Passiert dann das Gleiche wie mit diesem Ticket?
Shopware Issuetracker
und diesem?
Shopware Issuetracker
Nee, hier ist erst fertig, wenn fertig! Das liegt ja wohl auch an uns, mit Problem gelöst und Fortbestand der Ursache ist wohl keinem gedient am wenigsten SW selbst.
Und das hier ist ein massives Problem!
… Beitrag erledigt …
Als kurze Meldung von unserer Seite, ein Danke an @Moritz Naczenski Du setzt dich hier wirklich gut ein.
Wir wurden über das Support-Interface kontaktiert, und schauen mal ob auf dem Weg der Fehler eingegrenzt werden kann.
Ich halte Euch auf alle Fälle auf dem Laufenden.
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.
Servus,
danke für den Hinweis, ich habe es eben mal bei unserem System getestet, sprich
- nginx reverse proxy aus
- alle anfragen von apache bedient
- paypal plus eingeschaltet
- keine 30 Minuten später „Fehlerzustand“ in unserem Shop, sprich 500er Fehler bei /checkout
Kleine Besonderheit bei uns noch, wir setzen Redis anstelle von APCu als Cache ein.
Rein subjektiv schienen mir damit die Fehler unter 5.3.2 abgenommen zu haben.
Inzwischen sind wir auf 5.3.3 und alles so aktuell wie es nur irgendwie geht, und rums 500er Fehler wenn PayPal Plus aktiviert ist.
Wir haben auch lange probiert.
Wir haben fast alle Plugins deaktiviert. Nur noch Shopware Plugins.
Wenn wir mit einem Nutzer ein europäisches Land ausgewählt haben. z.B. Österreich und PayPal Plus als Zahlungsart aktiv ist, kommt die weiße seite beim /checkout/confirm.
Ändere ich von PayPal Plus auf Stripe, so funktioniert es sofort.
Folgenden Fehler konnte ich ausmachen, vielleicht ist das unser unknown s:
Im Checkout (vielleicht schon vorher im Register bzw danach im Finish) kommt es zu einem Fehler der aus einem undefiniertem $ resultiert. Bei uns wird dieser Fehler vom Plugin DHL Packstation produziert, wenn ich dieses deinstalliere, dann ist der Fehler auch weg. Dort heisst es ab Zeile 453:
$(document).ready(function($) {
var configuration = {
snippets: {
postaddressCompany: 'Adresszusatz 1',
packstationCompany: 'DHL Kundennummer (PostNummer)',
postaddressStreet: 'Straße und Nr.',
packstationStreet: {}, // These snippets are set below due to limitations in minimal-smartyness (no Smarty allowed in keys of associative array)
packstationStreetTitle: {},
customerNumberTitle: 'Die Kundennummer muss eine sechs- bis zehnstellige Zahl sein.'
},
Uns fällt auf, dass die beiden Arrays packstationStreet und packstationStreetTitle nicht referenziert sind - also produziert die Seite einen unknown s Fehler. Diese Fehler werden erst eingeblendet, wenn der Kunde eine alternative Lieferadresse wünscht, davon aber unabhängig werden die abzufragenden Arrays komplett geladen und bleiben halt (sofern keine andere Adresse gewünscht wird) leer … das Laden der Arrays versucht aber immer diesen unknow s Fehler.
Eben habe ich bemerkt, dass es dieses Plugin von Vision im Store gar nichtmehr gibt, das Warum fand ich hier: Das neue DHL Wunschpaket Plugin | Pickware Blog
Diese News ist komplett an mir vorbei gegangen und da ich schonmal ein Problem mit dem Wunschpaket Plugin in einer früheren Version hatte, habe ich natürlich nie in Betracht gezogen, hier mal nach Neuigkeiten ausschau zu halten. Also - schau mal, ob euer Checkout auch einen Uncaught ReferenceError auswirft. Musste etwas schmunzeln, denn in den Kommentaren steht es klar - drin siehe oben 
Ich versuchs mal mit dem neuen Plugin, bzw. mit keinem Plugin
vielleicht ist das unser unknown s:
Ich denke eher nicht, denn:
- Im einem Testshop habe ich den Fehler schon auf der Startseite und nur bei Verwendung einer Proxy-IP
- Ein DHL Plugin ist gar nicht vorhanden
In diesem Zusammenhang aber mal eine Frage in Runde:
Bei wem ist der Fehler zum ersten mal aufgetreten? Nach einem Update? Wenn ja, von welcher Version auf welche Version?
Achso, bei uns bei: von 5.2.27 auf 5.3.3.
Bei wem ist der Fehler zum ersten mal aufgetreten? Nach einem Update? Wenn ja, von welcher Version auf welche Version?
Seit wir von 5.2.x auf 5.3.2 umgestiegen sind. Da begann es, bei 5.3.3 ging es weiter.
Von 5.2.25 auf 5.3.2 war der Fehler da.
Fast alle Plugins raus damit der Shop wenigstens einigermaßen stabil läuft.
Cache leerung alle 4h.
Ich hänge mich hier mal an…
Ich betreue verschiedene Shops und hab das Problem leider mittlerweile in allen Shops, die auf 5.3.3 sind
In diesen Shops sind völlig unterschiedliche Plugins am laufen. Am massivsten betrifft es sogar den, der kein Paypal Plus integriert hat.
Auch hier hab ich mittlerweile alle Plugins rausgehauen, die nicht wirklich zwingend gebraucht werden, aber keine Veränderung.
In einem Shop kann ich zudem beobachten, dass es nur bei eingeloggten Kunden mit einer Kundengruppe die NICHT EK ist, auftritt.
Im anderen Shop wiederrum rufen nur Kunden an, die nicht aus Deutschland sind…
bei uns ist es auch seit dem Update von 5.2.x auf 5.3.2
Wir haben das Problem auch, soweit ich das beurteilen kann, in Verbindung mit PayPal Plus. Auch bei uns, wird der cache geleert, ist der Fehler erst einmal weg.
Eventuell testet Shopware das Ganze nur mit frisch aufgestzten 5.3 Testumgebungen?
Ihr solltet mal im Test einen 5.2 Shop auf 5.3 updaten.
2,600 views in diesem thread + 1.200 bei Nach update auf 5.3 shop tot - unknown tag s
Sprechen nicht mehr für Einzelfälle 
Die Kollegen schauen sich das Ticket an. Haben da ja bereits Kontakt zum Threadersteller - hat er ja auch schon geschrieben.
1 „Gefällt mir“
Ich melde mich hier auch noch einmal kurz.
Danke an Shopware, ja es wird gerade aktuell von einem Entwickler das Problem untersucht.
Ich verstehe natürlich auch das sich jeder hier im Thread wünscht das seine Systeme untersucht werden, dabei bitte ich um etwas Respekt für Shopware, sie haben halt auch nur begrenzte Ressourcen und es ist als kulant zu bewerten das sie sich überhaupt auf die Fehlersuche begeben.
Von daher bitte noch etwas Geduld.
Auch wenn hier nicht mehr viel neue Information drinsteckt : auch bei uns tritt der Fehler noch nach einem Update auf 5.3.3 auf, im PHP -Errorlog sieht ein solcher Vorgang dann so aus :
[Mon Oct 16 19:40:56.849001 2017] [fcgid:warn] [pid 26543:tid 140520147822336] [client xx.xxx.xxx.xxx:45730] mod_fcgid: stderr: PHP Fatal error: Uncaught exception ‘SmartyCompilerException’ with message ‘Syntax Error in template “/var/www/vhosts/unseredomainbeiaixpro.de/httpdocs/themes/Frontend/Bare/frontend/index/header.tpl” on line 9 “<meta name=“author” content=”{s name=‘IndexMetaAuthor’}{/s}" />" unknown tag “s”’ in /var/www/vhosts/unseredomainbeiaixpro.de/httpdocs/engine/Library/Smarty/sysplugins/smarty_internal_templatecompilerbase.php:657, referer: PayPal
…
mehrere gleichartige Fehlermeldungen, gekürzt wegen Zeichenlimit
…
[Mon Oct 16 19:44:03.241637 2017] [fcgid:warn] [pid 4092:tid 140520164607744] [client xx.xxx.xxx.xxx:46054] mod_fcgid: stderr: #2 /var/www/vhosts/unseredomainbeiaixpro.de/httpdocs/engine/Library/Smarty/sysplugins/smarty_internal_templateparser.php(3101): Smarty_Int in /var/www/vhosts/unseredomainbeiaixpro.de/httpdocs/engine/Library/Smarty/sysplugins/smarty_internal_templatecompilerbase.php on line 657, referer: PayPal
Schmerzhaft als Shopbetreiber dann noch zu sehen wie der Kunde es über 4 Minuten mehrfach versucht bevor er dann natürlich verärgert abbricht
Wir konnten das auftreten des Fehlers veringern indem wir alle 4 Stunden per cronjob den Cache leeren und wieder aufwärmen, vereinzelt wie jetzt hier gestern, tritt der Fehler aber noch auf.
Bei uns trat der Fehler auch nach deaktivierung von PP Plus noch auf, einfaches Paypal bei der Rückleitung zum Shop reichte aus.
Ich hoffe sehr, dass es hier bald zu einer Lösung kommt, wenn wir uns die Abbruchanalyse und dazu das Errorlog ansehen wird einem fünfstellig schwindelig.
Der „unknown tag s” Club wird größer …
Ich hab hier vielleicht nochmal `nen kleinen Ansatz was die Richtung angeht:
Muss etwas ausholen dafür :
Mir ist heute aufgefallen, dass wir im Listing (Kategorien) seit einiger Zeit scheinbar keine Grundpreise mehr haben (doh!).
Auf der Suche im Forum bin ich dabei noch über diesen Beitrag hier gestolpert, einer der dasselbe Problem hatte :
https://forum.shopware.com/discussion/43529/grundpreisberechnung-fehlende-anzeige-bei-100ml
Ich habe dann etwas herumprobiert und habe festgestellt, dass der Fehler verschwindet, sobald man den Textbaustein aus der frontend/listing/product-box/product-price-unit.tpl rausnimmt an der Stelle.
Statt
{* Unit price is based on a reference unit *}
{if $sArticle.purchaseunit && $sArticle.purchaseunit != $sArticle.referenceunit}
{* Reference unit price content *}
{block name=‘frontend_listing_box_article_unit_reference_content’}
({$sArticle.referenceprice|currency}
{s name=“Star”}{/s} / {$sArticle.referenceunit} {$sArticle.sUnit.description})
{/block}
{/if}
Also {s name=“Star”}{/s} entfernen.
Seltsamerweise gibt es keinerlei Fehler solange der Textbaustein drin ist , der dahinterliegende Teil, also die Grundpreisanzeige im Listing, wird dann aber nicht mehr angezeigt, das ist zu 100% reproduzierbar bei uns.
Der Namespace ist im Bare-TPL mit {namespace name=“frontend/listing/box_article”} angegeben und dort ist dieser auch vorhanden.
Was mich jetzt interessieren würde : wenn man sich andere Dateien ansieht, z.B. die frontend/listing/text,tpl diesen Block hier :
{* Short description *}
{block name=“frontend_listing_text_content_short”}
{$sCategoryContent.cmstext|strip_tags|truncate:200}
{s namespace=“frontend/listing/listing” name=“ListingActionsOpenOffCanvas”}{/s} »
{/block}
dann wird hier nicht nur der Name, sondern auch der namespace nochmal angegeben, obwohl auch in dieser Datei der genannte namespace schon oben angegeben wird :
{namespace name=“frontend/listing/listing”}
Um jetzt wieder den Bogen zum hier behandelten Problem zu schlagen : in der frontend/index/header.tpl die ja nun zumindest in den Paypal-Rückleitungsfällen den Fehler auswirft, ist ja nun garkein Namespace angegeben, kann es sein, dass dieser unter bestimmten Voraussetzungen an der Stelle nicht bekannt ist?
Wäre es einen Versuch wert,den oder die relevanten Namespace(s) hier nochmal extra mit anzugeben ?
also entweder oben in der Datei via
{namespace name=“frontend/index/header”}
oder eben direkt an den betroffenen Stellen
Ich hab es jetzt noch nicht ausprobiert da ich gleich Feierabend machen muss, aber vielleicht kann da einer von euch was zu sagen ? WAhrscheinlich hat es ja einen guten Grund weswegen hier kein Namespace angegeben ist… ?
Mit besten Grüßen aus Hamburg
Mario
Den Gedanken hatte ich auch schonmal verfolgt. Aber irgendwie kann ich mir nicht vorstellen, dass dort das Problem liegt. Der Textbaustein im Header ist glaube ich nur einfach der erste der compiliert wird (weils nunmal der erste textbaustein ist der vorkommt).
Ich hab den schonmal einfach rausgenommen, dann wird halt am nächsten rumgemeckert - zumindest war das bei mir der Fall… Das Große Problem ist wirklich das sporadische auftreten… Das ergibt für einen gelernten Programmierer keinerlei Sinn… 