PHP Fatal error:
Uncaught exception 'SmartyCompilerException' with message 'Syntax Error in template
"/var/.../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/.../engine/Library/Smarty/sysplugins/smarty_internal_templatecompilerbase.php:657
In einem SW 5.3.3 haben wir bei einem Kunden nun auch diese Fehlermeldung und ich suche mir seit Tagen einen Wolf nach der Ursache. Im Shop selber sind KEINE inkompatiblen Plugins installiert. Alle Plugins (und das sind ganz wenige) sind auf aktuellen Stand. Leider tritt immer spoardisch diese nervige Fehlermeldung (unknown tag “s”) im System auf. Die Seite des Artikels bliebt weiß. Es sind immer nur bestimmte Artikel die es betrifft. Ein Zusammenhang ist (noch) nicht erkennbar. Nach dem Cache leeren ist der Fehler in der Regel wieder weg, tritt aber irgendwann wieder auf. Testhalber haben wir in der config.php auch “‘enabled’ => true” eingetragen. Leider ohne jeglichen Erfolg.
Langsam geht mir das sowas von auf den … Sorry
Was kann ich noch tun um diesem Mist entlich ein Ende zu setzen?
Ihr könnt bei großen Problemen die Smarty-Security auch als temporäre Lösung komplett deaktivieren in der config.php:
‚template_security‘ => [
‚enabled‘ => true,
],
Empfiehlt sich aber nur, als temporäre Lösung, bis ihr in euren Testumgebungen den Übeltäter gefunden habt.
Wir haben die Empfehlung als temporäre Lösung genutzt (übrigens kein PayPal installiert…), was auch die letzten Tage den Fehler endlich ausgeschaltet hat. Doch heute morgen ist der trotzdem wieder aufgetreten.
Gibt es keine Möglichkeit, die Smarty-Kompilierung direkt beim Fehler „crashen“ zu lassen? Scheinbar wird ja der Tag gar nicht erst geladen oder wieder gelöscht, da sollte ja der Fehler vor der Meldung im Log auftreten.
Ich tippe ja eher auf einen BUG im http-cache. Hab zwar nicht so viel Traffic, aber auch keine “S”-Fehler - allerdings habe ich auch den HTTP-Cache deaktiviert, was bei “wenig” Traffic den Shop eh schneller macht. Mit “HTTP-Cache” aktiviert hab ich oft Fehler, weil der Timeout für das Filesystem etwas knapp bemessen ist.
Der Fehler scheint auch nicht umbedingt im “S”-Tag zu sein, sondern ein paar Code-Stellen früher. Ich vermute so eine Art Kombination aus ESI-Tag und “S”-Regexpression.
Edit: Nee - nochmal nachgedacht: Passt nicht so ganz:
Wenn “Cache löschen” für eine gewisse Zeit hilft, wird es was mit dem Smarty-Cache zu tun haben können. Damit Textbausteine selber wieder Smarty abarbeiten können, müssen sie ja durch den Compiler gejagt werde. mit “Include string:” wird der Inhalt gerendert und mit einem Hash aus dem Inhalt vom gerenderten Textbaustein im Cache abgelegt und includet. Auch wenn es nur “einmal” verwendet wird, bleibt es bis zum Cache Leeren vorhanden und wird ggf. überschrieben. Möglich wäre also auch, dass hier beim Überschreiben ein Fehler entsteht oder ein Datei-Limit in einem Verzeichnis erreicht wird.
Ich habe bisher keinen blassen Schimmer woher das kommt. Ich weiß nur, nach dem Cache leeren (nicht über Cronjob, sondern manuell) ist der Fehler weg. Und den Fehler sehe ich nur bei Produkten deren Lagerbestand 0 oder -1 ist.
Ich habe bisher keinen blassen Schimmer woher das kommt. Ich weiß nur, nach dem Cache leeren (nicht über Cronjob, sondern manuell) ist der Fehler weg. Und den Fehler sehe ich nur bei Produkten deren Lagerbestand 0 oder -1 ist.
Das mit dem Lagerbestand können wir für einen unserer Shops bestätigen - wenn wir das betreffende Produkte auf einen Lagerbestand größer 0 setzen tritt der Fehler nicht mehr auf, setzt man direkt anschließend zurück auf 0 oder -1 ist der Fehler wieder da. Auch wir suchen bereits seit mehreren Tagen den Fehler und kommen nicht weiter…
ich bin jetzt ca 24h Fehlerfrei bei mir scheint es mit PayPal Plus zusammen zu hängen. PayPal Plus jetzt deaktiviert und jetzt kommt der Fehler nicht mehr.
Habt ihr PayPal Plus laufen?
ich reihe mich mal mit in die Runde der geplagten “unknown tag s” User mit ein. Habe schon viele graue Haare und durch die Fehlersuche werden es immer mehr. Witzig ist, dass in der Tat dieser Fehler nur bei Produkten auftritt, deren Lagerbestand kleiner 1 zu seien scheint. Aktuell läßt sich nciht erkennen, ab welchem Zeitpunkt dieser Fehler vorkommt. Er tritt sehr sporadisch auf. Und nach dem Cache leeren (also übers Backend per Hand) ist er wieder weg.
[Nachtrag]
Ich habe versucht das Problem auf einer 1:1 Testumgebung nachzustellen. Ich kann machen was ich will, aber dort tritt der Fehler nicht auf. Was ich davon halten soll weiß ich nicht.
ich hatte den Fehler immer beim zurück leiten von PayPal zum Shop dann kommt eine komplett weiße Seite bis ich den Cache leere (deshalb leere ich aktuell alle 5Minuten Cache per Cron bringt nur bedingt was…)
Das hat Bestellungen ohne Ende gekostet ca 10 Stück am tag…
Jop, das war auch der Fehler bei vielen anderen wenn es von PP zurück zum Shop geht.
Jedoch sind PP und PP-Plus Core Plugins daher sollte so etwas nicht sein.
Ich glaube der Verweis auf die “smarty_internal_templatecompilerbase.php” sind Folgefehler, aber nicht die Ursache. Leider kann man mit der Fehlermeldung rein gar nichts anfangen.
Ich habe gerade eine pp+ Bestellung gemacht, Rechnung, KK, PP soweit o.k. wenn ich den regulären PP Weg zurück gehe, auch wenn wenn ich im Browser zurück gehe kein Problem…
Kann denn mal jemand die Sache mit dem WB = 0 oder auch WB < 0 bestätigen ? Ich will mich ja nicht darauf festlegen, aber mindstens bei 3 Leuten ist das die bisher gemeinsam gefundene Ursache.
Abgesehen davon, warum taucht das Problem auf unserem Testserver wie auch bei 4RAM nicht auf ?
Der Fehler tratt immer nur bei bestimmten Artikeln auf (jedenfalls in der Live-Umgebung). Wir konnten das nachvollziehen, nachdem wir bei einem besagten Artikel ohne den Cache zu lerren den Lagerbestand auf 1 gesetzt hatten. Dann war der Fehler weg! Dann wieder auf 0 gesetzt => Fehler wieder da. Cache geleert => Fehler weg. Also langsam geht mir auch der Mist auf den Sack!
Warum der Fehler auch bei unserer Testumgebung nicht vorkommt, ist mir ein völliges Rätsel. Die Testumgebung ist eine 1:1 Kopie der Live-Umgebung in einem Unterverzeichnis. Es herschen also die selben Bedingungen. Der einzige Unterschied ist die URL.
Offensichtlich ist das kein Plugin Problem oder sonst irgendein User Problem! Das kann nur ein SW BUG sein!
Bis vor dem gestrigen 5.3.3 Livegang hatten wir keine Probleme, seit Juni monatelang auf alle Plugin Updates gewartet, vorab getestet, die sensible SW Lady bloß nicht verärgern und jetzt dieser Salat. Ein Downgrade ist ja leider nicht möglich. Ich habe nicht die Absicht weiter mit der Stange im Nebel zu stochern schon gar nicht wochenlang …
Also bitte liebes SW Team, nehmt euch des Problems an!
Mit “HTTP-Cache” aktiviert hab ich oft Fehler, weil der Timeout für das Filesystem etwas knapp bemessen ist.