Hallo,
wir haben seit Freitag auch die vorgeschlagene Änderung in der _ smarty_security.php _ eingebaut, seitdem keine Fehler mehr, zumindest noch nicht….
Nur als Info, PayPal Plus war bei uns immer aktiv und hat zumindest bei uns den „s“ Tag nicht verursacht.
Die Frage ist jetzt aber, ist das nun nur eine Notlösung oder die Lösung des Problems?
Hans
Das ist natürlich nur eine Notlösung… Wird bei einm Update wieder überschrieben. Ihr solltet wenn dieser Fehler reproduzierbar ist die Shopware Config.php anpassen.
'phpsettings' => [
'display_errors' => 1,
],
// Frontend display Exceptions
'front' => [
'noErrorHandler' => true,
'throwExceptions' => true,
],
(Cache leeren) und dann den Fehler Reproduzieren. Durch die anpassung der ShopConfig solltet ihr eine Richtige Fehlermeldung bekommen die aussagekräfig ist. Also welches Plugin zu früh versucht ein Template zu laden bzw. zu Spät das Template Directory registriert.
@DennisG
Also welches Plugin zu früh versucht ein Template zu laden bzw. zu Spät das Template Directory registriert.
Gibt es ein Schema nach dem man in den zugänglichen Templates schauen kann ob dies der Fall ist?
Nein, leider nicht… dies fällt erst mit der Exception auf das man das Template garnicht oder in der falschen Reihenfolge registriert
Wurde wegen dem Fehler schon ein Update in 5.3.4 eingebaut?
Konnte leider im Log nix finden.
In 5.3.4 ist das zusätzliche Log noch nicht enthalten.
Unser Kollege hat ja bereits geschrieben, dass man den eigentlichen Fehler so ausgeben lassen kann:
'phpsettings' => [
'display_errors' => 1,
],
// Frontend display Exceptions
'front' => [
'noErrorHandler' => true,
'throwExceptions' => true,
],
Die Fehlermeldung „unkown Tag s“ ist erstmal nicht die Fehlermeldung die dem zugrunde liegt, sondern verschluckt nur die eigentliche Fehlermeldung. Nun gilt es die eigentliche Fehlermeldung (die wird nicht immer die gleiche sein) rauszubekommen.
Mit der nächsten regulären Version (ohne Sicherheitspatch) wird dann die korrekte Fehlermeldung auch geloggt, sodass ihr konkret seht, wo der Fehler entsteht.
Moritz
Es muss am PayPal Plus Modul liegen, seit 2 Wochen ausgeschaltet, seither keine Fehler mehr.
Allerdings auch weniger Geschäftskunden, da muss nun dringend eine Lösung her.
Es muss am PayPal Plus Modul liegen, seit 2 Wochen ausgeschaltet, seither keine Fehler mehr.
Allerdings auch weniger Geschäftskunden, da muss nun dringend eine Lösung her.
Sonst mal Stripe als Alternative probieren.
@Bohrerdiscount24 jup, sehen wir auch so da wir mit diesem schon immer probleme hatten und das sich regelmäßig deaktiviert hat. Laut Paypal soll es aber demnächst ein Update geben. Wir vermuten hier einen Fehler:
2017/10/24 11:38:20 [error] 4842#4842: *43707 upstream sent unexpected FastCGI record: 3 while reading response header from upstream, client: xxx.xx.xxx.xxx, server: domain.de, request: "POST /checkout/saveShippingPayment/sTarget/checkout/sTargetAction/index HTTP/1.1", upstream: "fastcgi://unix:/var/lib/php5-fpm/web2.sock:", host: "www.domain.de", referrer: "https://www.domain.de/checkout/shippingPayment"
ist aber nur eine Vermutung und lässt sich leider nicht nachstellen bzw. näher eingrenzen. Immer wenn dieser Fehler kommt, geht PP + danach nicht mehr.
Alternativ das normale PayPal-Modul nutzen, das funktioniert zumindest bei uns unauffällig.
Ja, das normale funktioniert tadellos, wir brauchen aber “Rechnung” und “Kreditkarte”…
Laut PayPal arbeitet SW am Probloem. (Schon seit Wochen…)
Vor 2 Wochen wusste der PayPal Plus Berater noch nichts von einem Problem mit dem Modul.
Heute ist ein Update für den Shop rausgekommen, von einer PayPal Plus Fehlerbeseitigung keine Spur…
Scheinbar ist es auch nur ein SW Problem, andere Plattformen haben keine Probleme.
Trinken wir mal einen auf den Wettbewerb der gerade fleisig Rechnungskauf Kunden abfischt.
Hallo zusammen!
Hänge mich hier mit dran. Wir haben die besagte Fehlermeldung auch mehrmals täglich. und einen Anstieg von ca. 40% Anmeldung ohne Bestellungen.
Einige Kunden haben uns die Fehlercodes geschickt:
Folgender insgesamt 4 x
Fatal error: Uncaught SmartyCompilerException: Syntax Error in template „/var/www/vhosts/XXXX.de/XXXX/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/vhosts/XXXX.de/XXXX/engine/Library/Smarty/sysplugins/smarty_internal_templatecompilerbase.php:657 Stack trace: #0 /var/www/vhosts/XXXX.de/XXXX/engine/Library/Smarty/sysplugins/smarty_internal_templatecompilerbase.php(443): Smarty_Internal_TemplateCompilerBase->trigger_template_error(‚unknown tag „s“‘, 7) #1 /var/www/vhosts/XXXX.de/XXXX/engine/Library/Smarty/sysplugins/smarty_internal_templateparser.php(2388): Smarty_Internal_TemplateCompilerBase->compileTag(‚s‘, Array) #2 /var/www/vhosts/XXXX.de/htt in /var/www/vhosts/XXXX.de/XXXX/engine/Library/Smarty/sysplugins/smarty_internal_templatecompilerbase.php on line 657
Wir benötigen schnellstmöglich eine Lösung - hatte gehofft, dass Thema wäre mit 5.3.4 erledigt…
Bitte einmal lesen. Das ist nicht die zugrunde liegende Fehlermeldung. Mit der erweiterung die ich oben geschrieben habe, bekommt man die richtige. Diese weicht von der aus dem Wiki ab!
In 5.3.4 ist das zusätzliche Log noch nicht enthalten.
Unser Kollege hat ja bereits geschrieben, dass man den eigentlichen Fehler so ausgeben lassen kann:‚phpsettings‘ => [
‚display_errors‘ => 1,
],
// Frontend display Exceptions
‚front‘ => [
‚noErrorHandler‘ => true,
‚throwExceptions‘ => true,
],Die Fehlermeldung „unkown Tag s“ ist erstmal nicht die Fehlermeldung die dem zugrunde liegt, sondern verschluckt nur die eigentliche Fehlermeldung. Nun gilt es die eigentliche Fehlermeldung (die wird nicht immer die gleiche sein) rauszubekommen.
Mit der nächsten regulären Version (ohne Sicherheitspatch) wird dann die korrekte Fehlermeldung auch geloggt, sodass ihr konkret seht, wo der Fehler entsteht.
Moritz
Nochmal nachgedacht - auch wenn der „s“ die echten Fehler kaschiert, glaube ich nicht an „verschiedene“ Fehler in Plugins, die das Template falsch oder zu spät registrieren (warum sollten diese das nur ab und zu nach Lust und Laune tun?). Was alle gemeinsam haben ist, dass, wenn der Fehler EINMAL aufgetreten ist, erst wieder der Cache geleert werden muss, damit es eine zeitlang funktioniert. Letzte Nacht ist mir dann spontan wieder eingefallen, warum ich derzeit den HTTP-Cache deaktiviert habe:
Event für detail auf postDispatch registriert und dort das Plugin-Template registriert. In der TPL einfach ein *Hallo Welt* in ein DIV packen - und ab und zu ist es dann doch nicht vorhanden. Was bitte soll hier dann noch falsch registriert werden? Für mich riecht es danach, dass irgendwo im Core ein Hund begraben ist, der entweder eine Template-Registrierung verhindert und/oder löscht, oder der erst gar nicht dafür sorgt, dass das Plugin-Event abgearbeitet wird.
Falls es zur Fehlerfindung beiträgt (mit der Erweitung in der config erhalten wir folgende Fehlermeldung):
Fatal error: Uncaught SmartyException: directory '/sw/engine/Shopware/Plugins/Community/Frontend/SwagPaymentPaypalPlus/Views/frontend/checkout/confirm.tpl' not allowed by security setting in /sw/engine/Library/Smarty/sysplugins/smarty_security.php:381 Stack trace:
#0 /sw/engine/Library/Smarty/sysplugins/smarty_internal_resource_file.php(33): Smarty_Security->isTrustedResourceDir('...')
#1 /sw/engine/Library/Smarty/sysplugins/smarty_resource.php(532): Smarty_Internal_Resource_File->populate(Object(Smarty_Template_Source), NULL)
#2 /sw/engine/Library/Smarty/sysplugins/smarty_internal_resource_extends.php(41): Smarty_Resource::source(NULL, Object(Enlight_Template_Manager), '...')
#3 /sw/engine/Library/Enlight/Components/Snippet/Resource.php(76): Smarty_Internal_Resource_Extends->populate(Object(Smarty_Template_Source), NULL)
#4 /sw/engine/Library/Smarty/sysp in /sw/engine/Library/Smarty/sysplugins/smarty_security.php on line 381
Ich vermute schwer, dass es wie teils meine Vorredner schon erwähnt haben, am Paypal Plus Plugin liegt.
Möglich, dass es mit PP+ besonders viele Schwierigkeiten in diesem Zusammenhang gibt. Bei uns taucht der Fehler aber auch ohne PP+ oft auf.
Falls es zur Fehlerfindung beiträgt (mit der Erweitung in der config erhalten wir folgende Fehlermeldung):
Fatal error: Uncaught SmartyException: directory ‚/sw/engine/Shopware/Plugins/Community/Frontend/SwagPaymentPaypalPlus/Views/frontend/checkout/confirm.tpl‘ not allowed by security setting in /sw/engine/Library/Smarty/sysplugins/smarty_security.php:381 Stack trace:
#0 /sw/engine/Library/Smarty/sysplugins/smarty_internal_resource_file.php(33): Smarty_Security->isTrustedResourceDir(‚…‘)
#1 /sw/engine/Library/Smarty/sysplugins/smarty_resource.php(532): Smarty_Internal_Resource_File->populate(Object(Smarty_Template_Source), NULL)
#2 /sw/engine/Library/Smarty/sysplugins/smarty_internal_resource_extends.php(41): Smarty_Resource::source(NULL, Object(Enlight_Template_Manager), ‚…‘)
#3 /sw/engine/Library/Enlight/Components/Snippet/Resource.php(76): Smarty_Internal_Resource_Extends->populate(Object(Smarty_Template_Source), NULL)
#4 /sw/engine/Library/Smarty/sysp in /sw/engine/Library/Smarty/sysplugins/smarty_security.php on line 381Ich vermute schwer, dass es wie teils meine Vorredner schon erwähnt haben, am Paypal Plus Plugin liegt.
In diesem Fall wird der Fehler durch das PaypalPlus Plugin verursacht. Es ist wahrscheinlich der Timingfehler von dem DennisG gesprochen hat. Um den zu beheben ersetz die von ihm genannte publich function. Das ist aber nicht immer der Fall. Es bringt ja nun auch nichts, immer wieder nur paypalplus zu rufen, wenn hier im Thread schon andere „Quellen“ genannt werden. Eigentlich muss der Core derartige Probleme abfangen.
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.
Das ist Perfekt @haustechnik, vielen Dank!!! Wir werden dazu ein Ticket erstellen und umgehend bearbeiten!
@hth Der Core darf solche fehler nicht beheben da es sich um ein Security issue handelt. Es muss in diesem Fall einfach einmal knallen damit die Fehler der Vergangenheit auffallen und behoben werden können!
Wie gesagt. Wenn ihr solche Fehler bekommt, bearbeitet eure config.php um den Fehler zu indentifizieren. Sprecht darauf den jeweiligen PluginEntwickler an. Nur so kann dieses Problem sinnvoll bearbeitet und behoben werden.
Zur Zeit ist es ja noch möglich die SmartySecurity aus zu schalten bis die Fehler behoben wurden (ACHTUNG NOTLÖSUNG)
So, ich melde mich auch mal wieder.
Heute das Update auf 5.3.4 eingespielt und zack, Fehler ist wieder da.
Der Support ist informiert, mal schauen ob sie was finden können *daumendrück*