Hat jemand eine Ahnung, auf was man jetzt in der 6.7.0.1 das memory-Limit setzen muss?
Bei uns ist 512MB eingestellt und die Storefront steigt mit memory-Limit aus. Dabei hat der Shop nichtmal wirklich Plugins im Einsatz und das Theme habe ich auch wegen dem Update auf dem SW-Standard-Theme.
Backend scheint soweit zu laufen
Die Storefront nutzt bei mir meist zwischen 20 und 40 MB. Ein generelles Shopware Problem sollte es also nicht sein.
Aber natürlich kommt es auf die Individualisierung an und wie viele Daten du mittels Verknüpfungen zusätzlich lädst.
An deiner Stelle würde ich den Profiler nutzen und schauen, was da so viel RAM frisst.
Das hohe Memorylimit ist eigentlich nur fürs Backend und Scheduler relevant, hab ich noch nie erlebt, daß das Frontend ins Memorylimit läuft. Normalerweise erwähnt der Fehler auch, wo er ins Limit läuft, was zeigt er da an?
Das wundert mich halt auch. Hatte das im Frontend auch noch nie.
Der Fehler kommt beim CacheValueCompressor
Sehr merkwürdig. Habt Ihr viele Produkte/Kategorien? Und ist gzip oder zstd als Kompression eingestellt, weißt Du das? Eventuell mal wechseln?
Finde das auch komisch. Vorher auf der 6.6.9 lief ja alles problemlos.
Nur knapp 900 Artikel (inkl. Varianten 3800) und Kategorien sind sehr überschaubar
Zum Glück ist das noch kein Live-Shop. Shopware-Updates sind immer wieder was schönes.
Irgend eine Überraschung gibt es immer 
Hab gerade mal den Wartungsmodus aktiviert, die Seite wird interessanterweise angezeigt
Bin mal gespannt, woran es diesmal liegt.
Habe das gleiche Problem. Konnte schon Lösung gefunden werden?
Hallo zusammen,
es gibt zur Zeit einen Bug, der das Problem verursachen kann. Dazu gibt es bereits ein Ticket, dass bisher noch nicht veröffentlicht wurde.
Es geht um das folgende Ticket: fix: Change path of header and footer routes to avoid collisions by mitelg · Pull Request #10911 · shopware/shopware · GitHub
Das Problem kann behoben werden in dem in der Tabelle seo_url die Einträge Footer/ oder Header/ gelöscht werden. Bitte auf die korrekte Schreibweise achten. Nicht footer, Footer oder Footer//.
Ob man betroffen ist, kann man z.B. mit den beiden folgenden Abfrage heraus finden:
SELECT * FROM seo_url WHERE seo_path_info = 'Footer/';
SELECT * FROM seo_url WHERE seo_path_info = 'Header/';
Alle Angaben ohne Gewähr. Macht bitte vorher ein Backup eurer Datenbank.
VG Rico von enerspace.de
Super. Das verhindert zumindest mal den Error 500.
Aber generell scheint Shopware im Footer zumindest ziemlichen Mist zu machen.
die render_esi wirft da jetzt dann im Footer eine 301, weil es wohl den Footer nicht rendern kann.
Error when rendering „https://Domainname/footer“ (Status code is 301).
Und hab ich eine seoUrl die im seo_path ‚footer‘ stehen hat, steht man wieder am Anfang mit Error 500
Aber Hauptsache es wird was geändert
also wenn man den 301-Error hat, muss man einfach in der Tabelle nochmal nach footer bei der seo_path_info suchen. den Eintrag weglöschen und nun gehts.
Hallo,
wie bereits beschrieben, darf nur der Eintrag Footer/ oder Header/ gellöscht werden.
VG Rico von enerspace.de
Hi,
die hatte ich nicht mehr in der DB.
Solang ich aber in der seo_url-Tabelle noch einen Eintrag mit „footer“ in seo_path_info hatte, wollte er den Footer nicht rendern.
Jetzt heißt der MP für meine Footernavi „footernavi“ und nicht mehr „footer“.
und in der DB hab ich keinen footer-Eintrag mehr (der Kommt ja vom Navigation-Controller im SW-Core)
und schon macht die render_esi Funktion im Base-Twig für den Footer kein Problem mehr und stellt die Navi korrekt da
Aber thx nochmal für den Hinweis mit der DB um das Ursprungsproblem zu finden