@ Moritz Naczenski Läuft es mit
'template_security' => [
'enabled' => false,
],
nach wie vor zuverlässig bzw. stabil? Oder kommt es damit in Verbindung mit dem Cache noch zu Problemen? Weil dann könnten wir es bei uns auch deaktivieren.
Bei uns hatte es mit
'template_security' => [
'enabled' => true,
],
nicht funktioniert und habe es wieder aus der config.php entfernt. Mittlerweile haben wir jedoch vom SW Support noch eine andere Not-Lösung als Test am laufen. Sollte dies stabil funktionieren, wird sich bestimmt Shopware dazu hier melden.
Bei uns hatte es mit
‚template_security‘ => [
‚enabled‘ => true,
],nicht funktioniert und habe es wieder aus der config.php entfernt. Mittlerweile haben wir jedoch vom SW Support noch eine andere Not-Lösung als Test am laufen. Sollte dies stabil funktionieren, wird sich bestimmt Shopware dazu hier melden.
wie schaut die Lösung aus?
Für alle zur Info:
Wir haben es in unserem Shop geschafft, den Fehler in einem Testaccount reproduzierbar zu machen und haben dazu ein Express-Ticket bei Shopware aufgemacht. Mal sehen, was der Support antwortet.
@vppshop wie habt Ihr das geschafft, eventuell könnten wir das dann bei uns auch mal versuchen nachzustellen?
@SwNewbie in unserem Fall ist es eine bestimmte Konstellation aus Produkten und wenn man als Kunde ein anderes Lieferland als Deutschland angibt.
Wenn das Cache leeren lange genug her ist, wirft es zuverlässig jedesmal einen 500er Fehler ohne ausgabe im Frontend.
Habe gerade einen Anruf aus dem 3rd Level Support bekommen - die Antwort insgesamt war etwas ernüchternd: Man könne uns nur weiterhelfen, wenn wir unseren Produktivshop auf das Shopware Standardtheme umstellen und sämtliche Drittanbieter-Plugins deaktivieren. Leider unmöglich für uns, da der Shop damit unbrauchbar ist.
Interessant ist aber, dass bei uns das SwagGoogle Plugin einen Fehler wirft - der Supportmitarbeiter meinte, dass es theoretisch möglich ist, dass dieses Plugin nicht zu SW 5.3 kompatibel ist und in bestimmten Konstellationen mit anderen Plugins den Fehler verursacht.
Wir haben es nun testweise deaktiviert und werden mal sehen, ob der Fehler damit behoben ist.
Eine generelle Empfehlung des Supports ist es, jeweils ein Plugin nach dem anderen zu deaktivieren und zu sehen, ob der Fehler dann irgendwann nicht mehr auftritt. In unserem Fall etwas ungünstig, da einige Plugins für den Betrieb des Shops unverzichtbar sind und nicht deaktiviert werden können - außer man nimmt den Shop komplett vom Netz. Aber vielleicht hilft der Tipp wem anders und bringt uns alle insgesamt weiter 
@SwNewbie in unserem Fall ist es eine bestimmte Konstellation aus Produkten und wenn man als Kunde ein anderes Lieferland als Deutschland angibt.
Wenn das Cache leeren lange genug her ist, wirft es zuverlässig jedesmal einen 500er Fehler ohne ausgabe im Frontend.
Habe gerade einen Anruf aus dem 3rd Level Support bekommen - die Antwort insgesamt war etwas ernüchternd: Man könne uns nur weiterhelfen, wenn wir unseren Produktivshop auf das Shopware Standardtheme umstellen und sämtliche Drittanbieter-Plugins deaktivieren. Leider unmöglich für uns, da der Shop damit unbrauchbar ist.
Interessant ist aber, dass bei uns das SwagGoogle Plugin einen Fehler wirft - der Supportmitarbeiter meinte, dass es theoretisch möglich ist, dass dieses Plugin nicht zu SW 5.3 kompatibel ist und in bestimmten Konstellationen mit anderen Plugins den Fehler verursacht.
Wir haben es nun testweise deaktiviert und werden mal sehen, ob der Fehler damit behoben ist.
Eine generelle Empfehlung des Supports ist es, jeweils ein Plugin nach dem anderen zu deaktivieren und zu sehen, ob der Fehler dann irgendwann nicht mehr auftritt. In unserem Fall etwas ungünstig, da einige Plugins für den Betrieb des Shops unverzichtbar sind und nicht deaktiviert werden können - außer man nimmt den Shop komplett vom Netz. Aber vielleicht hilft der Tipp wem anders und bringt uns alle insgesamt weiter
Das mit dem Lieferland kann ich so bestätigen. Wir haben fast ausschließlich Kundenbeschwerden von nicht Deutschland-Lieferadressen.
Das Entfernen / ausschalten der SmartySecurity und danach Cach leeren sollte eigentlich helfen. Alternativ sollte es helfen wenn ihr in der
Datei: /…engine/Library/Smarty/sysplugins/smarty_security.php
die Methode: isTrustedResourceDir anpasst und einfach ein return true einbaut.
public function isTrustedResourceDir($filepath)
{
return true; //
Zur weitern Fehleranalyse könnt ihr auch das Plugin von shyim installieren: GitHub - shyim/whoops-for-shopware: Whoops for Shopware
Aktuell gehen wir davon aus das dieser Check vor dem hinzufügen der Template Ordner von Plugins läuft und dadurch der Fehler geworfen wird.
Ich probier die Anpassung der smarty_security.php mal aus - der Fehler war nach kurzer Zeit wieder vorhanden, diesmal aber immerhin mit einer sichtbaren Exception im Frontend, die auf exakt dieses Problem hinweist.
…wenns was neues gibt, werde ich berichten
…fazit bis jetzt: läuft
Feedback: Die Not-Lösung über „smarty_security.php“ läuft aktuell seit einigen Tagen ohne Probleme.
Also wir hatten nun das Wochenende über den Cache aus, PayPal Plus deaktiviert und in der Config:
'template_security' => [
'enabled' => false,
],
Damit haben wir auch keinen Fehler mehr erhalten. @R4M habt Ihr den Cache an gelassen und PayPal Plus im Einsatz?
Also es scheint ein reines Timing problem zu sein. Seit dem die Smarty Security eingeschaltet ist fallen diese Fehler erst auf. Solltet ihr die Exception unknown-tag-s bekommen, solltet ihr einmal das oben erwähnte Plugin von ShyIm installieren um die genaue Fehlermeldung zu erhalten. https://github.com/shyim/whoops-for-shopware
Damit könnt ihr die genaue Exception bekommen und die addTemplateDir Methode dementsprechend an die richtige stelle rücken. ( in einem früheren Event aufrufen ) etc.
So solltet ihr den Fehler loswerden.
‘template_security’ => [‘enabled’ => false,], (ist auch nur eine Notlösung). Behandele lieber den Fehler! 
Wenn das Drittanbieter Plugins sind benachrichtigt bitte die Hersteller!!!
@DennisG mit dem Plugin erhalte ich eine Ausgabe aber nur wenn ich den Fehler selbst produziere? In den Logs etc. taucht er dann dennoch nicht auf?
Am Samstagmorgen hatten wir alle Plugins aktiviert (auch die vorher fragilen) und diesen Hinweis umgesetzt. Seither keine einzige SmartyCompilerException mit tag s.
Das Entfernen / ausschalten der SmartySecurity und danach Cach leeren sollte eigentlich helfen. Alternativ sollte es helfen wenn ihr in der
Datei: /…engine/Library/Smarty/sysplugins/smarty_security.php
die Methode: isTrustedResourceDir anpasst und einfach ein return true einbaut.
public function isTrustedResourceDir($filepath)
{
return true; //Zur weitern Fehleranalyse könnt ihr auch das Plugin von shyim installieren: https://github.com/shyim/whoops-for-shopware
Aktuell gehen wir davon aus das dieser Check vor dem hinzufügen der Template Ordner von Plugins läuft und dadurch der Fehler geworfen wird.
Also es scheint ein reines Timing problem zu sein. Seit dem die Smarty Security eingeschaltet ist fallen diese Fehler erst auf. Solltet ihr die Exception unknown-tag-s bekommen, solltet ihr einmal das oben erwähnte Plugin von ShyIm installieren um die genaue Fehlermeldung zu erhalten. https://github.com/shyim/whoops-for-shopware
Damit könnt ihr die genaue Exception bekommen und die addTemplateDir Methode dementsprechend an die richtige stelle rücken. ( in einem früheren Event aufrufen ) etc.
So solltet ihr den Fehler loswerden.
‚template_security‘ => [‚enabled‘ => false,], (ist auch nur eine Notlösung). Behandele lieber den Fehler!
Wenn das Drittanbieter Plugins sind benachrichtigt bitte die Hersteller!!!
Der Fehler tritt allerdings auch bei Shopware-Core-Funktionalität auf, wenn ein 500er ausgelöst wurde. Was nicht grundsätzlich gegen die Timing-Hypothese spricht, aber gelöst werden muss es dann im Core und kann nicht nur auf Plugins geschoben werden.
Ich habe den unknown s-Tag ein Mal ohne jeden vorherigen 500-Fehler in den Logs gesehen. Leider - zum Glück - ist das so selten, dass ich das leider nicht reproduzieren kann und im Live-System auch nicht weiter debuggen kann.
Es könnte sein, dass der CSRF-Schutz involviert ist, da bei den „meisten“ Fällen irgendeine Ajax-Aktion beteiligt ist (Variant, Suche) und IPs aus dem Nummernkreis von Google oder Microsoft.
Nachdem uns eine Kundin informiert hat, dass beim Shop oben „Hi Cornelia“ steht, sie aber „Brigitte“ heißt, habe ich bemerkt, dass die Einstellungen für die Cache Controller falsch sind und wir den SLT nicht berücksichtigt hatten - der Fehler trat immer in Verbindung mit Varianten auf - und eben diesem Token. Nun haben wir die isTrustedRessourceDir geändert, den SLT aus und den Variantenwechsel umgestellt - mal schauen, was heute das Log so spricht. Wir brauchen unbedingt seitens shopware eine Auflistung der Cache Controller - hier ist die Doku für Developer ja nett, aber für Shopbetreiber unzureichend. Ist slt bei euch Teil der Cache Controller? An? Aus?
P.s. Kundin Cornelia war eine der Kunden, die zig mal versucht haben zu bestellen aber nicht weiter kam 
@SwNewbie Ja, leider ist das so. Aber es ich habe gerade einen PR gesehen der dann auch die richtige Fehlermeldung in den Log schreibt. Somit sollte im nächsten SW Patch dann auch die richtige Fehlermeldung im Log stehen
@SwNewbie
Also wir hatten nun das Wochenende über den Cache aus, PayPal Plus deaktiviert und in der Config:
‚template_security‘ => [
‚enabled‘ => false,
],Damit haben wir auch keinen Fehler mehr erhalten. @R4M habt Ihr den Cache an gelassen und PayPal Plus im Einsatz?
Um die Frage zu beantworten: Ja Cache ist aktiv und Paypal Plus haben wir gar nicht im Einsatz.
