Beiträge von StefanSTS

    Servus,


    Zur Zeile:

    - Bei diesen Bestellungen fehlt die Rechnungsnummer, Status ist "in Bearbeitung" -

    (Hiermit kann das alles zusammenhängen.)


    Status P "In Bearbeitung/Pending" ist nur für einen bestimmten Zweck/Zeitraum gedacht.


    --

    Nach:

    -> Der Kunden hat den Kaufen-Button gedrückt.

    Bis:

    -> Das Payment-Plugin gibt einen neuen Status zurück.

    --


    Es gibt im Grunde nur zwei EDIT: drei Szenarien, in denen Status P in der Bestellliste sichtbar sein sollte.


    1. Der Kunde ist gerade dabei, die Bestellung abzuschließen,

    - Hat den Kaufen-Button geklickt.

    - Ist noch beim Zahlungsprovider, z. Bsp. Paypal, und von dort gibt es noch keine Rückmeldung.


    2. Der Kunde hat den Kauf nach dem Klick auf Kaufen durch Schließen des Browser-Fensters beendet.

    - Der Zahlungsprovider schickt in diesem Fall keine Rückmeldung. Z. Bsp. Bestätigt, Abgelehnt, usw.

    -> Der Status "bleibt auf P hängen".


    EDIT:

    3. Die Rückmeldung einer erfolgreichen Zahlung an den Shop ist trotz erfolgreicher Bezahlung nicht vom Zahlungsprovider an den Shop mitgeteilt worden.

    Z. Bsp. weil eine IPN nicht erfolgreich beim Shop angekommen ist.


    Mir ist bewusst, dass dieser Status P sehr oft anders verwendet wird. Mir wäre auch lieber, wenn er anders heißen würde.

    Z. Bsp.: "Kaufen-Button gedrückt, warte auf Zahlungsplugin". Dann würde es nie wieder Missverständnisse geben.


    Wenn der Status P "In Bearbeitung/Pending" aktuell in einer anderen Form verwendet wird, kann ich nur raten, das umzustellen.

    Ich habe oft gesehen, dass die Einstellungen so sind, dass Status P von einem Zahlungsplugin als Status nach erfolgreicher Bezahlung aufgerufen wird.

    Das ist so nicht gedacht, und deshalb gibt es auch keine Mails an den Käufer oder eine Rechnungsnummer. Status P erzeugt keine Rechnungen, damit auch keine Rechnungsnummer und nur E-Mails an den Verkäufer, wenn das so gewünscht ist (VM Konfig).


    Die Standardstatus, die ein Zahlungsplugin nach erfolgreicher Bestellung ausgibt, sind Status U und Status C.

    Status U - Vom Kunden bestätigt / Confirmed by Shopper.

    Status C - Bestätigt / Confirmed.


    Wenn einem die Namen nicht gefallen, kann man diese umbenennen.


    Oder eigene neue Status anlegen. Das ist oft sinnvoll, vor allem, wenn man unterschiedliche Zahlungsplugins vewendet.

    (Ich habe Kunden mit ca. 20 Status für alle möglichen Fälle, spezifische Rückmeldung für Paypal, für Stripe, Zahlungserinnerungen usw.)


    Soviel zur Zeile 5. Ich muss jetzt erst einmal Kaffee trinken.


    STS

    Servus,


    "was Milbo mit product groups meint"


    mit Produktegruppen meint Milbo die Bereiche, die in einer Kategorieansicht unter den Produkten der Kategorie angezeigt werden können.

    Im Allgemeinen benutzt man diese auf der Shop-Startseite, die über das Kategorielayout mit Verweis auf "Kategorie Höchste Ebene" (ID 0) angelegt wird.


    --

    Früher gab es das alte Layout "Standard Layout (Veraltet!)" für die Startseite. Damit das funktioniert, gibt es die oben genannte Einstellung in der VM-Konfig. Die alte VM-Startseite als Menüeintrag gibt es zwar noch, aber das ist Kram von gestern, den Milbo nur nicht rauswirft, um alte Installationen bei Update nicht zu zerstören. So grob gesagt.

    In dieser Startseite waren die Produktgruppen fest eingebaut.

    --


    In den Screenshots in Beitrag 16 kann man die Einstellungen für die Produktgruppen in der VM-Konfiguration - Reiter Stilvorlagen - Shop Einstellungen vornehmen. Dort der letzte 5er-Block, der mit "Aktionen anzeigen" beginnt.


    Das Gleiche kann man dann auch noch im Menüeintrag für eine bestimmte Kategorie einstellen und in der angelegten VM-Kategorie im Reiterr "VirtueMart Kategorieansicht einstellen".


    Die Reihenfolge, welche Einstellung priorisiert wird, bitte einmal selbst ausprobieren. Korrigiert mich, wenn ich es verdreht habe.


    Früher war es.

    VM-Konfig wird überschrieben von

    VM-Kategorie-Einstellung wird überschrieben von

    Menüeintrag-Einstellung.


    Jetzt müsste es sein:

    VM-Konfig wird überschrieben von

    Menüeintrag-Einstellung wird überschrieben von

    VM-Kategorie-Einstellung.



    Grüße

    STS

    Das kann ich nicht mit Bestimmtheit sagen, aber ich nehme stark an, dass es nur die Tabellen sind, an die Joomla auch herankommt. Und das müssten die sein, die in der Joomla-Konfiguration eingestellt sind. Eben die mit dem Prefix der jeweiligen Installation.


    Persönlich verwende ich immer getrennte Datenbanken, um die Installationen vollständig voneinander zu trennen.


    STS

    Hm, noch ein Ansatz:

    In den VM-Werkzeugen gibt es die Datenbank-Reparatur, evtl. könnte das etwas bringen.



    Möglicherweise sind aber auch noch andere Plugins von Artio aktiv, die da mitspielen.

    Ich werfe Artio schon seit Jahren raus, weil das durch alten und schlechten Code oft Probleme gemacht hat, deshalb kann ich aber auch nichts zur aktuellen Qualität sagen, weil ich da nicht mehr hinein schaue.


    STS

    Ja, da hast Du recht, an der default.php kann es nicht mehr liegen, weil von dort aus dann kein JS mehr eingefügt wird.


    Ich hatte nur den anderen JS-Code mit in die Bedingung gepackt, weil er beim Druck dann einfach übergangen wird,

    Bringt sicher keine Milisekunde. Fühlt sich aber richtiger an, als unnötig Variablen zu füllen.


    Die verbleibenden // werden aus einer anderen Datei kommen. Wer es zuerst findet, bekommt auf dem nächsten VirtueMart-Tag ein Frühstück.


    STS

    In dem Fall würde ich sagen, wenn da "manuell" in der Datenbank ausgelesen wird, besser nicht genau beschreiben, damit es niemand nachmacht, der nicht weiß, was er tut. ;-)


    Für alle, die über Google hier herkommen.

    Advanced Shipping by Rules von Open Tools ist inzwischen in VM integriert. Damit kann man einiges tun.

    Hier gibt es Infos dazu, solange die Seite noch online ist:
    https://www.open-tools.net/vir…ed-shipping-by-rules.html


    Es ist auch durchaus möglich, solche Änderungen mit VM-Hausmitteln darzustellen. Das allerdings nur, wenn der genaue Anwendungsfall bekannt ist.


    STS

    Servus,


    um die Frage umfassend beantworten zu können, müsste ich jetzt viel Code surfen.


    Leider ist die eigentliche Aufgabenstellung nicht genau beschrieben.

    Ich bin mir ziemlich sicher, es gibt auch Möglichkeiten, diese Custom Field Eigenschaft auch anders bei den Versandkosten zu berücksichtigen.


    Wenn man zum Beispiel ein Multi-Variant dafür nimmt, könnte man die Kinder unterschiedlichen deaktivierten Kategorien als Steuerkategorie zuordnen, und dann die Versandart nach Kategorie wählen.

    Mir fallen da noch andere Möglichkeiten ein, ohne im Code Veränderungen machen zu müssen.


    Oder gar das Google: qvariant Plugin von AH, das als Custom Field auch das Gewicht des Produkts ändern kann. Das Plugin findet Google im engl. VM Forum.


    Auf die Schnelle

    STS

    Den Fix habe ich ausprobiert, bei mir erscheint weiterhin das // am Ende des PDFs.

    Womöglich sind da noch andere Aufrufe, die bei webgras nicht vorhanden sind.


    Daraus folgernd könnte es bei webgras an Template-Overrides liegen, dass es funktioniert wie erwartet.


    In den Produktdetails habe ich die Bedingung noch ausgeweitet, aber auf die Schnelle nichts gefunden.

    Ich sehe dieses Problem als weiterhin offen.

    Falls noch jemand Ideen hat, wo die Zeichen // im Original VM unter Cassiopeia herkommen könnten, immer raus damit. ;-)


    STS

    Die Aussage, dass das Problem nur mit der Version .11101 auftritt, hatte ich gelesen.

    An meinen Fragen ändert das nichts, weil das erste Schritte sind, um festzustellen, ob sich etwas verändert.


    Wenn dieses Problem in einer VM-Demo-Installation nicht nachvollziehbar ist, ist es hilfreich, an ein paar Schrauben zu drehen.


    STS


    PS. Evtl. bei Milbo einmal anfragen, ob er die aktuelle Dev-Version schicken kann.


    PPS. Die PHP-Version auf 8.2 stellen, wäre ein weiterer Versuch.