"Zur Kasse" Button leitet häufig auf /register weiter - "Warenkorb ist leer"

Guten Morgen,

auch wir haben einen Kunden der von diesem Problem betroffen ist (Shopware 5.4.2 ) und dessen Kunden entsprechend nicht begeistert sind.
Leider war es uns noch nicht möglich dieses Verhalten in irgend einer Form zu reproduzieren, auch nicht mit einem frischen Browser. Daher ist das Debuggen äußerst schwierig…

Die Vermutung ist, dass aus irgendwelchen Gründen erst die Session verloren geht und dann als Folge der 302 in Richtung /register stattfindet.
Aufgrund der zeitlichen nähe von “Artikel in Warenkorb legen” und “zur Kasse gehen” dürfte es nicht an einer abgelaufenen Session liegen.

Als evtl. kleine “Besonderheit” verwenden wir nicht den Shopware Standard über die DB sondern memcached für die Sessions. Mediafiles werden über einen AWS CDN aus S3 geliefert, allerdings ohne Fallback zu shopdomain.tld/media, wie im hier geschilderten Fall: https://www.digitalmanufaktur.com/news/shopware-wondering-about-empty-basket-after-switching-category

Irgendwie habe ich aktuell einen der Warenkorb Ajax-Requests im Verdacht (/checkout/ajaxAmount, /checkout/ajaxAddArticleCart, /checkout/ajaxCart).

Kann jemand das Verhalten zuverlässig reproduzieren? Falls ja, wie?

Noch eine Frage von mir:

Wie fällt der Fehler eigentlich auf? Gibt es eine Fehlermeldung im BE/Fehlermail oder ist es dem Shopbetreiber nur bekannt, weil Kunden sich melden? Wenn der Shopbetreiber es selbst nicht merkt, gibt es vlt noch weitere Shops mit diesem Problem.

und noch eine zweite Frage…

Tritt der Fehler bei jeder Bestellung auf oder nur gelegentlich?

Die Kunden melden sich regelmäßig und sind not Amused. 
Was man auch durchaus nachvollziehen kann… stell dir vor, du rennst ne halbe Stunde durch den Supermarkt, packst deinen Wagen voll und sobald du am Kassenband stehst isser plötzlich leer…

Nachdem wir auf das Problem ausmerksam wurden, konnten wir es auch im Accesslog finden. 
Viele Aufrufe von /register haben eine Artikeldetailseite als Referrer, bzw. sind eine 302 Weiterleitung von /checkout/shippingPayment mit Artikeldetailseite als Referrer -> da passt was nicht.
Bei genauerer Betrachtung der vorangegangenen Requests von /register Aufrufen stellt man fest, dass vom gleichen Nutzer kurz zuvor u.a._ /checkout/ajaxAddArticleCart _aufgerufen wurde. 
Es wurde also ein Artikel in den Warenkorb gelegt und anschließend dann der Weg zur Kasse gewählt.

Der Fehler tritt nur gelegentlich auf und konnte zumindest von uns noch nicht reproduziert werden.

Guten Abend zusammen,

ein kleines Update: 
ich habe unser Problem tatsächlich im Issue Tracker gefunden Shopware Issuetracker und konnte mit der dortigen Beschreibung den Fehler reproduzieren. Eine kurze Ursachenforschung hat ergeben, dass man (vereinfacht gesagt) als Gastbesteller mit SLT Cookie zu „1/4“ eingeloggt ist, sobald man nach Bestellabschluss dem Browser schließt, wieder öffnet und eine neue Session bekommt. 
Shopware merkt sich allerdings mehr oder weniger nur, dass man Gastbesteller ist. Kommt man nun als Gastbesteller „uneingeloggt“ zum checkout, wird man sicherheitshalber erstmal „richtig“ ausgeloggt, was das löschen der Session zur Folge hat und wird dann zur Registrierung unter /register weitergeleitet.

Sofern man vom SLT (https://community.shopware.com/Shopware-Login-Token_detail_2028.html) keinen gebrauch macht, ist die einfachste Lösung des Problems, dieses zu deaktivieren.

Für alle anderen habe ich ein winziges Quick-Bugfix-Plugin geschrieben, welches ihr auf Github finden und verwenden könnt bis Shopware selbst nachgebessert hat:  
GitHub - mwillner/tplbFixSltCookie

Das Plugin bewirkt, dass bei Gastbestellungen kein SLT Cookie mehr angelegt wird und verhindert damit den oben beschriebenen „1/4 Login“ bei folgenden Shopbesuchen.
Das bedeutet gleichzeitig, dass für Gastbesteller keine SLT-Funktionen greifen.

Das Plugin wurde lediglich mit Shopware Version 5.4.2 kurz getestet, die Nutzung erfolgt auf eigene Gefahr.

2 Likes