Die oben genannte Fehlermeldung ist bekanntlich ein relativ “alter Hut” und wird in der Regel durch den geringsten Fehler in der Kombination aus den Versandkostenregeln, Zahlungsarten etc. verursacht.
Dieser Fehler tritt bei mir nur bei einer Erstbestellung auf. Die Versand/Zahlungsregeln sind definitiv korrekt, da z.B. eine Bestellung mit dem Admin-Account (John Doe) problemlos beendet werden kann.
“Beheben” lässt sich der Fehler durch Leeren des ERSTEN Warenkorbs nach der Neuregistrierung.
Genauer :
Neuregistrierung > mit dem 1.Warenkorb zur Kasse = o.a. Fehlermeldung
Leeren des Warenkorbs > Artikel erneut in den Warenkorb = Fehlermeldung verschwunden.
Diesen Prozess probiert natürlich kein Kunde aus. Kann sich jemand erklären woran das liegen könnte ?
in den meisten Fällen ist die Versandkostenregel nicht wie gewünscht konfiguriert.
Deine Workaround Schilderung, dass eine Versandkostenregel bei allen Kunden angezeigt wird welche bereits einmal den Warenkorb gefüllt hatten deutet darauf hin, dass in den Zuordnungsfenstern bei der Zahlungsart, Versandart und/oder Versandkostenregel bei Benutzergruppen und/oder Benutzer eine unglückliche Zuordnung gewählt wurde.
Habe mich das komplette Wochenende noch einmal mit dem Problem auseinandergesetzt und die Versandarten, Länder, Zahlungsarten sowie Benutzerzuordnungen systematisch kontrolliert.
Das Problem besteht weiterhin : Bestandskunde kann problemlos bestellen - Neukunde erhält die besagte Fehlermeldung. Und das Phänomen mit dem Warenkorb ist tatsächlich reproduzierbar : Einmal den Warenkorb leeren, danach wieder neu bestücken : Dann erscheint statt der Fehlermeldung der 3.Bestellschritt “Versand + Zahlung”
Keine Idee mehr… mal ganz trocken formuliert : Wäre etwas in den Versandarten, Länder, Zahlungsarten oder Benutzerzuordnungen fehlerhaft konfiguriert, dann dürfte das simple Leeren des Warenkorbs keineswegs zum Erfolg führen. Und Bestandskunden könnten dann ebenfalls keine Bestellung ausführen.
Nach einer Neuregistrierung wird in der Standard Konfiguration dem Neukunden der Benutzergruppe Inlandskunde und Noch nicht gekauft zugeteilt.
In der Standard Konfiguration bei den Zahlungsarten haben alle vorkonfigurierten Zahlungsarten gemeinsam, dass die Benutzergruppe Inlandskunde zugeordnet.
Jetzt wären die Fragen
Welches Land hat der Neukunde bei Registrierung ausgewählt?
Welches Land bzw. Länder sind als Inlandsländer in den Shop Grundeinstellungen → Tab Einstell. → Global ausgewählt?
Welche Benutzergruppen hat ein Neukunde nach seiner Registrierung zugeordnet? Ändern sich die Benutzergruppen des Neukundens wenn er den Warenkorb leert?
Hat der Neukunde vor seiner Registrierung vielleicht bereits als Gast eine Bestellung getätigt?
Ansonsten das oben verlinkte Modul von @leofonic sehr zu empfehlen um nähere Rückschlüsse auf die Konfiguration der Versandkostenregeln zu erhalten für die Diagnose.
Da gab’s eigentlich nichts zu installieren - PayPal war ja schon vorinstalliert und der Shop in der Version 6.3.1 steht ja noch als Download Package zur Verfügung. In sofern entstand da zu dem Thema “Composer” zunächst kein Handlungsbedarf.
Ich werde mich da heute mal mit auseinandersetzen. Wenn ich es richtig gesehen habe, empfiehlt der Shop ein Update auf die Version 6.4.0 welches offenbar ohnehin ausschließlich über Composer zu realisieren ist.
Ja man kommt um composer nicht herum. Zum Ausprobieren empfiehlt sich eine Testumgebung. Mal ein kurzer Überblick:
Composer kopiert Dateien auf den lokalen Rechner, in den Zweig “vendor”. Oxid installiert dabei noch ein composer-plugin, welches Dateien von “vendor” in “source” kopiert, das läuft nach jedem “conposer update” automatisch.
Es gibt die composer.json, da steht drin was installiert werden soll, und die composer.lock, da steht drin was tatsächlich installiert wurde.
Der Befehl “composer update” installiert das was in composer.json gewünscht wurde.
Der Befehl “composer require” trägt ein neues Package in der composer.json ein und führt dann “composer update” aus
Dann gibt es noch den Parameter “–no-dev” für composer update ("–update-no-dev* bei require), dann werden die packages bei “require-dev” nicht installiert (Testing Libraries etc).
Für eine Modulinstallation muss man also nur den Befehl “composer require packageXY” oder"composer require packageXY --update-no-dev" in der Kommandozeile eingeben und fertig.
Ich habe es heute einfach mal “gewagt” unter SSH im Shopverzeichnis “*composer require zunderweb/deliverysetcheck” auszuführen. Das fürwahr verblüffende Ergebnis : Nach einigen Sekunden war das Modul installiert und musste lediglich aktiviert werden
Das Modul konnte keinen Fehler finden und der Bestellvorgang lief bis zum Abschluss fehlerfrei durch (Besteller war Neukunde)
Und jetzt kommt’s : Seit der Installation des Moduls funktionieren alle Bestellvorgänge einwandfrei (!!) ohne, dass irgendwelche Änderungen vorgenommen wurden. Egal ob das Modul aktiviert oder deaktiviert ist. Ich habe mehrere Erstbestellungen danach durchgeführt (welche vorher definitiv immer mit der besagten Fehlermeldung abbrachen) - alle konnten problemfrei beendet werden.
Das ist relativ. Durch die Modulinstallation wurden automatisch alle Abhängigkeiten mit aktualisiert, wahrscheinlich war nur eine andere Software Bibliothek veraltet in Deinem Vendor Verzeichnis.
Das ist der Vorteil von Composer, dass die Software Bibliotheken über Composer (Packages genannt) einfacher aktuell gehalten werden ohne ein Shop Update durchzuführen. Bis zu einem gewissen Grad - kommt drauf an wie der Abhängigkeitsbaum in der composer.json Datei definiert ist - ist dies möglich.
benutzt Du einen Apple oder einen Microsoft Rechner/Laptop? Bzw. gibt es hierbei noch Unterschiede? Weil ich habe leider immer noch dasselbe nervige Problem, was Du jetzt offenbar schon gelöst hast, und das, obwohl ich mir all die Antworten auf Deine Frage, die ja jetzt als gelöst gilt, durchgelesen habe und versucht habe die dortigen Anweisungen zu befolgen, aber bei mir hat dies bisher wie gesagt nicht so gut geklappt…
Deswegen bevor ich mich da nochmal reinfuchse, wollte ich lieber nochmal nachfragen, ob der Weg zur Lösung bei Apple und Microsoft sich hierbei unterscheidet?
um kurz zu machen, dies sollte in diesem Fall keinen Unterschied machen welches Betriebssystem Du verwendest.
Der OXID eShop selber setzt als Systemvoraussetzung z.B. einen Apache Server voraus. Normalweise sind diese beim Hoster auf einer Linux Umgebung aufgesetzt.
