Ich weiß nicht ob es von Bedeutung ist, aber langsam vermute ich, immer wenn der Shop ein Error 500 ausgibt, steht auch die selbe Fehlermeldung “unknown tag s” in Log. Wie ich darauf komme?
Eben versuche ich ein Template anzupassen. Hier wollte ich per Include ein anderes TPL einbinden was sich jedoch im selben Theme befindet. Hat nicht funktioniert. Der Shop brach mit Error 500 ab. Witzig ist die Fehlermeldung im error_log, genau “unknown tag s”. Hier hätte ich jetzt eine andere Fehlermeldung erwartet, wie File nicht gefunden oder sonstiges. Aber “unknown tag s” in diesem Zusammenhang?
Das ist etwas sehr komisch! Hat hier schlichtweg die Fehlerausgabe (Error handling) von Shopware eine Macke? Kann es sein, dass bei bestimmten Fällen nicht die eigentliche Fehlermeldung ausgegeben wird, sondern selber diesen “tag s” Fehler verursacht?
Ich weiß nicht ob es von Bedeutung ist, aber langsam vermute ich, immer wenn der Shop ein Error 500 ausgibt, steht auch die selbe Fehlermeldung „unknown tag s“ in Log. Wie ich darauf komme?
Eben versuche ich ein Template anzupassen. Hier wollte ich per Include ein anderes TPL einbinden was sich jedoch im selben Theme befindet. Hat nicht funktioniert. Der Shop brach mit Error 500 ab. Witzig ist die Fehlermeldung im error_log, genau „unknown tag s“. Hier hätte ich jetzt eine andere Fehlermeldung erwartet, wie File nicht gefunden oder sonstiges. Aber „unknown tag s“ in diesem Zusammenhang?
Das ist etwas sehr komisch! Hat hier schlichtweg die Fehlerausgabe (Error handling) von Shopware eine Macke? Kann es sein, dass bei bestimmten Fällen nicht die eigentliche Fehlermeldung ausgegeben wird, sondern selber diesen „tag s“ Fehler verursacht?
Zumindest kann es ein Folgefehler eines 500er sein. Ich habe einen Fall in den Serverlogs gefunden, bei dem nach mehrfachem Artikel in den Warenkorb legen und Artikel im Ajax-Warenkorb wieder löschen ein 500er Fehler beim Zurückgehen zum Artikel entstanden ist. Auf den folgt dann direkt ein unknown s-tag Fehler auf der Error-Template-Seite. Wobei diese komplett unverändert ist und der entsprechende Textbaustein ebenfalls. Der nächste unknown s-tag entsteht anschließend auf der Artikeldetailseite zu der vom Warenkorb zurückgekehrt wird.
Der Shop funktioniert offensichtlich dennoch. Auch die Artikeldetailseite (ist eine Variante) wurde von derselben IP später erneut angesprochen. Die IP hat später weiter Artikel in den Warenkorb gelegt und auch den kompletten Checkout durchlaufen und erst auf der Paypal-Seite abgebrochen (wahrscheinlich Kauf auf Rechnung). Parallel waren andere IPs aktiv.
Wo seht ihr eigentlich die Fehler? Beide oben beschriebenen Fehler sind bei dem Shop nicht im Shopware-Log gewesen.
Könnt ihr das eigentlich auf einen Gerätetyp anhand der Logfiles zurückverfolgen - hier war es ein Android7-System
Das ist etwas sehr komisch! Hat hier schlichtweg die Fehlerausgabe (Error handling) von Shopware eine Macke? Kann es sein, dass bei bestimmten Fällen nicht die eigentliche Fehlermeldung ausgegeben wird, sondern selber diesen „tag s“ Fehler verursacht?
Ja, dass vermute ich aktuell auch. Ich glaube es ist eher eine Macke am Errorhandling, was viele einzelne Fehler versteckt und weniger ein allgemeines Ding. Habe hier gerade ein Plugin was ebenfalls diesen Fehler verursacht, sobald man das Errorhandling ersetzt und sich die Exeption direkt im Errorhandler ausliest, bekommt man auch einen anderen Fehler. Bei mir hilft es aber auch konkret, die Smarty Security zu deaktivieren:
'template_security' => [
'enabled' => false,
],
Das hat aktuell aber noch den Nachteil, dass dann die Dokumentenerstellung im Backend nicht funktioniert, dazu gibt es einen Pull-Request:
Funktioniert aber wahrscheinlich nur, wenn die zugrundeliegende Fehlermeldung auch ein Security-Error ist.
so, also auch wir nun dabei… gestern von 5.2.24 auf 5.3.3 gegangen und zack… haben wir den Salat… auf die Schnelle nur getestet: PAYPAL PLUS aktiv, Artikel mit Bestand 0 via Vorauskasse bestellt, nach Abschluss weiße Seite mit Status 500. Dann Paypal Plus deaktiviert, den gleichen Artikel wieder auf Bestand 0 gesetzt und wieder per Vorauskasse bestellt und alles lief glatt.
2017/10/18 16:08:30 [error] 10627#10627: *351154 FastCGI sent in stderr: "PHP message: PHP Fatal error: Uncaught exception 'SmartyCompilerException' with message '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/sy" while reading response header from upstream, client: 217.7.241.85, server: domain.de, request: "POST /checkout/finish HTTP/1.1", upstream: "fastcgi://unix:/var/lib/php5-fpm/web2.sock:", host: "www.domain.de", referrer: "https://www.domain.de/checkout"
2017/10/18 16:08:37 [error] 10620#10620: *351187 FastCGI sent in stderr: "PHP message: PHP Fatal error: Uncaught exception 'SmartyCompilerException' with message '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/sy" while reading response header from upstream, client: 217.7.241.85, server: domain.de, request: "GET /checkout/finish HTTP/1.1", upstream: "fastcgi://unix:/var/lib/php5-fpm/web2.sock:", host: "www.domain.de"
2017/10/18 16:08:39 [error] 10620#10620: *351187 FastCGI sent in stderr: "PHP message: PHP Fatal error: Uncaught exception 'SmartyCompilerException' with message '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/sy" while reading response header from upstream, client: 217.7.241.85, server: domain.de, request: "GET /checkout/finish HTTP/1.1", upstream: "fastcgi://unix:/var/lib/php5-fpm/web2.sock:", host: "www.domain.de"
es scheint ja was mit dem “/themes/Frontend/Bare/frontend/index/index.tpl” zu tun haben, an der betreffenden Zeile steht ein
Das funktioniert leider nicht - dann meckert er an dem nächsten Textbaustein rum. Das hatte ich so ziemlich als erstes getestet… Hat nichts gebracht bei mir
Vielleicht können wir dann diesen problematischen „tag s“ umgehen.
Das wurde schon versucht, der Fehler entsteht dann direkt beim nächsten s-Tag. Wenn es so einfach wäre, dann würden wir hier vermutlich nicht seit Monaten rumeiern…
Ich habe mehrfach versucht etwas über ihren Online Shop zu bestellen, aber beim Übergang zur Zahlung, ebenfalls bei “direkt zu Paypal”, landet man auf einer weissen Seite. Safari und Chrome Browser.
@SwNewbie Das hat jetzt allerdings gar nichts mit dem besprochenen Verhalten, welches hier behandelt wird, zu tun.
Es wäre daher super, wenn wir uns hier wirklich auf das eine Thema beschränken könnten
Das ist etwas sehr komisch! Hat hier schlichtweg die Fehlerausgabe (Error handling) von Shopware eine Macke? Kann es sein, dass bei bestimmten Fällen nicht die eigentliche Fehlermeldung ausgegeben wird, sondern selber diesen „tag s“ Fehler verursacht?
Ja, dass vermute ich aktuell auch. Ich glaube es ist eher eine Macke am Errorhandling, was viele einzelne Fehler versteckt und weniger ein allgemeines Ding. Habe hier gerade ein Plugin was ebenfalls diesen Fehler verursacht, sobald man das Errorhandling ersetzt und sich die Exeption direkt im Errorhandler ausliest, bekommt man auch einen anderen Fehler. Bei mir hilft es aber auch konkret, die Smarty Security zu deaktivieren:
‚template_security‘ => [
‚enabled‘ => false,
],
Das hat aktuell aber noch den Nachteil, dass dann die Dokumentenerstellung im Backend nicht funktioniert, dazu gibt es einen Pull-Request:
Funktioniert aber wahrscheinlich nur, wenn die zugrundeliegende Fehlermeldung auch ein Security-Error ist.
Das Problem mit der Dokumentenerstellung gibt es auch in Verbindung mit Pickware und dem PayPal Ratenzahlung-Plugin in Verbindung mit Pcikware. Hier ist es auch so, dass auf einmal nach einem undefinierbarem Zeitraum kein Rechnungsdruck mehr möglich ist. Wird das Plugin PayPal Ratenzahlung deaktiviert funktioniert die Rechnungserstellung auf einmal wieder.
Aktueller Statuts: wir haben gestern um 17:34 Paypal Plus abgeschaltet und dazu unter “Einstellungen -> Performance -> Einstellungen -> HTTP-Cache”
httpCache deaktiviert
Automatische-Cache-Unvalidierung deaktiviert.
Dadruch ist der Shop in den Bearbietungsmodus gegangen und die error.log vom Server hat keinen Fehler mehr aufgezeichnet. Wir werden weiter beobachten.
FastCGI sent in stderr: "PHP message: PHP Fatal error: Uncaught exception 'SmartyCompilerException' with message 'Syntax Error in template "/var/www/clients/client1/web2/web/themes/Frontend/Bare/frontend/index/index.tpl" on line 7
Jetzt um 10:11 PayPal Plus deaktiviert… Ich weiß das haben andere auch schon getestet und probiert, nur hier kann das scheinbar auch nachgestellt werden.
Das mit dem PayPal Plus halte ich in diesem Falle nur für den Auslöser einer (anderen) Fehlermeldung, jedoch aber NICHT die Ursache zum eigentlichen Problem. Wer die Beiträge hier verfolgt hat, erkennt auch, dass der “tag s” Fehler bei ganz unterschiedlichen Gegebenheiten statt fand. Meine (aktuelle) Vermutung liegt immer noch beim Errorhandling vom Shop selber und ggf. in Verbindung mit dem Cachehandling. Dieser “tag s” Fehler ist vermutlich nur ein Folgefehler, jedoch aber nicht der Fehler der eigentlich kommen sollte. Vermutlich ist dieser “tag s” Fehler zur Standardmeldung mutiert, wenn irgendwo ein Error 500 auftritt, oder wird automatisch zum Error 500
