Ich wiederhole mich gern noch mal, ich glaube nicht an ein Plugin Problem! Der Fehler hat Methode.
Das ist ein SW Problem auch wenn in Shöppingen die Erde wackelt. Aber ich glaube das nehmen die Mädels und Jungs sportlich… 
Wenn überhaupt, dann haben die vermuteten Plugins etwas Gemeinsames was den Fehler triggert und dann sind wir wieder bei SW, bzw. den Richtlinien der Pluginentwicklung.
Verflixt, was läuft denn hier anders als im Livesystem?
Das hab ich mich nun schon 3 Tage gefragt 
Vermutlich kann man Fehler verursachen, wenn man Plugins deaktiviert, deinstalliert oder an den Einstellung zum Cache etwas ändert, ohne dabei aber den Cache komplett zu leeren. Aktuell hab ich so einen Zustand.
Aber für heute hab ich die Schnautze voll …
Bis jetzt lese ich ja nur - wenn es auch erst 3 sind - nginx
SW könnte ja mal sagen, was “diesen” Fehler bei diversen untersuchten Problemen getriggert hat.
Ich bleibe dabei: Irgendwas mit dem Smarty-Cache und Raceconditions/Schreib-Leseprobleme, die keinen direkten Fehler werfen, dann aber im Template den Fehler triggern.
PHP Version 7.0.24 Apache zur Berechnung und Nginx als Reverse-Proxy-Server
MySql 5.5.56
Die Sache mit dem Smarty Cache ist auch für mich eine durchaus nahe liegende Ursache.
Letztlich mündet der Fehler ja immer wieder im veränderten Template welches mit Cache leeren wieder hergestellt wird und egal was im Hintergrund den Fehler erzeugt ist ja immer noch vorhanden.
Wenn es ein “Code”-Fehler in einem Plugin wäre - also z.B. Security von smarty - würde der Fehler ja IMMER auftreten und reproduzierbar sein, ein *bischen* Fehler gibt es nicht.
Möglich auch, dass unter gewissen Bedingungen - ESI ? - SW nicht vollständig initialisiert wird, und smarty die SW-Erweitrung “S” nicht “bekanntgemacht” wird.
Wie auch immer - das *stinkt* nach einem SW-Laufzeitproblem, somal es ja erst mit 5.3.x gekommen ist, aber wiederum nicht alle betrifft.
Die Gemeinsamkeiten heisst es nun zu erkennen 
bei uns ist es definitiv PayPal plus…
wenn aus ist läuft es…
Habe mich beschwert bei PayPal - Antwort: das Modul macht jetzt Shopware wir müssen uns an die wenden…
Dann mach mal ein Artikel mit WB = 0 , bin gespannt …
SW könnte ja mal sagen, was „diesen“ Fehler bei diversen untersuchten Problemen getriggert hat.
Unterschiedliche Plugins die das Theme nicht nach Konventionen erweitern und/oder das Theme-Verzeichnis nicht korrekt registrieren.
Die Probleme die wir auf dem Tisch hatten, warem aber sowas wie „Meine Formulare werfen immer diesen Fehler“ oder „Der komplette Checkout funkioniert nicht“. Also schon die gleiche Fehlermeldung aber nicht sporadisch auftretend.
Am besten legt ihr mal ein Ticket für den Core an und dann schau ich mal, dass dort ein Entwickler da mal draufschaut. Habe bisher nur eines für Paypal Plus gefunden, aber dann wäre es ja auf das Plugin reduziert.
[@Moritz Naczenski](http://forum.shopware.com/profile/14574/Moritz Naczenski „Moritz Naczenski“) wir haben kein Paypal (Plus) installiert und es tritt trotzdem genau das gleiche Problem auf. Das mit dem WB <= 0 muss ich mal testen.
Installation läuft übrigens unter PHP 5.6, MariaDB 10 auf Apache 2.4. @sonic NGINX würde ich somit nicht als Ursache sehen, die Lock-Problematik sieht da leider schon vielversprechender aus…
Dann melche ich mich als Threadersteller auch mal wieder.
Also, ich kann bei uns definitiv einen Zusammenhang zwischen PayPal Plus und dem Fehler ziehen. PP Plus deaktivert und eine Woche lang keine Fehler mehr im checkout gehabt (nur noch die Fehler mit der Fehlerseite). PP Plus aktivert und keine 3 Stunden später rasselt es 500er Fehler mit weißen Seiten beim checkout.
Wir setzen einen eigenen Server ein
Apache 2.4.7
Nginx 1.11.10 als reverse proxy davor
php 7.0.24
mysql 5.5.57
Trotzt Support Vertrag wurde eine Berbeitung seitens Shopware abgelehnt und ich hier auf das Forum verwiesen.
Auf Empfehlung von Moritz habe ich dann mal ein Ticket angelegt
https://issues.shopware.com/issues/SW-20183
@ronecker kann ich bestätigen PayPal Plus abgeschaltet und ich habe auch keinen Fehler mehr schon über 24h vorher war das alle 3 Stunden der Fall!
Der Ursprung ist definitiv aus mehreren Faktoren zusammengesetzt, die Sache mit PayPal Plus mag das eine sein, allerdings hat einer der massiv betroffenen Live-Shops das PayPal Plus nicht installiert und crasht leider massiv. Die Shops sind so nicht weiter zu betreiben - mit der aktuellen Release macht ein betroffener Shop nur noch 3% seines regulären Umsatzes und die Telefone klingeln heiß. Also, hier besteht mehr als Handlungsbedarf. Zu den Fakten:
PHP 7.0.18 unter nginx nginx 1.10.1, ACPu 5.1.8 und ZendCache an, DB unter mysqlnd 5.0.12-dev.
Im Moment hilft nur das Deaktivieren des Caches und somit des Produktivmodus, denn mit Cache kann ich alle hier bereits genannten Aussagen mit ja unterstreichen.
Zum Entstehen des Fehlers, besser noch: der Fehler:
Der Shopbetreiberin ist nach dem Update auf 5.3.3 sehr früh aufgefallen, dass die Lagerbestände nichtmehr richtig laufen und über API (Amazon und real) importierte Bestellungen nichtmehr in Statistiken auftauchen bzw. einen fehlerhaften Bestand produzieren. Da die Bestände nicht kleiner 0 werden dürfen, kam es massiv zu Überverkäufen (Artikel auf Bestellung via $order rein, Bestellung abgefertigt und weil die Artikel dann auf den Marktplätzen nichtmehr verfügbar waren gab es viele Order direkt im Shop - aber wenn Du nur 10 Stück von dem Ding hast, dann ist es schwer, 15 Stück zu liefern).
Der Fehler ist heute noch nachvollziehbar, da die Artikelstatistiken nach wie vor falsch laufen. Wir haben sodann die Entwickler der verschiedenen Plugins kontaktiert. Zuerst die Amazon-Anbindung, Bestellung kommt via API rein, es gibt einen Event ExternalOrder_… und hier scheint der erste Fehler zu passieren und in einem falschen Bestand zu resultieren, bzw. in einem Fehler der Artikelstatistiken (vielleicht ist auch hier der Fehler), wir haben sodann den Entwickler eines Plugins für Lagerbestandsprotokollierung eingeschalten, da hier die Bestände wiederrum anders falsch liefen als jene im Stock selbst. Die Betreiberin konnte (bedingt duch gewissenhafte Lagerstandshaltung mit Papier und Stift) die Fehler definieren. Der Entwickler hat uns vor wenigen Tagen darauf hingewiesen, dass wir wohl einen Bug im Core gefunden haben. Aber wir glauben an unsere Mädels und Jungs in Schöppingen (und das schon seit Shopware 3.5 
- nur nützt uns das nichts, denn das Spiel geht weiter.
Bei Warenbeständen mit 0 crasht der Shop. Der Abgleich des Bestandes passt wohl nicht (der ja eigentlich nicht gecasht werden soll) und es gibt den Fehler oder es liegt daran, dass man sich mit der Benachrichtigungsfunktion den Fehler ins Haus holt. Ich denke eher Punkt 1. Und hier ist unser Ansatz: Verkäufe oder Manipulationen am Bestand der Artikel werden falsch in der DB bzw. im Cache verankert, bei dem Trigger, dass ein anderer Kunde, eine andere IP den Artikel aufrufen/kaufen will und ja der Wert auf ArticleStock ausgegeben werden muss, schiesst sich Smarty ab, denn welche Menge sollst Du denn nun darstellen? Da wäre der unknown Tag S :).
Diesen Workaround könnte man in einer Staging-Umgebung niemals darstellen. Seltsam: Das Ganze funktioniert aber, solange man den Cache deaktiviert. Hier unsere 2. These: Es Teil der Stocks werden mitgecasht oder nicht richtig freigehalten. Würde auch zum Problem mit den Zahlungsplugins passen, denn wenn Du von PayPal wieder zurück kommst, müsste der Artikel nen anderen Bestand bekommen - hm, ist hier evtl. der Bug? Wir wissens nicht.
Da war doch noch was - eine nette Fehlermeldung beim Versuch das Plugin für die Bestandsprotokollierung zu entfernen und hier könnte man auch fündig werden:
A new entity was found through the relationship ‘Shopware\Models\User\Rule#resource’ that was not configured to cascade persist operations for entity: Shopware\Models\User\Resource@00000000192cc5b30000000036ee4dc5. To solve this issue: Either explicitly call EntityManager#persist() on this unknown entity or configure cascade persist this association in the mapping for example @ManyToOne(…,cascade={“persist”}). If you cannot find out which entity causes the problem implement ‘Shopware\Models\User\Resource#__toString()’ to get a clue.
Nachvollziehbare auffällige Symptome seit Bestehen des Fehlers in mehreren Shopinstallationen unter gleichen Servervariablen:
Das Backend ist teilweise nichtmehr nutzbar, sieht aus ein Grafikfehler Seitenaufbau katastrophal trotz perfomanter Hardware. Diese Problematik resultiert aus dem eingeführtem Feature, damit permanent gecheckt wird, was die Benutzer im Backend so treiben und sich nicht in die Quere kommen. Es gab dazu hier schon einen Thread sowie ein Ticket welches abgelehnt wurde. Aber der Fehler ist zu 100% parallel mit dem Problem zum Produktivsystem im Frontend 
Das Plugin Backend Bestellung (sogar als Update in der aktuellen Version) verursacht den Fehler bei Produktivsystem ad hoc. Also Im Backend Bestellung anlegen über einen Artikel. Der Artikel wird 5 Minuten später im Frontend aufgerufen: Shop ist platt. Na, ist es vielleicht doch der Bestand? Oder ein anderer Controller?
Andere im Forum aufgetauchte Fehler kann ich reproduzieren, indem eben z.B. die Smartys nicht ganz richtig in dem einen oder anderen Plugin aufgerufen werden, meistens sind es |rewrite: und solche Sachen, aber auch ein append an eine index.tpl (wurde hier auch genannt, schiesst den Shop ab - das ist aber nicht das eigentliche Problem)
Mit Cache aber hält länger durch: Das Deaktivieren der template_security in der Config.php sorgt somit für ein gefühltes längeres Leben des Shops. Damit umgeht man aber nur die eben angesprochenen klassischen Fehler und Schreibweisen - ich glaube nicht, dass das responsive oder bare theme keinen append oder prepend mehr hat (nur ein kleiner Wink mit dem Zaunpfahl)
Oder ganz ganz ganz was andere: Das Problem resultiert evtl. auch schon aus einerer früheren Geschichte - in einer anderen Installation gab es seit dem Sicherheitsupdate 5.2.25 ziemlich ähnliche Probleme im Handling - evtl. wurde hier etwas übersehen? Das war dann schon Ende Juni?
Ich habe auf Github gesehen, dass sich die letzten Commits mit der API befassen und überlege ernsthaft, einen der Live-Shops mit der Git-Version zu betreiben, schlimmer kann es für die Shopinstallationen fast nichtmehr werden und wir müssen entweder auf ein gutes Weihnachtsgeschäft hoffen oder ein paar Leute suchen sich neue Jobs.
Jedenfalls auch seltsam: in einem 5.2er Shop, der seit Juli unangetastet ist, tauchen seit 6. Oktober 2017 CSRF Fehler auf - gab es am 6ten Oktober irgendwas, was die Welt wissen muss? Ab wann sind eigentlich die ersten unknown S aufgetaucht? Frohe Fehlersuche, ich hoffe, ich konnte helfen - wir sind selbst am Verzweifeln
Ich mach weiter damit man dem Fehler auf die Schliche kommt und wir seit der 5.3er Version damit kämpfen hier weitere Hinweise an die Profis:
einer der ersten Fehlerszenarien wurde am 29. September begleitet von folgender Fehlermeldung (damit ist eine Weltuntergangsthese für den 6ten Oktober ausgeschlossen)
Enlight_Controller_Exception: Unauthorized in /engine/Shopware/Plugins/Default/Backend/Auth/Bootstrap.php:209 Stack trace:
#0 /engine/Library/Enlight/Event/Handler/Plugin.php(149): Shopware_Plugins_Backend_Auth_Bootstrap->onPreDispatchBackend(Object(Enlight_Controller_ActionEventArgs))
#1 /engine/Library/Enlight/Event/EventManager.php(214): Enlight_Event_Handler_Plugin->execute(Object(Enlight_Controller_ActionEventArgs))
#2 /engine/Library/Enlight/Controller/Action.php(136): Enlight_Event_EventManager->notify(‘Enlight_Control…’, Object(Enlight_Controller_ActionEventArgs))
#3 /engine/Library/Enlight/Controller/Dispatcher/Default.php(530): Enlight_Controller_Action->dispatch(‘getTurnOverVisi…’)
#4 /engine/Library/Enlight/Controller/Front.php(223): Enlight_Controller_Dispatcher_Default->dispatch(Object(Enlight_Controller_Request_RequestHttp), Object(Enlight_Controller_Response_ResponseHttp))
#5 /engine/Shopware/Kernel.php(189): Enlight_Controller_Front->dispatch()
#6 /vendor/symfony/http-kernel/HttpCache/HttpCache.php(491): Shopware\Kernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true)
#7 /engine/Shopware/Components/HttpCache/AppCache.php(268): Symfony\Component\HttpKernel\HttpCache\HttpCache->forward(Object(Symfony\Component\HttpFoundation\Request), true, NULL)
#8 /vendor/symfony/http-kernel/HttpCache/HttpCache.php(258): Shopware\Components\HttpCache\AppCache->forward(Object(Symfony\Component\HttpFoundation\Request), true)
#9 /engine/Shopware/Components/HttpCache/AppCache.php(105): Symfony\Component\HttpKernel\HttpCache\HttpCache->pass(Object(Symfony\Component\HttpFoundation\Request), true)
#10 /var/www/clients/client7/web10/web/shopware/shopware.php(118): Shopware\Components\HttpCache\AppCache->handle(Object(Symfony\Component\HttpFoundation\Request))
#11 {main}
In SW 5.3 wurde SW-14197 migriert - wurde das sauber und fehlerfrei gemacht? Beruht die Problematik darauf? Wäre auch nie im einem Staging nachvollziehbar
Auf geht´s - zusammen finden wir den Bug :), Liebe Grüße und gute Nacht, ich träum von den Smarties (die kleinen süßen, nicht die unkown tag)
Jürgen
Viele Sachen die du oben erwähnst haben sicherlich nichts mit dem Fehler der hier geschildert wird zu tun.
Die meisten Dinge wirst du dir daher individuell ansehen müssen. Den “Unkown Tag S” Fehler können wir uns sicherlich mal genauer ansehen, dazu gibt es jetzt das Ticket.
Hallo @ronecker
könnt ihr das System ohne den Reverse Proxy betreiben und/oder seid ihr sicher für diesen alles korrekt konfiguriert zu haben? Es kann auch zu unerwarteten Problemen kommen, wenn man z. B. den Opcode Cache ausschließlich auf Performancemaximierung konfiguriert.
Probleme mit einem ngnix-Proxy habe ich schon öfters bei Kunden gesehen.
Jedenfalls auch seltsam: in einem 5.2er Shop, der seit Juli unangetastet ist, tauchen seit 6. Oktober 2017 CSRF Fehler auf - gab es am 6ten Oktober irgendwas, was die Welt wissen muss? Ab wann sind eigentlich die ersten unknown S aufgetaucht?
Frohe Fehlersuche, ich hoffe, ich konnte helfen - wir sind selbst am Verzweifeln
Was bedeutet denn „es tauchen Fehler auf“. Wenn es das Ticket ist, kann es auch einfach irgendein Bot/Tool sein, welches den Link abfragt und den CSRF-Fehler auslöst. In dem Fall wäre es kein Fehler und der Shop könnte einfach erst am 6.10. auf der „Bot-Liste“ gelandet sein. So etwas sehe ich auch immer wieder.
Zu dem Grafikfehler: Wie äußert der sich? Ich sehe seit einem GoogleChrome-Update vor wenigen Tagen/Wochen - habe leider nicht genau aufgepasst - immer wieder grüne semitransparente Felder (aus Qudraten aufgebaut) in den Statistik-Widgets des Backend blinken. Nach einem Reload oder in Firefox sind die wieder weg.
Mit der Sache „PayPal Plus“ kann ich nicht bestätigen. In einer Testumgebung wo alle möglichen Plugins deinstalliert sind, tritt dennoch der Fehler auf. Zumal wir nur „Paypal“ haben, nicht PayPal Plus.
Bei uns trat es auch ohne PayPal Plus auf (nur mit normalem PayPal).
Zum Testen:
[URL gelöscht]
Erklärung:
Die Umgebung befindet sich aktuell im Wartungsmodus. Ich mit meiner IP kann den Inhalt vom erwähnten Link ganz normal anzeigen lassen. Benutze ich aber einen Tor-Browser mit einer Proxy-IP, bleibt die Seite Weiß und im error_log steht der Fehler „Unkown Tag S“. Würde ich jetzt den Cache leeren, dann wäre der Fehler weg. Aber ich lasse es mal so.
Wie kann das sein?
Guten Morgen,
jetzt aber auch ordentlich Voten! Der BUG muss weg!
https://issues.shopware.com/issues/SW-20183
Offensichtlich hat unser unbekannter „Freund“ viele Gesichter bzw. greift wohl komplexer in das Geschehen ein als uns lieb sein kann. Irgendwie bekommt der Unknown „s“ tag ja schon was Bedrohliches ….
