Bestellabschluss nicht möglich! Error 500 auf checkout/shippingPayment. Wie vorgehen?

Shopware 5 Allgemein
1

Hallo,

beim checkout, Schritt 1 (Adresse angeben) und aktivierter Option „kein Benutzerkonto anlegen“ erscheint nach dem klick auf „Weiter“ nur noch der Header aber kein page content mehr. Im Inspector ist zu sehen das die Verbindung zu https://meinShop/checkout/shippingPayment mit einem Fehler 500 endet. Dabei wurden aber Schon Daten empfangen. In der Antwort sind, wie gesagt, sichtbare page header und schon ein Teil der Navigation, sie bricht aber einfach mittendrin ab.

Php errorlog auf Server enthält keinen aktuellen Eintrag.

Ich weiß nicht wo ich noch weiter nachforschen kann.

Danke ud Grüße

rowa

PS: Die 1:1 Script- und DB-Kopie aka. DevShop im Unterordner erzeugt dieses Problem nicht. Nur der Produktion Shop.

2

Gibt es Fehlermeldungen in den Shopware-Logs?

Timme Hosting - schnelles nginx-Hosting

www.timmehosting.de

3

Jetzt hab ich logs:

[24-Aug-2018 09:48:09 Europe/Berlin] PHP Fatal error: Uncaught Enlight_Controller_Exception: Controller "account" not found in /html/shopware/engine/Library/Enlight/Controller/Dispatcher/Default.php:507
Stack trace:
#0 /html/shopware/engine/Shopware/Kernel.php(226): Enlight_Controller_Dispatcher_Default->dispatch(Object(Enlight_Controller_Request_RequestHttp), Object(Enlight_Controller_Response_ResponseHttp))
#1 /html/shopware/vendor/symfony/http-kernel/HttpCache/HttpCache.php(486): Shopware\Kernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#2 /html/shopware/engine/Shopware/Components/HttpCache/AppCache.php(268): Symfony\Component\HttpKernel\HttpCache\HttpCache->forward(Object(Symfony\Component\HttpFoundation\Request), true, NULL)
#3 /html/shopware/vendor/symfony/http-kernel/HttpCache/HttpCache.php(443): Shopware\Components\HttpCache\AppCache->forward(Object(Symfony\Component\HttpFoundation\Request), true)
#4 /html/shopware/vendor/symfony/http-kernel/HttpCache/HttpCache.php(339): Symfony\Component\HttpKernel\HttpCache\HttpCache->fetch(Obj in /html/shopware/engine/Library/Enlight/Controller/Dispatcher/Default.php on line 507

 

ShopCache leeren hat nichts verändert.

4

Wäre echt cool, wenn noch jemand ne Idee hat wo ich was probieren oder nach schauen kann. Denn hat sich ein Kunde einmal den Checkout zerschossen, sind ALLE Seiten des Shops genau so kaputt. Ab dann immer, bei jedem neuen Aufruf! (Nachtrag: Solange der Warenkorb existiert. Diese verfällt nach ~10min, dann wird der Shop wieder normal angezeigt oder wenn ein Privates/incognito-Fenster verwendet wird)

 

Hab jetzt mal debug output in /html/shopware/engine/Library/Enlight/Controller/Dispatcher/Default.php:507 kurz vor der Stelle des Endes erzeugt. Dabei ist zu sehen, das sich der output auf dem DevSystem (wo der Checkout normal funktioniert) und dem ProduktivSystem stark unterscheiden:

Mein “Debbuger”:
error_log('ControllerName: ‘.$request->getControllerName().’ key: '.$request->getControllerKey."\n".
          'ModuleName: ‘.$request->getModuleName().’ key: '. $request->getModuleKey()."\n".
          'ActionName: ‘.$request->getActionName().’ key: '. $request->getActionKey()."\n".
          'UserParams: '.print_r($request->getUserParams(),true).
          ‘BaseUrl/path: ‘. $request->getBaseUrl().’/’.$request->getBasePath()
          );

 

Der output im Produktivsystem:

[25-Aug-2018 17:10:46 Europe/Berlin] ControllerName: register key:
    ModuleName: frontend key: module
    ActionName: saveRegister key: action
    UserParams: Array()
    BaseUrl/path: /
[25-Aug-2018 17:10:49 Europe/Berlin] ControllerName: checkout key:
    ModuleName: frontend key: module
    ActionName: shippingPayment key: action
    UserParams: Array()
    BaseUrl/path: /
[25-Aug-2018 17:10:57 Europe/Berlin] ControllerName: checkout key:
ModuleName: widgets key: module
    ActionName: info key: action
    UserParams: Array()
    BaseUrl/path: /
[25-Aug-2018 17:10:57 Europe/Berlin] ControllerName: account key:
    ModuleName: widgets key: module
    ActionName: partnerStatisticMenuItem key: action
    UserParams: Array()
    BaseUrl/path: /
[25-Aug-2018 17:10:57 Europe/Berlin] PHP Fatal error: Uncaught Enlight_Controller_Exception: Controller "account" not found in /html/shopware/engine/Library/Enlight/Controller/Dispatcher/Default.php:515
    Stack trace: [...]
[25-Aug-2018 17:11:02 Europe/Berlin] ControllerName: login key:
    ModuleName: backend key: module
    ActionName: getLoginStatus key: action
    UserParams: Array()
    BaseUrl/path: /

 

Der Output im DevSystem wenigstens bis zum fraglichen controller “account”:

[25-Aug-2018 17:03:31 Europe/Berlin] ControllerName: register key:
    ModuleName: frontend key: module
    ActionName: saveRegister key: action
    UserParams: Array()
    BaseUrl/path: /shopware-devsys//shopware-devsys
[25-Aug-2018 17:03:32 Europe/Berlin] ControllerName: checkout key:
    ModuleName: frontend key: module
    ActionName: shippingPayment key: action
    UserParams: Array()
    BaseUrl/path: /shopware-devsys//shopware-devsys
[25-Aug-2018 17:03:38 Europe/Berlin] ControllerName: index key:
    ModuleName: widgets key: module
    ActionName: shopMenu key: action
    UserParams: Array
    (
        [_isSubrequest] => 1
        [module] => widgets
        [controller] => index
        [action] => shopMenu
    )
    BaseUrl/path: /shopware-devsys//shopware-devsys
[25-Aug-2018 17:03:38 Europe/Berlin] ControllerName: compare key:
    ModuleName: widgets key: module
    ActionName: index key: action
    UserParams: Array
    (
        [_isSubrequest] => 1
        [module] => widgets
        [controller] => compare
    )
    BaseUrl/path: /shopware-devsys//shopware-devsys
[25-Aug-2018 17:03:38 Europe/Berlin] ControllerName: index key:
    ModuleName: widgets key: module
    ActionName: menu key: action
    UserParams: Array
    (
        [_isSubrequest] => 1
        [module] => widgets
        [controller] => index
        [action] => menu
        [group] => gLeft
    )
    BaseUrl/path: /shopware-devsys//shopware-devsys
[25-Aug-2018 17:03:38 Europe/Berlin] ControllerName: checkout key:
    ModuleName: widgets key: module
    ActionName: info key: action
    UserParams: Array
    (
        [_isSubrequest] => 1
        [module] => widgets
        [controller] => checkout
        [action] => info
    )
    BaseUrl/path: /shopware-devsys//shopware-devsys
[25-Aug-2018 17:03:38 Europe/Berlin] ControllerName: account key:
    ModuleName: frontend key: module
    ActionName: partnerStatisticMenuItem key: action
    UserParams: Array
    (
        [_isSubrequest] => 1
        [action] => partnerStatisticMenuItem
        [controller] => account
    )
    BaseUrl/path: /shopware-devsys//shopware-devsys

 

Wäre toll, wenn mir jemand helfen könnte zu erklären, warum nach dem ersten checkout controller weniger Daten (index, compare und index controller fehlen) erzeugt werden als auf dem DevSystem. Ich bin total ratlos. Die Einstellungen, Dateien und Datenbank beider Systeme sind identisch. Einziger Unterschied, der DevShop liegt im Unterverzeichnis des ProduktivShops.

Danke und Gruß

5

Zusatz: Der Fehler tritt reproduzierbar nicht auf wenn der Shop im Bearbeitungsmodus betrieben wird! Steht der Shop auf Produktivmodus, tritt der Fehler wieder auf. (Bei jedem Moduswechsel muss natürlich der Cache gelöscht werden um das veränderte Verhalten zu sehen.)

Ich sehe auch einen gewissen Bezug zu einem bereits gemeldeten Fehler: https://issues.shopware.com/issues/SW-22413 da dort auch die Oberfläche kaputt geht und durch löschen des Cookies temporär behoben wird. Was bei mir zwar hilft den Shop an sich wieder zu sehen aber natürlich den kaputten Checkout nicht repariert. Hatte ich den Fehler #SW22431 selber beim Plugin BestItAmazonPay.

6

Sehe da keinen Zusammenhang.

Bei dir scheint der Shop den Controller “account” nicht mehr zu finden. 
Klingt erstmal nach einem sehr individuellen Problem. Vielleicht hast du ein Plugin was den Zugriff auf “account” reguliert?

7

Nein, wir haben nichts was den den account beeinflussst, ausser das Swag PayPal oder Bestit Amazon Plugin tun das.

Es wird immer schlimmer, nach dem wir nun diesen workaround haben, dass der Shop im dem Bearbeitungsmodus läuft springt er im zweiten Schitt des Checkouts, bei der Wahl eines Zahlungsmittels, zurück auf Schritt-1 und sagt “Ihre Zugangsdaten konnten keinem Benutzer zugeordnet werden”. Weder das php_error.log noch unter var/log/ sind aktuelle Einträge aufgetaucht.

Ist das feature “Kein Kundenkonto” noch an irgendeine Einstellungen gebunden?

8

Naja „kein Kundenkonto“ kann aber auch nicht auf account zugreifen - das wäre ja richtig. Der account leitet dann immer auf register weiter, wenn du ein Gastkonto hast.
Klingt ziemlich komisch was ihr da habt - erklär nochmal genau den Fehler - in welchem Case wird ein 500 im Checkout geworfen und wie kommst du jetzt auf Schnellbesteller?

9

Wie ob am log output zu sehen ist, wird auch bei einem “Schnellbesteller” der controller account durchlaufen. Und in meinem Fall, also bei aktivierten Produktivmodus failt das auch. (-> Seite kaputt. 500er

Mein Workaround, aktuell ist, nur den Bearbeitungsmodus aktiviert zu haben. Das führt nun aber dazu, dass im Schritt-3 beim Wechsel auf eine Zahlungsart er wieder zurück auf Schritt-1 springt und meint “Ihre Zugangsdaten konnten keinem Benutzer zugeordnet werden”. Was wohl ein PayPal fail ist soweit ich das grade überblicke.

Zu erwähnen wäre noch, das obwohl grade alle PayPal-Plugins deaktivert (und die alten auch deinstalliert), der Punkt PayPal im checkout verfügbar ist.

Bei mir geht es die ganze Zeit nur um den Fall mit aktiviertem Häckchen bei “Kein Kundenkonto anlegen”, nix anderes.

10

Du wirfst aber etliche Sachen durcheinander. Die Zahlungsart kannst du im Zahlungsarten-Modul deaktivieren - das Plugin deaktiviert nur die Funktion dahinter. Deine Probleme werden auch nix mit Paypal zu tun haben.

Deine Fehlerseite ist ja /checkout/ShippingPayment soweit du das erklärt hast. Also am besten als ersten Schritt mal alle Zahlungsanbieter bis auf Vorkasse deaktivieren (= Einstellungen > Zahlungsarten), gleiches für die Versandkosten (Einstellungen > Versandkosten). 

Der Bearbeitungsmodus greift weder im Account, noch im Checkout, weil die Seiten immer Live ausgeliefert werden. Entweder hast du da was mit dem Caching “zerhackt” (bspw. beim HTTP-Cache irgenwas mit cachen lassen, was da nicht hingehört, kann man im Performance-Modul einstellen) oder du hast ein anderes Problem.

Im Zweifel gib mir mal Zugang zum Shop und ich muss das nachstellen können (FTP, PHPMyAdmin, Backend) an forum@shopware.com
 

1 „Gefällt mir“
11

Danke für die vielen Ansätze.

Also der Fehler tritt auch auf wenn nur noch Vorkasse als Zahlung und Nachnahme bei Versand aktiv ist (wir haben keine Versandkosten extra für Vorkasse).

Im cache ist soweit ich sehe nichts anders eingestellt als der default nach der Installation. Einzig, dass sowohl oben in der Definition widgets/checkout ( Wert=3600) stand als auch unten bei nicht gecachten tags widgets/checkout (Wert=checkout/slt) auftaucht.

 

12

Im Responsive tritt es nicht auf. Ich habe mir danach mal das eingesetzte Theme runtergeladen und in meinen Testshop gepackt und dann hab ich da das Problem auch. Ist also eindeutig das Theme die Ursache. Das Problem ist ein „Mein Konto“ ausklapper oben, der kommt wohl mit Schnellbestellern nicht klar.

1 „Gefällt mir“