404-Error im Checkout

Hallo zusammen,

aktuell habe ich eine massive Zahl an Kaufabbrüchen in meinem Shop. Die Zahl ist so hoch, dass mich sogar mehrere Kunden darauf hingewiesen haben.

Es scheint als würde im checkout nach der Adresseingabe (also nach /checkout/confirm) bzw. nach Wahl der Bezahlmethode ein 404 Error kommen. Die Warenkörbe bleiben aber erhalten, so dass einige Kunden den Vorgang Wiederholen können. Es liegt auch nicht an Modulen wie PayPal, weil die Kunden bis zu diesem Schritt in der Regel nicht kommen.

Am PC (Chrome, Firefox, IE) sowie mit Android 6 oder dem iPad kann ich die Fehler aber nicht nachstellen. Weder mit Bestands- noch mit Gastkonten.

Ich weiß auch nicht so recht, wo ich auf Fehlersuche gehen soll, denn es scheint soweit zu klappen. Caches sind ebenfalls geleert.

Könnte mir jemand von euch evtl. einen Tipp geben was ich noch überprüfen kann? Wäre euch sehr dankbar, denn aktuell bin ich wirklich am verzweifeln Crying?

Hier ist der Link zum Shop

Edit: Ich nutze Version 5.1.5

Gerade eben kam folgende Nachricht eines Besuchers rein

 

Leider ist es mir schon den ganzen Tag nicht möglich mich auf der  Seite einzuloggen, auch kann ich Artikel zwar in den Warenkorb legen, allerdings wird mir dann trotzdem ein leerer Warenkorb angezeigt.  Gestern Mittag habe ich mich erstmalig registriert, ich habe auch eine Bestätigung meiner Registrierung per E-Mail erhalten, einloggen kann ich mich jedoch nicht. Es kommt immer eine Fehlermeldung.  Können Sie das bitte prüfen beziehungsweise mir mitteilen wie genau ich vorgehen soll?

Gestern habe war ich bereits mit Freunden und Verwandten auf Fehlersuche, aber es scheint alles zu funktionieren. Bestellungen gehen durch.

Doch bei einigen anderen Nutzern hängt einfach alles  Crying 

Sind alle Plugins für 5.1.5 freigegeben? Am besten die komplette Liste im Detail durchgehen.

Als ich 5.1.5 vor Wochen installiert habe, waren alle Plugins freigegeben.

Danach habe ich 1-2 Stück installiert, diese waren aber kompatibel markiert.

Aktuell sind 3 noch nicht für die aktuellste Version nicht freigegeben (5.2.6), daher warte ich mit dem Update noch.

@Andrew schrieb:

Gerade eben kam folgende Nachricht eines Besuchers rein

 

Leider ist es mir schon den ganzen Tag nicht möglich mich auf der  Seite einzuloggen, auch kann ich Artikel zwar in den Warenkorb legen, allerdings wird mir dann trotzdem ein leerer Warenkorb angezeigt.  Gestern Mittag habe ich mich erstmalig registriert, ich habe auch eine Bestätigung meiner Registrierung per E-Mail erhalten, einloggen kann ich mich jedoch nicht. Es kommt immer eine Fehlermeldung.  Können Sie das bitte prüfen beziehungsweise mir mitteilen wie genau ich vorgehen soll?

Gestern habe war ich bereits mit Freunden und Verwandten auf Fehlersuche, aber es scheint alles zu funktionieren. Bestellungen gehen durch.

Doch bei einigen anderen Nutzern hängt einfach alles  Crying 

das scheint mir das iOS-Problem zu sein. irgendwas mit Bots…suche mal danach im Forum…ich habs gerade nicht da 

@NextMike schrieb:

das scheint mir das iOS-Problem zu sein. irgendwas mit Bots…suche mal danach im Forum…ich habs gerade nicht da 

Danke sehr, ich teste es direkt einmal mit dieser Anleitung

Wenn es nun wirklich daran liegt, hat mein Apple-Hass eine neue Dimension erreicht  Grin

Es scheint wirklich mit dem „legs“ Bot aus der Anleitung zusammenzuhängen. Eine Kundin konnte nach der Anpassung in der Bot-Liste, die Bestellung vom iPad aus durchführen. Zuvor hat sie mich auf den Fehler hingewiesen.

Wir haben aktuell genau denselben Fehler. Den Eintrag in der Bot-Liste habe ich schon angepasst. Gibt es evtl. noch einen anderen Ansatz? Der 404 kommt im Checkout, ich kann ich aber nicht nachstellen.

Auch wir beobachten diesen Fehler seit einem Update von Shopware 5.0.x auf Shopware 5.2.x. Dummerweise tritt der Fehler nur sporadisch auf - schon 1 Sekunde später kann er bereits wieder verwschwunden sein. Die Vermutung ist tatsächlich, dass der Fehler vom Client ausgelöst wird, wir die Randbedingungen aber nicht kennen.

Wir loggen gerade mit Nachdruck, was dort passiert.

Wir haben derzeit das gleiche Problem. Der Eintrag „legs“ in der Botliste existiert bei uns nicht mehr, trotzdem können keine Artikel in den Warenkorb gelegt werden.

Ich konnte es bisher auf iPhone 7 eingrenzen. Bei iPhone 6 und allen getesteten Android Geräten (Smartphone und Tablet) tritt der Fehler nicht auf.

Shopware Version 5.0.2.

 

@SVH Handels GmbH schrieb:

Wir haben derzeit das gleiche Problem. Der Eintrag „legs“ in der Botliste existiert bei uns nicht mehr, trotzdem können keine Artikel in den Warenkorb gelegt werden.

Ich konnte es bisher auf iPhone 7 eingrenzen. Bei iPhone 6 und allen getesteten Android Geräten (Smartphone und Tablet) tritt der Fehler nicht auf.

Shopware Version 5.0.2.

 

Javascript deaktiviert? 

Hallo Moritz,

nein, am JavaScript liegt es nicht. Das Hinzufügen zum Warenkorb funktioniert ganz normal über ein Formular, nicht über JavaScript. (altes emotion Template)

Cookies sind ebenfalls zugelassen. Das Phänomen tritt bei unterschiedlichen iPhone 7 Geräten auf, daher kann eigentlich eine besondere Einstellung am Gerät ebenfalls ausgeschlossen werden. Wie gesagt, bis iPhone 6 funktioniert es einwandfrei.

Hier kann das Problem nachgestellt werden: m.svh24.de

Einfach irgendeinen Artikel in den Warenkorb legen. Ich weiß, der mobile-Shop sieht nicht besonders schön aus. Fliegt auch Ende diesen Jahres mit der Umstellung auf 5.3 und responsive Template weg :slight_smile:

 

Gruß

Markus

Hast du das denn im demoshop auch oder nur bei euch?

 

Wir haben das Problem auch bei Amazon Pay Zahlungen und sind aktuell absolut ratlos. Es werden auch keine Fehlermeldungen in die Log-Dateien geschrieben.

Moin,

3 Ansätze die bei uns sämtliche Kaufabbrüche lösten.

#1 im HTTPS Checkout werden Inhalte und Forumulare via HTTP eingebunden
Wir hatten mal ein one-page-checkout im Einsatz, bei denen die Formulare alle per http eingebunden waren,
da gingen permanent sessions flöten, leere Warenkörbe und Kaufabbrüche bei Versandart oder Zahlartwechsel.

#2 Kaspersky Internet Security 2015

KIS 2015 verhindert PayPal-Abschlüsse wenn PayPal.com in Kaspersky nicht als “Website für den sicheren Zahlungsverkehr” eingetragen ist.

 

#3 Shop komplett auf HTTPS umgestellt.
Da waren die Probleme mit Kaspersky verschwunden

 

Durch die 3 Maßnahmen habe ich statt 4 von 10 ,gerade mal 1 von 300 Abbrüche.

 

 

 

 

1 „Gefällt mir“

@SW5Nutzer schrieb:

Moin,

3 Ansätze die bei uns sämtliche Kaufabbrüche lösten.

#1 im HTTPS Checkout werden Inhalte und Forumulare via HTTP eingebunden
Wir hatten mal ein one-page-checkout im Einsatz, bei denen die Formulare alle per http eingebunden waren,
da gingen permanent sessions flöten, leere Warenkörbe und Kaufabbrüche bei Versandart oder Zahlartwechsel.

#2 Kaspersky Internet Security 2015

KIS 2015 verhindert PayPal-Abschlüsse wenn PayPal.com in Kaspersky nicht als „Website für den sicheren Zahlungsverkehr“ eingetragen ist.

 

#3 Shop komplett auf HTTPS umgestellt.
Da waren die Probleme mit Kaspersky verschwunden

 

Durch die 3 Maßnahmen habe ich statt 4 von 10 ,gerade mal 1 von 300 Abbrüche.

 

 

 

 

Das kann ich soweit eigentlich ausschließen. Der Shop läuft schon immer komplett verschlüsselt und im Checkout selbst haben wir keine Plugins laufen. 

Ich konnte nun endlich eine Fehlermeldung „abfangen“, wie bereits erwähnt, wird diese Meldung in kein Log geschrieben. Nachdem ich den Cache-Leere, funktioniert es wieder für eine gewisse Zeit. Kann evtl. jemand was mit der Meldung anfangen?

Fatal error: Uncaught SmartyCompilerException: Syntax Error in template „/var/www/clients/client1/web2/web/themes/Frontend/Bare/frontend/index/index.tpl“ on line 7 „<html class=„no-js“ lang=“{s name=‚IndexXmlLang‘}{/s}" itemscope=„itemscope“ itemtype="http://schema.org/WebPage"\>" unknown tag „s“ in /var/www/clients/client1/web2/web/engine/Library/Smarty/sysplugins/smarty_internal_templatecompilerbase.php:657 Stack trace: #0 /var/www/clients/client1/web2/web/engine/Library/Smarty/sysplugins/smarty_internal_templatecompilerbase.php(443): Smarty_Internal_TemplateCompilerBase->trigger_template_error(‚unknown tag „s“‘, 7) #1 /var/www/clients/client1/web2/web/engine/Library/Smarty/sysplugins/smarty_internal_templateparser.php(2388): Smarty_Internal_TemplateCompilerBase->compileTag(‚s‘, Array) #2 /var/www/clients/client1/web2/web/engine/Library/Smarty/sysplugins/smarty_internal_templateparser.php(3101): Smarty_Int in /var/www/clients/client1/web2/web/engine/Library/Smarty/sysplugins/smarty_internal_templatecompilerbase.php on line 657

Hi @Chris_tian den gleichen scheiß habe ich auch hast du eine Lösung gefunden? (Ich lass jetzt alle 5 Minuten den Cache leeren um das ein bisschen einzuschränken)
Ist natürlich nicht die Lösung… :-/

@Nama99 schrieb:

Hi @Chris_tian den gleichen scheiß habe ich auch hast du eine Lösung gefunden? (Ich lass jetzt alle 5 Minuten den Cache leeren um das ein bisschen einzuschränken)
Ist natürlich nicht die Lösung… :-/

Das ist absolut nicht die Lösung. Hast du auch dieselbe Fehlermeldung? Evtl. können wir gemeinsamkeiten in den Plugins finden? 

Da bei uns im Shop die Fehler als 404 angezeigt werden, haben wir einen kleinen Logger gebaut. Auffällig ist eine enger zeitlicher Zusammenhang, und das auch witzigerweise alternative URLs nicht funktionieren:

[2017-09-25 14:16:47] 404 case: /checkout/confirm - referrer: https://www.stoffkontor.eu/account {"uid":"e85061d"}
[2017-09-25 14:16:47] Trying to fix 404 case: /checkout/confirm [] {"uid":"e85061d"}
[2017-09-25 14:16:49] 404 case: /checkout/confirm/ - referrer: https://www.stoffkontor.eu/account {"uid":"8473cb2"}
[2017-09-25 14:17:38] 404 case: /checkout/confirm - referrer: https://www.stoffkontor.eu/checkout/confirm/ {"uid":"fff1272"}
[2017-09-25 14:17:38] Trying to fix 404 case: /checkout/confirm [] {"uid":"fff1272"}
[2017-09-25 14:17:40] 404 case: /checkout/confirm/ - referrer: https://www.stoffkontor.eu/checkout/confirm/ {"uid":"093779c"}
[2017-09-25 14:20:30] 404 case: /checkout/confirm - referrer: https://www.stoffkontor.eu/AmazonPay/address {"uid":"b8c5396"}
[2017-09-25 14:20:30] Trying to fix 404 case: /checkout/confirm [] {"uid":"b8c5396"}
[2017-09-25 14:20:31] 404 case: /checkout/confirm/ - referrer: https://www.stoffkontor.eu/AmazonPay/address {"uid":"c6ebc68"}

Das mit dem 404 ist natürlich merkwürdig, da der Controller ja nicht einfach verschwinden kann.

Nächste Überlegung: Wir löschen den Cache programmatisch, wenn der Fall auftritt. Das wird die Performance des Shops natürlich nicht wirklich verbessern. :frowning: