Fehlerbehebung FAQ

Das Problem: Sie brauchen das Modul, aber nicht seine Assets auf jeder Seite

Es gibt viele Situationen, in denen Sie ein PrestaShop-Modul installiert und aktiv lassen möchten, aber verhindern wollen, dass es seine CSS- oder JavaScript-Dateien auf bestimmten Seiten oder sogar auf allen Seiten lädt. Vielleicht haben Sie ein Modul, dessen Funktionalität Sie benötigen, dessen Styling aber mit Ihrem Theme in Konflikt steht. Vielleicht lädt ein Modul eine schwere JavaScript-Bibliothek, die Sie bereits über Ihr Theme eingebunden haben. Vielleicht möchten Sie die Standardstile eines Moduls durch Ihr eigenes benutzerdefiniertes CSS ersetzen, ohne dass die Originalstile stören. Oder vielleicht haben Sie durch ein Performance-Audit festgestellt, dass ein Modul Assets auf Seiten lädt, auf denen es keine sichtbare Ausgabe hat, und Sie diese Verschwendung beseitigen möchten.

Das Modul zu deinstallieren kommt nicht in Frage, weil Sie seine Kernfunktionalität benötigen: seine Hooks, seine Datenbanktabellen, seine Konfiguration, seine Back-Office-Funktionen. Sie müssen lediglich chirurgisch bestimmte CSS- oder JavaScript-Dateien aus der Front-Office-Ausgabe entfernen. PrestaShop bietet mehrere Mechanismen, um dies zu erreichen, und dieser Artikel behandelt alle im Detail, vom einfachsten bis zum leistungsfähigsten.

Methode 1: Theme.yml verwenden, um Modul-Assets zu entfernen

Der einfachste und wartbarste Weg, CSS oder JavaScript eines Moduls in PrestaShop 1.7 und später zu entfernen, führt über die Konfigurationsdatei des Themes, die theme.yml. Diese Datei, die sich im Stammverzeichnis Ihres Theme-Ordners befindet, steuert, welche Assets das Theme lädt und welche Modul-Assets es entfernt.

Öffnen Sie Ihre theme.yml-Datei und suchen Sie den Assets-Bereich. Wenn er nicht existiert, können Sie ihn erstellen. Innerhalb des Assets-Bereichs können Sie CSS- und JavaScript-Dateien angeben, die nach ihrer Asset-ID entfernt werden sollen. Jedes Asset, das über registerStylesheet oder registerJavascript registriert wird, hat eine ID, die typischerweise aus dem Modulnamen gefolgt von einem beschreibenden Suffix besteht.

Um die Asset-IDs eines Moduls zu finden, untersuchen Sie den Quellcode Ihrer Seite und suchen Sie nach den Stylesheet-Link-Tags und den Script-Elementen. PrestaShop fügt diesen Elementen im Debug-Modus ein id-Attribut hinzu, oder Sie finden die IDs im Quellcode des Moduls, wo es registerStylesheet oder registerJavascript aufruft.

Fügen Sie in Ihrer theme.yml-Datei einen Bereich unter assets, dann css, dann all hinzu. Fügen Sie einen Eintrag mit der Asset-ID hinzu und setzen Sie ihn auf false. Wenn beispielsweise ein Modul ein Stylesheet mit der ID modulname-style registriert, würden Sie modulname-style mit dem Wert false unter dem Bereich css all hinzufügen. Verfahren Sie genauso für JavaScript-Dateien unter dem Bereich js all.

Nach der Änderung der theme.yml müssen Sie den PrestaShop-Cache unter Erweiterte Einstellungen, Leistung löschen. Die theme.yml-Änderungen werden nach dem Neuaufbau des Caches wirksam. Dieser Ansatz bleibt über Modul-Updates hinweg bestehen, da die Entfernung in Ihrem Theme definiert ist, nicht im Modul selbst. Er entfernt die Assets jedoch von allen Seiten. Wenn Sie die Assets auf manchen Seiten benötigen, aber auf anderen nicht, brauchen Sie einen gezielteren Ansatz.

Methode 2: Media::unregisterStylesheet und Media::unregisterJavascript

PrestaShop 1.7 führte die Media-Klassenmethoden unregisterStylesheet und unregisterJavascript ein, die es Ihnen ermöglichen, programmgesteuert bestimmte Assets zu entfernen, die von anderen Modulen registriert wurden. Diese Methoden sind leistungsfähig, weil Sie sie bedingt aufrufen können — Assets nur auf bestimmten Seiten entfernen und auf anderen beibehalten.

Um diesen Ansatz zu verwenden, benötigen Sie ein benutzerdefiniertes Modul oder eine Modifikation an einem bestehenden Modul. Rufen Sie in der hookActionFrontControllerSetMedia-Methode Ihres Moduls Media::unregisterStylesheet mit der Asset-ID der CSS-Datei auf, die Sie entfernen möchten. Rufen Sie entsprechend Media::unregisterJavascript mit der Asset-ID der JavaScript-Datei auf. Sie können diese Aufrufe in bedingte Logik einbetten, um Assets nur auf bestimmten Seitentypen zu entfernen.

Wenn Sie beispielsweise die Assets eines Slider-Moduls von jeder Seite außer der Startseite entfernen möchten, würden Sie prüfen, ob der aktuelle Controller der IndexController ist. Wenn es nicht die Startseite ist, rufen Sie die Unregister-Methoden auf. Wenn es die Startseite ist, tun Sie nichts und lassen die Assets normal laden.

Die zentrale Überlegung bei diesem Ansatz ist die Hook-Ausführungsreihenfolge. Die hookActionFrontControllerSetMedia-Methode Ihres Moduls muss nach dem Modul ausgeführt werden, dessen Assets Sie entfernen möchten. PrestaShop führt Hook-Callbacks in der Reihenfolge aus, in der Module beim Hook registriert sind, was Sie über die Seite Design, Positionen im Back-Office steuern können. Verschieben Sie Ihr benutzerdefiniertes Modul unter das Zielmodul auf dem actionFrontControllerSetMedia-Hook, um sicherzustellen, dass Ihre Unregister-Aufrufe nach der Asset-Registrierung des Zielmoduls erfolgen.

Wenn das problematische Modul die älteren addCSS- und addJS-Methoden anstelle von registerStylesheet und registerJavascript verwendet, funktionieren die Unregister-Methoden möglicherweise nicht, da die älteren Methoden nicht dasselbe Asset-Management-System verwenden. In diesem Fall benötigen Sie einen anderen Ansatz.

Methode 3: Benutzerdefiniertes Modul zum Blockieren bestimmter Assets

Wenn Sie eine feinkörnige Kontrolle darüber benötigen, welche Assets auf welchen Seiten geladen werden, ist die Erstellung eines dedizierten Asset-Manager-Moduls die flexibelste Lösung. Dieses Modul dient als zentrale Stelle, an der Sie Regeln zum Blockieren oder Zulassen bestimmter Modul-Assets definieren.

Erstellen Sie ein neues Modul mit einer hookActionFrontControllerSetMedia-Methode. Definieren Sie innerhalb dieser Methode ein Array von Asset-Regeln. Jede Regel gibt einen Modulnamen, die zu blockierenden Asset-IDs und die Bedingungen an, unter denen sie blockiert werden sollen. Die Bedingungen können auf dem Controller-Namen, dem Seitentyp oder jedem anderen im PrestaShop-Kontext verfügbaren Kriterium basieren.

Ihr Modul durchläuft die Regeln bei jedem Seitenaufruf, prüft die Bedingungen und ruft Media::unregisterStylesheet oder Media::unregisterJavascript für jedes Asset auf, das auf der aktuellen Seite blockiert werden soll. Dieser zentralisierte Ansatz ist viel einfacher zu warten, als Asset-Entfernungslogik über mehrere Module oder Theme-Dateien zu verstreuen.

Sie können dieses Modul mit einer Back-Office-Konfigurationsseite erweitern, die es Ihnen ermöglicht, die Regeln über die PrestaShop-Admin-Oberfläche zu verwalten, anstatt Code zu bearbeiten. Ein einfaches Formular mit Feldern für Modulname, Asset-ID und einer Mehrfachauswahl für Seitentypen, auf denen das Asset blockiert werden soll, gibt Ihnen eine benutzerfreundliche Möglichkeit, das Asset-Laden zu verwalten, ohne nach der Ersteinrichtung Code anfassen zu müssen.

Dieser Ansatz funktioniert sowohl mit dem neuen registerStylesheet-System als auch mit dem älteren addCSS-System, wobei Sie für jedes möglicherweise unterschiedliche Techniken anwenden müssen. Für Assets, die mit dem neuen System registriert wurden, verwenden Sie die Media::unregister-Methoden. Für Assets, die mit dem älteren System hinzugefügt wurden, können Sie die css_files- und js_files-Arrays des Controllers direkt in der hookActionFrontControllerSetMedia-Methode manipulieren.

Methode 4: Der Hook-Abhänge-Ansatz

Ein aggressiverer, aber manchmal notwendiger Ansatz besteht darin, ein Modul vollständig von den Hooks abzuhängen, bei denen es seine Assets registriert. Gehen Sie zu Design, dann Positionen in Ihrem Back-Office. Finden Sie das Modul auf dem displayHeader- oder actionFrontControllerSetMedia-Hook. Klicken Sie auf den Löschen- oder Abhängen-Button, um das Modul vollständig von diesem Hook zu entfernen.

Dies verhindert, dass das Modul überhaupt Assets lädt, auf jeder Seite. Die anderen Hooks des Moduls, wie displayProductAdditionalInfo oder displayFooter, funktionieren weiterhin normal. Die Front-Office-Ausgabe des Moduls kann jedoch fehlerhaft werden, wenn sie von ihrem CSS für die Gestaltung oder ihrem JavaScript für interaktives Verhalten abhängt.

Dieser Ansatz ist besonders nützlich, wenn Sie die Gestaltung des Moduls vollständig durch Ihr eigenes benutzerdefiniertes CSS ersetzen möchten. Sie hängen das Modul von displayHeader ab, um das Laden seines CSS zu verhindern, und schreiben dann Ihre eigenen Stile in der benutzerdefinierten CSS-Datei Ihres Themes, die auf die HTML-Elemente des Moduls abzielen. Dies gibt Ihnen die vollständige Kontrolle über das Erscheinungsbild des Moduls ohne Konflikte zwischen den Originalstilen und Ihren Anpassungen.

Für JavaScript ist das Abhängen riskanter. Wenn das Modul auf sein JavaScript für Kernfunktionalität wie AJAX-Aufrufe, Formularvalidierung oder dynamisches Laden von Inhalten angewiesen ist, werden diese Funktionen durch das Entfernen des JavaScripts nicht mehr funktionieren. Hängen Sie JavaScript nur ab, wenn Sie sicher sind, dass die Front-Office-Ausgabe des Moduls nicht davon abhängt, oder wenn Sie eine Ersatzimplementierung über Ihr Theme bereitstellen.

Ein wichtiger Vorbehalt: Wenn Sie das Modul aktualisieren, kann der Aktualisierungsprozess das Modul erneut bei den Hooks registrieren, von denen Sie es entfernt haben. Prüfen Sie nach jeder Modulaktualisierung unter Design, Positionen, ob Ihre Abhängung noch wirksam ist. Manche Module registrieren ihre Hooks während des Aktualisierungsprozesses explizit neu, was Ihre manuelle Abhängung überschreibt.

Methode 5: Modul-Assets über Ihr Theme überschreiben

PrestaShops Theme-System ermöglicht es Ihnen, Modul-Template-Dateien zu überschreiben, indem Sie sie im modules-Verzeichnis Ihres Themes platzieren. Obwohl dies primär für Template-Überschreibungen verwendet wird, können Sie es auch nutzen, um das Asset-Laden indirekt zu steuern.

Wenn ein Modul seine Assets über seine Template-Dateien lädt, indem es Smarty-Funktionen wie Script- oder Stylesheet-Tags direkt in TPL-Dateien verwendet, anstatt über PHP-Hooks, können Sie diese Templates in Ihrem Theme überschreiben und die Asset-Referenzen entfernen. Kopieren Sie die Template-Datei des Moduls in das modules-Verzeichnis Ihres Themes unter Beibehaltung der gleichen Verzeichnisstruktur und bearbeiten Sie die Kopie, um die unerwünschten CSS- oder JavaScript-Referenzen zu entfernen.

Dieser Ansatz ist theme-spezifisch, das heißt, er betrifft nur das aktuelle Theme. Wenn Sie das Theme wechseln, werden die Überschreibungen nicht übernommen. Er erfordert auch Wartung: Wenn das Modul seine Templates aktualisiert, müssen Sie Ihre Überschreibungen aktualisieren, um strukturelle Änderungen zu übernehmen und gleichzeitig Ihre Asset-Entfernungs-Modifikationen beizubehalten.

Für Module, die Assets über PHP-Hooks statt über Templates laden, helfen Theme-Template-Überschreibungen nicht beim Asset-Blockieren. Verwenden Sie in diesem Fall eine der anderen in diesem Artikel beschriebenen Methoden.

PrestaShop 1.7 vs. 8.x: Unterschiede im Ansatz

PrestaShop 8.x verfeinerte das in 1.7 eingeführte Asset-Management-System, aber die grundlegenden Ansätze bleiben gleich. Die Hauptunterschiede liegen in der internen Implementierung und einigen zusätzlichen Funktionen.

In PrestaShop 1.7 verwendet das Asset-Management-System registerStylesheet und registerJavascript mit einem Prioritätssystem. Die Methoden Media::unregisterStylesheet und Media::unregisterJavascript funktionieren zuverlässig für Assets, die über dieses System registriert werden. Module, die noch die veralteten addCSS- und addJS-Methoden verwenden (die veraltet, aber weiterhin funktionsfähig sind), durchlaufen jedoch nicht das neue Asset-Management-System, was es schwieriger macht, sie sauber zu entfernen.

PrestaShop 8.x verbesserte die Abwärtskompatibilität, sodass auch Assets, die über die veralteten Methoden hinzugefügt werden, durch die neue Asset-Pipeline verarbeitet werden. Das bedeutet, dass die Media::unregister-Methoden konsistenter über alle Module hinweg funktionieren, unabhängig davon, welche Registrierungsmethode sie verwenden. Wenn Sie PrestaShop 8.x verwenden, ist der Unregister-Ansatz die zuverlässigste Methode für alle Module.

PrestaShop 8.x führte auch ein verbessertes Cache-Busting für Assets ein, was bedeutet, dass Änderungen nach dem Löschen des Caches sofort wirksam werden, ohne dass Kunden veraltete gecachte Versionen sehen. In PrestaShop 1.7 musste man manchmal sowohl den PrestaShop-Cache als auch den Browser-Cache löschen oder warten, bis das Combine-Compress-Cache (CCC)-System die kombinierten Dateien neu generiert hatte.

Beide Versionen unterstützen den theme.yml-Ansatz zur Asset-Entfernung, und die Syntax ist identisch. Wenn Sie ein benutzerdefiniertes Modul für das Asset-Management schreiben, funktioniert derselbe Code auf beiden Versionen 1.7 und 8.x mit minimalen Unterschieden.

Leistungsgewinne nach dem Deaktivieren von Assets messen

Nach dem Deaktivieren von Modul-Assets sollten Sie die Leistungsverbesserung messen, um zu bestätigen, dass Ihre Änderungen den erwarteten Effekt hatten. Verwenden Sie eine Kombination von Tools für eine umfassende Messung.

Beginnen Sie mit dem Netzwerk-Tab der Chrome DevTools. Vergleichen Sie die Gesamtzahl der Anfragen und die gesamte übertragene Größe vor und nach Ihren Änderungen. Filtern Sie nach CSS und JS, um die spezifische Reduzierung der Stylesheet- und JavaScript-Dateianzahl und -größen zu sehen. Eine sinnvolle Optimierung sollte eine deutliche Reduzierung sowohl der Anfragenanzahl als auch der Gesamtgröße zeigen.

Führen Sie ein Lighthouse-Performance-Audit vor und nach der Änderung durch. Konzentrieren Sie sich auf die Metriken, die am stärksten vom CSS- und JavaScript-Laden beeinflusst werden: First Contentful Paint wird durch render-blockierendes CSS beeinflusst, Largest Contentful Paint durch das gesamte Ressourcenladen und Total Blocking Time durch JavaScript-Parsing und -Ausführung. Erfassen Sie diese Metriken aus mindestens drei Durchläufen und vergleichen Sie die Durchschnittswerte.

Verwenden Sie den Coverage-Tab in den Chrome DevTools, um die CSS- und JavaScript-Nutzung zu messen. Öffnen Sie den Coverage-Tab über das Drei-Punkte-Menü unter Weitere Tools und laden Sie dann die Seite neu. Der Coverage-Tab zeigt Ihnen, wie viel von jeder CSS- und JavaScript-Datei auf der aktuellen Seite tatsächlich verwendet wird. Dateien mit hohem Anteil ungenutzten Codes (rot angezeigt) sind Kandidaten für Entfernung oder bedingtes Laden. Nach dem Deaktivieren von Modul-Assets sollten die verbleibenden Dateien höhere Nutzungsprozentsätze aufweisen, was darauf hinweist, dass Sie Verschwendung erfolgreich beseitigt haben.

Berücksichtigen Sie auch Realwelt-Metriken von Ihrer Analytics-Plattform. Wenn Sie Google Analytics oder ein ähnliches Tool verwenden, vergleichen Sie die Seitenladezeiten für eine Woche vor und nach Ihrer Optimierung. Reale Daten von tatsächlichen Besuchern auf verschiedenen Geräten und unter verschiedenen Netzwerkbedingungen geben Ihnen das genaueste Bild der Leistungsverbesserung.

Risiken und Kompatibilitätsbedenken

Das Deaktivieren von Modul-Assets birgt Risiken, die Sie verstehen und managen müssen. Das häufigste Risiko ist visueller Bruch. Wenn Sie das CSS eines Moduls entfernen, verlieren seine HTML-Elemente ihre Gestaltung und können fehlerhaft angezeigt werden. Dies kann von geringfügigen kosmetischen Problemen wie falschen Farben oder Abständen bis hin zu schwerwiegenden Layout-Problemen wie überlappenden Elementen oder unsichtbaren Inhalten reichen.

Das Entfernen von JavaScript birgt ein höheres Risiko. Moderne Module hängen oft von ihrem JavaScript für Kernfunktionalität ab. Das Entfernen von JavaScript kann dazu führen, dass Funktionen vollständig aufhören zu arbeiten: Buttons, die nicht auf Klicks reagieren, Formulare, die nicht abgesendet werden, Popups, die sich nicht öffnen, AJAX-Inhalte, die nicht geladen werden. Testen Sie immer jede Funktion eines Moduls, nachdem Sie sein JavaScript entfernt haben.

Es gibt auch ein Kompatibilitätsrisiko bei Modul-Updates. Wenn ein Modul aktualisiert wird, kann der Entwickler neue CSS- oder JavaScript-Dateien mit anderen Asset-IDs hinzufügen. Ihre Entfernungsregeln, ob in der theme.yml oder einem benutzerdefinierten Modul, erfassen die neuen Assets möglicherweise nicht, weil sie auf die alten Asset-IDs abzielen. Überprüfen Sie nach jedem Modul-Update, ob Ihre Asset-Blockierung noch korrekt funktioniert, und aktualisieren Sie Ihre Regeln bei Bedarf.

Manche Module führen Feature-Erkennung in ihrem JavaScript durch und verhalten sich anders, wenn ihr CSS nicht geladen ist. Ein Modul könnte die Existenz bestimmter CSS-Klassen oder berechneter Stile prüfen, bevor es seine JavaScript-Funktionalität initialisiert. Das Entfernen des CSS ändert in diesem Fall nicht nur das Erscheinungsbild, sondern bricht auch das JavaScript-Verhalten, das von diesen CSS-definierten Zuständen abhängt.

Beachten Sie schließlich Abhängigkeiten zwischen Modulen. Modul A könnte eine JavaScript-Bibliothek wie ein Lightbox-Plugin laden, das Modul B ebenfalls verwendet, aber selbst nicht lädt, weil es davon ausgeht, dass Modul A sie bereitstellt. Das Entfernen der JavaScript-Dateien von Modul A würde in diesem Szenario beide Module beschädigen. Prüfen Sie auf gemeinsame Abhängigkeiten, bevor Sie Assets entfernen.

Ein praktischer Workflow für sichere Asset-Entfernung

Befolgen Sie diesen Workflow, um Modul-Assets sicher zu deaktivieren, ohne Ihren Shop zu beschädigen. Erstens: Dokumentieren Sie Ihren aktuellen Zustand. Machen Sie Screenshots von jedem Seitentyp, auf dem das Modul Inhalte anzeigt. Erfassen Sie Lighthouse-Scores und Netzwerk-Tab-Statistiken. Dies gibt Ihnen eine Ausgangsbasis zum Vergleichen und eine Referenz dafür, wie das Modul aussehen und funktionieren sollte.

Zweitens: Identifizieren Sie die spezifischen Assets, die Sie entfernen möchten. Verwenden Sie DevTools, um die genauen Dateinamen und Asset-IDs zu finden. Bestimmen Sie, welche Seiten die Assets benötigen und welche nicht.

Drittens: Implementieren Sie die Entfernung mit der am besten geeigneten Methode aus diesem Artikel. Für einfache globale Entfernung verwenden Sie theme.yml. Für bedingte Entfernung basierend auf dem Seitentyp erstellen Sie ein benutzerdefiniertes Modul mit Media::unregister-Aufrufen. Für einen vollständigen Asset-Ersatz hängen Sie das Modul ab und stellen Ihre eigenen Stile bereit.

Viertens: Testen Sie gründlich. Prüfen Sie jeden Seitentyp, auf dem das Modul Inhalte anzeigen sollte. Überprüfen Sie, dass das visuelle Erscheinungsbild des Moduls korrekt ist und alle interaktiven Funktionen funktionieren. Prüfen Sie Seiten, auf denen Sie die Assets entfernt haben, um zu bestätigen, dass sie nicht mehr geladen werden. Testen Sie auf mehreren Browsern und Geräten.

Fünftens: Messen Sie die Leistungsverbesserung. Führen Sie Lighthouse-Audits durch und vergleichen Sie mit Ihrer Ausgangsbasis. Prüfen Sie den Netzwerk-Tab auf reduzierte Anfragenzahlen und -größen. Wenn die Verbesserung signifikant ist, war Ihre Optimierung erfolgreich. Wenn die Verbesserung minimal ist, waren die entfernten Assets möglicherweise nicht der Hauptleistungsengpass, und Sie sollten andere Optimierungsmöglichkeiten untersuchen.

Sechstens: Dokumentieren Sie Ihre Änderungen. Notieren Sie, welche Assets Sie entfernt haben, welche Methode Sie verwendet haben und welche Seiten betroffen sind. Diese Dokumentation ist unerlässlich für die Fehlerbehebung zukünftiger Probleme, insbesondere nach Modul-Updates, und für den Wissenstransfer, falls jemand anderes den Shop wartet.

Indem Sie diesem systematischen Ansatz folgen, können Sie das Seitengewicht Ihres Shops sicher reduzieren und die Ladezeiten verbessern, ohne auf die Modulfunktionalität zu verzichten, auf die Ihr Shop angewiesen ist. Der Schlüssel ist immer Testen und Messen: Gehen Sie nie davon aus, dass das Entfernen eines Assets sicher ist, und überprüfen Sie die Ergebnisse immer mit konkreten Daten.

Vollständige Antwort lesen

PHP memory_limit verstehen

Die memory_limit-Direktive in PHP steuert, wie viel RAM ein einzelner PHP-Prozess verbrauchen darf, bevor die Engine ihn mit einem fatalen Fehler beendet. Wenn Sie in PrestaShop die Meldung "Allowed memory size of X bytes exhausted" sehen, bedeutet dies, dass eine bestimmte PHP-Anfrage mehr Arbeitsspeicher nutzen wollte, als das konfigurierte Limit erlaubt.

Jeder Seitenaufruf in PrestaShop fuehrt PHP-Code aus, der das Framework laedt, eine Verbindung zur Datenbank herstellt, Daten verarbeitet, Templates rendert und HTML an den Browser sendet. Jeder dieser Schritte verbraucht Arbeitsspeicher. Das memory_limit fungiert als Sicherheitsnetz: Es verhindert, dass ein einzelner unkontrollierter Prozess den gesamten verfuegbaren Server-RAM verbraucht, was andere Prozesse zum Absturz bringen und potenziell den gesamten Server lahmlegen wuerde.

Das Standard-memory_limit in PHP betraegt typischerweise 128M (128 Megabyte). PrestaShop empfiehlt offiziell mindestens 256M, und viele Shops benoetigen 512M oder mehr, je nach Kataloggroesse, installierten Modulen und Traffic. Das Verstaendnis dessen, was den Speicherverbrauch antreibt, hilft Ihnen, den richtigen Wert fuer Ihren Shop zu bestimmen, anstatt das Limit blind zu erhoehen.

So pruefen Sie Ihr aktuelles Memory Limit

Es gibt mehrere Moeglichkeiten, um zu ueberpruefen, welches Memory Limit Ihre PrestaShop-Installation aktuell verwendet.

Aus dem PrestaShop Back Office

Navigieren Sie zu Erweiterte Einstellungen > Informationen. Diese Seite zeigt die PHP-Konfiguration Ihres Servers an, einschliesslich des aktuellen memory_limit-Wertes. PrestaShop zeigt auch Warnungen an, wenn der Wert unter dem empfohlenen Minimum liegt.

Mittels phpinfo()

Erstellen Sie eine temporaere Datei namens info.php im Stammverzeichnis Ihres PrestaShop mit folgendem Inhalt:

<?php phpinfo(); ?>

Rufen Sie sie ueber Ihren Browser unter ihredomain.de/info.php auf. Suchen Sie auf der Seite nach "memory_limit", um sowohl den Local Value (was tatsaechlich aktiv ist) als auch den Master Value (was in php.ini eingestellt ist) zu sehen. Der lokale Wert kann vom Master-Wert abweichen, wenn eine .htaccess-, .user.ini-Datei oder die Anwendung selbst ihn ueberschreibt.

Wichtig: Loeschen Sie diese Datei sofort nach der Ueberpruefung. Eine phpinfo()-Seite legt detaillierte Serverkonfigurationen offen, die Angreifer ausnutzen koennen.

Ueber die Kommandozeile

Wenn Sie SSH-Zugang haben, fuehren Sie aus:

php -i | grep memory_limit

Beachten Sie, dass die CLI-PHP-Konfiguration von der Webserver-Konfiguration abweichen kann. Um den webseitigen Wert zu pruefen, verwenden Sie die phpinfo()-Methode oder das PrestaShop Back Office.

Haeufige Ursachen fuer Memory-Limit-Fehler

Grosse Produktimporte

Das Importieren von Produkten per CSV ist eine der speicherintensivsten Operationen in PrestaShop. Jede Zeile in der Importdatei wird in den Speicher geladen, verarbeitet, validiert und in die Datenbank eingefuegt. Eine CSV-Datei mit 10.000 Produkten, jeweils mit mehreren Kombinationen, Bildern und Beschreibungen, kann leicht 512MB oder mehr Arbeitsspeicher erfordern.

PrestaShops Import-Tool verarbeitet Produkte in Stapeln, aber die Stapelgroesse und die Datenmenge pro Produkt bestimmen den gesamten Speicherbedarf. Grosse Textfelder (Beschreibungen mit HTML), viele Spalten und UTF-8-kodierte Dateien mit Sonderzeichen erhoehen den Speicherverbrauch pro Zeile.

Um den Speicherverbrauch waehrend des Imports zu reduzieren:

Teilen Sie grosse CSV-Dateien in kleinere Abschnitte auf (jeweils 1.000-2.000 Zeilen)
Importieren Sie Produkte zuerst ohne Bilder und importieren Sie die Bilder dann separat
Deaktivieren Sie nicht wesentliche Module waehrend des Imports (Statistiken, Suchindizierung)
Verwenden Sie den Kommandozeilen-Import, falls verfuegbar, der Webserver-Timeout-Limits umgeht

Produkte mit vielen Kombinationen

Produkte mit vielen Attributen (Groesse, Farbe, Material) erzeugen Kombinationen exponentiell. Ein Produkt mit 5 Groessen, 10 Farben und 3 Materialien erzeugt 150 Kombinationen. Jede Kombination ist ein separater Datenbankeintrag mit eigenem Preis, eigener Referenz, eigenem Lagerbestand und eigenen Bildverknuepfungen. Wenn PrestaShop eine Produktseite zur Bearbeitung im Back Office laedt, werden alle Kombinationen gleichzeitig in den Speicher geladen.

Produkte mit 500+ Kombinationen sind ein bekannter Schwachpunkt. Bei 1.000+ Kombinationen werden Sie mit der Standardkonfiguration fast sicher an Speichergrenzen stossen. Loesungen umfassen:

Erhoehung von memory_limit auf 512M oder 1G fuer das Back Office
Umstrukturierung von Produkten zur Reduzierung der Kombinationsanzahl (separate Produkte statt Mega-Kombinationen)
Verwendung von Modulen, die Kombinationen durch Paginierung effizienter handhaben

Aufgeblaehte oder schlecht programmierte Module

Drittanbieter-Module sind eine haeufige Quelle fuer Speicherprobleme. Gaengige Probleme umfassen:

Laden ganzer Datenbanktabellen in PHP-Arrays: Ein Modul, das SELECT * FROM ps_orders ohne LIMIT-Klausel ausfuehrt, laedt jede jemals aufgegebene Bestellung in den Speicher. Bei einem Shop mit 100.000 Bestellungen kann dies Hunderte von Megabyte verbrauchen.
Speicherlecks in Schleifen: Module, die Elemente in einer Schleife verarbeiten, aber Objekte ansammeln, ohne sie freizugeben. PHPs Garbage Collector behandelt einfache Faelle, aber zirkulaere Referenzen und gespeicherte Referenzen koennen die Bereinigung verhindern.
Uebermassiges Logging: Debug-Logging, das grosse Arrays oder Objekte in Logdateien schreibt, und die Verwendung von var_export() oder print_r() auf komplexen PrestaShop-Objekten kann enorme Mengen an Speicher verbrauchen.
Unoptimierte Bildverarbeitung: Module, die Bilder mit GD oder ImageMagick verkleinern oder mit Wasserzeichen versehen, laden das gesamte unkomprimierte Bild in den Speicher. Ein 5000x5000-Pixel-Bild mit 24-Bit-Farbtiefe benoetigt ungefaehr 75MB RAM allein fuer die Pixeldaten.

Um herauszufinden, welches Modul Speicherprobleme verursacht, pruefen Sie die Fehlermeldung sorgfaeltig. Sie enthaelt normalerweise einen Dateipfad, der auf das verantwortliche Modul verweist. Sie koennen auch den Debug-Modus von PrestaShop aktivieren, um detailliertere Stack-Traces zu erhalten.

Grosse Kataloge und komplexe Abfragen

Shops mit Zehntausenden von Produkten, vielen Kategorien und komplexen Attributstrukturen beanspruchen den Speicher waehrend des normalen Betriebs staerker. Kategorieseiten mit Schichtnavigation (Facettensuche) sind besonders anspruchsvoll, da die Filter-Engine verfuegbare Attributwerte ueber Tausende von Produkten hinweg berechnen muss.

Die Produktliste, Bestellliste und Kundenliste im Back Office laden alle Daten zur Anzeige in den Speicher. Bei sehr grossen Datensaetzen kann selbst die einfache Listenansicht an Speichergrenzen stossen, insbesondere wenn Module zusaetzliche Spalten oder Berechnungen zu diesen Listen hinzufuegen.

Smarty-Template-Kompilierung

PrestaShop verwendet die Smarty-Template-Engine, die Templates in PHP-Dateien kompiliert, um ein schnelleres Rendering zu ermoeglichen. Der Kompilierungsprozess selbst verbraucht Speicher, und komplexe Templates mit vielen Includes, Schleifen und bedingten Bloecken erfordern mehr Speicher fuer die Kompilierung. Nach der ersten Kompilierung werden gecachte Versionen verwendet, daher tritt dieses Problem primaer auf, wenn der Cache geleert wird oder waehrend der Entwicklung.

So erhoehen Sie das Memory Limit

Methode 1: php.ini

Die zuverlaessigste Methode ist die direkte Bearbeitung der PHP-Konfigurationsdatei. Der Speicherort haengt von Ihrem Setup ab:

Debian/Ubuntu: /etc/php/8.x/fpm/php.ini (PHP-FPM) oder /etc/php/8.x/apache2/php.ini (mod_php)
CentOS/RHEL: /etc/php.ini oder /etc/php.d/
cPanel: MultiPHP INI Editor in WHM oder cPanel

Finden Sie die memory_limit-Zeile und aendern Sie sie:

memory_limit = 512M

Nach dem Speichern starten Sie PHP-FPM oder Apache neu:

# PHP-FPM
sudo systemctl restart php8.2-fpm

# Apache mit mod_php
sudo systemctl restart apache2

Methode 2: .htaccess (nur Apache mit mod_php)

Fuegen Sie diese Zeile zur .htaccess-Datei in Ihrem PrestaShop-Stammverzeichnis hinzu:

php_value memory_limit 512M

Diese Methode funktioniert ausschliesslich mit Apache und mod_php. Wenn Sie PHP-FPM verwenden (was bei modernen Setups ueblicher ist), wird diese Direktive stillschweigend ignoriert oder kann einen 500-Fehler verursachen. Um zu pruefen, welchen PHP-Handler Sie verwenden, schauen Sie auf die Server API-Zeile in Ihrer phpinfo()-Ausgabe.

Methode 3: .user.ini (PHP-FPM)

Erstellen oder bearbeiten Sie eine Datei namens .user.ini in Ihrem PrestaShop-Stammverzeichnis:

memory_limit = 512M

PHP-FPM liest .user.ini-Dateien aus dem Document Root. Beachten Sie, dass Aenderungen nach Ablauf der user_ini.cache_ttl-Periode (Standard 300 Sekunden / 5 Minuten) wirksam werden, sodass Sie moeglicherweise warten oder PHP-FPM neu starten muessen, damit die Aenderung sofort greift.

Methode 4: Im PrestaShop-Code

PrestaShop setzt sein eigenes Memory Limit in der Datei config/defines.inc.php. Suchen Sie nach einer Zeile wie:

@ini_set('memory_limit', '256M');

Sie koennen diesen Wert direkt im Code erhoehen. Dieser Ansatz hat jedoch eine Einschraenkung: Die Funktion ini_set() kann das Memory Limit nur bis zum in php.ini gesetzten Wert erhoehen. Wenn php.ini auf memory_limit = 128M gesetzt ist und Ihr Code versucht, es auf 512M zu setzen, bleibt das tatsaechliche Limit bei 128M (es sei denn, der Master-Wert erlaubt Ueberschreibungen, was von der PHP_INI_ALL- vs. PHP_INI_SYSTEM-Klassifizierung abhaengt).

Methode 5: Pool-spezifische Konfiguration (PHP-FPM)

Wenn Sie Ihren eigenen Server verwalten, koennen Sie Speicherlimits pro PHP-FPM-Pool festlegen. Bearbeiten Sie die Pool-Konfigurationsdatei (z.B. /etc/php/8.2/fpm/pool.d/www.conf) und fuegen Sie hinzu:

php_admin_value[memory_limit] = 512M

Die Verwendung von php_admin_value macht diese Einstellung unveraenderlich — sie kann nicht durch .user.ini oder ini_set() ueberschrieben werden. Dies ist nuetzlich zur Durchsetzung von Limits in Multi-Tenant-Umgebungen.

Pro-Prozess- vs. gemeinsamer Speicher

Es ist wichtig zu verstehen, dass memory_limit fuer jeden einzelnen PHP-Prozess gilt, nicht fuer PHP insgesamt. Wenn Sie memory_limit = 512M setzen und Ihr Server 20 gleichzeitige PHP-Prozesse ausfuehrt, betraegt der theoretische maximale Speicherverbrauch durch PHP 10GB (20 x 512MB).

Deshalb kann blindes Erhoehen des Memory Limits Probleme verursachen. Auf einem Server mit 4GB RAM bedeutet die Einstellung memory_limit = 1G mit 10 PHP-FPM-Workern, dass PHP allein versuchen koennte, 10GB zu nutzen, was starkes Swapping verursacht oder den Linux OOM-Killer ausloest, der Prozesse zwangsweise beendet, um Speicher freizugeben.

Der richtige Ansatz ist, das Memory Limit mit der Anzahl der PHP-Worker auszubalancieren:

Verfuegbarer RAM fuer PHP = Gesamter RAM - Betriebssystem-Overhead - MySQL-Speicher - Webserver-Speicher - andere Dienste
Maximale PHP-Worker = Verfuegbarer RAM fuer PHP / memory_limit

Beispielsweise auf einem 4GB-VPS: 4GB gesamt - 0,5GB Betriebssystem - 1GB MySQL - 0,25GB Nginx = 2,25GB fuer PHP. Mit memory_limit = 256M koennen Sie sicher 8-9 PHP-FPM-Worker ausfuehren. Mit memory_limit = 512M koennen Sie nur 4 Worker ausfuehren, was bedeutet, dass weniger gleichzeitige Anfragen bedient werden koennen.

Konfigurieren Sie den PHP-FPM-Pool entsprechend:

pm = dynamic
pm.max_children = 8
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 5

Speicherlecks und uebermassige Nutzung diagnostizieren

Wenn das Erhoehen des Memory Limits den Fehler nur hinauszogert, anstatt ihn zu beheben, haben Sie wahrscheinlich ein Speicherleck oder einen ineffizienten Prozess. So diagnostizieren Sie die Grundursache.

PrestaShop Debug-Modus aktivieren

Bearbeiten Sie config/defines.inc.php und setzen Sie:

define('_PS_MODE_DEV_', true);

Dies aktiviert detaillierte Fehlerberichte, einschliesslich der genauen Datei und Zeilennummer, an der das Memory Limit ueberschritten wurde. Der Stack-Trace zeigt die Kette von Funktionsaufrufen, die zum Fehler gefuehrt haben, und hilft Ihnen, das verantwortliche Modul oder die Kernfunktion zu identifizieren.

Speichernutzung im Code ueberwachen

Sie koennen Speicherueberwachung zu bestimmten Codeabschnitten hinzufuegen, um festzustellen, wo Speicherspitzen auftreten:

error_log('Speicher vor Operation: ' . memory_get_usage(true) / 1024 / 1024 . ' MB');
// ... Operation ...
error_log('Speicher nach Operation: ' . memory_get_usage(true) / 1024 / 1024 . ' MB');
error_log('Maximale Speichernutzung: ' . memory_get_peak_usage(true) / 1024 / 1024 . ' MB');

Die Funktion memory_get_usage(true) gibt die tatsaechliche vom Betriebssystem an PHP zugewiesene Speichermenge zurueck, waehrend memory_get_peak_usage(true) das Maximum zurueckgibt, das zu irgendeinem Zeitpunkt waehrend der Anfrage zugewiesen wurde.

Xdebug-Profiling verwenden

Xdebugs Profiler generiert detaillierte Berichte ueber Funktionsaufrufe, Ausfuehrungszeit und Speicherverbrauch. Aktivieren Sie ihn voruebergehend in Ihrer PHP-Konfiguration:

xdebug.mode = profile
xdebug.output_dir = /tmp/xdebug

Oeffnen Sie die generierten Cachegrind-Dateien in einem Tool wie KCacheGrind oder Webgrind, um zu visualisieren, welche Funktionen am meisten Speicher verbrauchen. Dies ist der gruendlichste Diagnoseansatz, sollte aber aufgrund des erheblichen Performance-Overheads nur auf Entwicklungsservern verwendet werden.

Langsame Abfragen und MySQL pruefen

Manchmal ist das, was als PHP-Speicherproblem erscheint, tatsaechlich ein MySQL-Problem. Eine langsame Abfrage, die Millionen von Zeilen zurueckgibt, veranlasst PHP, Speicher fuer das gesamte Ergebnisset zuzuweisen. Pruefen Sie das MySQL Slow-Query-Log:

sudo tail -100 /var/log/mysql/slow-query.log

Wenn Sie Abfragen mit grossen Ergebnismengen sehen, fuegen Sie entsprechende LIMIT-Klauseln hinzu oder implementieren Sie Paginierung im verantwortlichen Modul.

OPcache-Speicher

OPcache ist eine PHP-Erweiterung, die kompilierten PHP-Bytecode in gemeinsam genutztem Speicher zwischenspeichert und damit die Notwendigkeit eliminiert, PHP-Dateien bei jeder Anfrage zu parsen und zu kompilieren. OPcache hat seine eigene Speicherzuweisung, getrennt von memory_limit.

Der Standard-OPcache-Speicher (opcache.memory_consumption) betraegt 128MB. PrestaShop mit mehreren installierten Modulen kann diesen leicht ueberschreiten. Wenn OPcache keinen Speicher mehr hat, beginnt es, gecachte Eintraege zu verdraengen und Dateien bei jeder Anfrage neu zu kompilieren, was zu erheblicher Leistungsminderung fuehrt.

Pruefen Sie den OPcache-Status ueber die Kommandozeile:

php -r "print_r(opcache_get_status());"

Oder schauen Sie sich den opcache-Abschnitt in Ihrer phpinfo()-Ausgabe an. Wichtige zu ueberwachende Werte:

opcache.memory_consumption: Gesamter fuer OPcache zugewiesener Speicher (fuer PrestaShop auf 256M erhoehen)
opcache.max_accelerated_files: Maximale Anzahl von Dateien, die OPcache cachen kann (fuer PrestaShop auf 20000 erhoehen)
Genutzter Speicher vs. Freier Speicher: Wenn der freie Speicher nahe Null ist, erhoehen Sie memory_consumption
Cache-Trefferquote: Sollte ueber 99% liegen. Unter 95% deutet auf Speicherdruck oder haeufige Cache-Invalidierung hin

Empfohlene OPcache-Konfiguration fuer PrestaShop:

opcache.enable = 1
opcache.memory_consumption = 256
opcache.max_accelerated_files = 20000
opcache.validate_timestamps = 1
opcache.revalidate_freq = 0
opcache.interned_strings_buffer = 16

Beachten Sie, dass OPcache-Speicher gemeinsam ueber alle PHP-Prozesse genutzt wird, im Gegensatz zu memory_limit, das pro Prozess gilt. Die Erhoehung des OPcache-Speichers multipliziert sich nicht mit der Anzahl der Worker.

MySQL-Speicherkonfiguration

MySQL hat seine eigene Speicherkonfiguration, die die PrestaShop-Performance indirekt beeinflusst und zum gesamten Speicherdruck auf dem Server beitragen kann. Wichtige MySQL-Speichereinstellungen umfassen:

innodb_buffer_pool_size: Der Hauptspeicherpuffer fuer InnoDB-Tabellen. Setzen Sie ihn auf 50-70% des verfuegbaren RAMs auf einem dedizierten Datenbankserver oder 25-50% auf einem Shared Server, der sowohl PHP als auch MySQL ausfuehrt. Dies ist die wichtigste einzelne MySQL-Performance-Einstellung.
sort_buffer_size und join_buffer_size: Pro-Verbindungs-Puffer fuer Sortierung und Joins. Belassen Sie diese auf den Standardwerten, es sei denn, Sie haben spezifische langsame Abfragen, die von groesseren Puffern profitieren. Zu hohe Werte verschwenden Speicher, da sie pro Verbindung zugewiesen werden.
query_cache_size: In MySQL 8.0 veraltet und vollstaendig entfernt. Wenn Sie noch MySQL 5.7 verwenden, kann ein kleiner Query-Cache (64M) helfen, aber grosse Query-Caches verursachen Kontention und reduzieren die Performance.

Wenn MySQL zu viel Speicher verbraucht, bleibt weniger fuer PHP uebrig, was Sie moeglicherweise zwingt, PHP-FPM-Worker oder das Memory Limit zu reduzieren. Verwenden Sie mysqladmin status oder SHOW GLOBAL STATUS, um den MySQL-Speicherverbrauch zu ueberwachen.

Wann Sie Ihr Hosting upgraden sollten

Manchmal reicht es nicht aus, das Memory Limit zu erhoehen und Ihren Code zu optimieren. Hier sind Anzeichen, dass Sie einen leistungsfaehigeren Server benoetigen:

Sie laufen staendig am maximalen Memory Limit: Wenn Ihre Prozesse regelmaessig 90%+ des zugewiesenen Speichers nutzen, selbst nach Optimierung, benoetigen Sie mehr RAM.
Der Server swappt haeufig: Pruefen Sie mit free -h oder vmstat 1. Wenn die Swap-Nutzung konstant hoch ist, haben Sie nicht genuegend physischen RAM.
Die Reduzierung der PHP-Worker beeintraechtigt die Performance: Wenn Sie PHP-FPM-Worker auf 3-4 reduzieren mussten, um das Memory Limit unterzubringen, kann Ihre Website gleichzeitige Besucher nicht effektiv bedienen.
Ihr Katalog waechst stetig: Ein Shop, der mit 1.000 Produkten gut funktionierte, kann mit 10.000 Schwierigkeiten haben. Der Speicherbedarf skaliert mit der Kataloggroesse, insbesondere fuer Suchindizierung, Kategorielistung und Back-Office-Operationen.
Sie benoetigen ein memory_limit ueber 1G: Wenn ein einzelner PHP-Prozess fuer normale Operationen (nicht Importe) mehr als 1GB Speicher benoetigt, stimmt etwas grundlegend nicht mit Ihrem Code oder Ihrer Hosting-Kapazitaet. Untersuchen Sie die Grundursache, bevor Sie das Limit einfach weiter erhoehen.

Beim Upgrade priorisieren Sie mehr RAM gegenueber mehr CPU-Kernen fuer PrestaShop. Ein Server mit 8GB RAM und 2 Kernen bedient PrestaShop besser als einer mit 4GB RAM und 4 Kernen. Erwaegen Sie auch, MySQL auf einen eigenen Server auszulagern oder einen Managed-Database-Service zu verwenden, der den RAM des Anwendungsservers vollstaendig fuer PHP freigibt.

Kurzreferenz: Empfohlene Einstellungen nach Shopgroesse

Die folgenden Empfehlungen dienen als Ausgangspunkte. Ueberwachen Sie Ihre tatsaechliche Nutzung und passen Sie entsprechend an.

Kleiner Shop (unter 1.000 Produkte, wenige Module): memory_limit = 256M, 2GB RAM, 4-6 PHP-Worker
Mittlerer Shop (1.000-10.000 Produkte, 20+ Module): memory_limit = 512M, 4GB RAM, 6-8 PHP-Worker
Grosser Shop (10.000+ Produkte, viele Kombinationen): memory_limit = 512M-1G, 8GB+ RAM, 8-16 PHP-Worker, separater Datenbankserver
Waehrend Importen: Voruebergehend auf 1G oder 2G erhoehen, dann den normalen Wert wiederherstellen

Denken Sie daran, dass das Memory Limit eine Sicherheitsobergrenze ist, kein Zielwert. Ein gut optimierter PrestaShop-Shop sollte fuer normale Seitenabrufe selten mehr als 128-256MB pro Anfrage nutzen. Wenn normale Operationen konsistent 512MB oder mehr benoetigen, untersuchen und beheben Sie die zugrunde liegende Ursache, anstatt das Limit weiter zu erhoehen.

Vollständige Antwort lesen

max_input_vars in PrestaShop verstehen

Wenn Sie schon einmal versucht haben, ein Produkt mit Dutzenden oder Hunderten von Kombinationen in PrestaShop zu speichern und dabei ein stilles Versagen, ein unvollstaendiges Speichern oder einen kryptischen Fehler erhalten haben, ist der Verursacher fast sicher die PHP-Direktive max_input_vars. Diese Einstellung steuert, wie viele einzelne Formularfelder PHP in einer einzigen POST-Anfrage akzeptiert. Wenn PrestaShop ein Produktformular uebermittelt, das dieses Limit ueberschreitet, wird jedes Feld jenseits des Schwellenwerts stillschweigend verworfen, was zu unvollstaendigen Speicherungen, fehlenden Kombinationen oder Daten fuehrt, die einfach ohne sichtbare Fehlermeldung verschwinden.

Standardmaessig werden die meisten PHP-Installationen mit max_input_vars auf 1000 gesetzt ausgeliefert. Fuer einen einfachen Blog oder eine Broschueren-Website ist das mehr als genug. Fuer PrestaShop koennen Produktbearbeitungsseiten jedoch Tausende von Formularfeldern generieren, insbesondere wenn Kombinationen, mehrsprachige Felder und benutzerdefinierte Eigenschaften beteiligt sind. Das Verstaendnis dieser Direktive, das Wissen, wie Sie den tatsaechlich von Ihrem Shop benoetigten Wert berechnen, und die korrekte Anwendung der Loesung werden Ihnen stundenlange Fehlersuche ersparen.

Warum PrestaShop hohe max_input_vars-Werte benoetigt

Das Produktbearbeitungsformular von PrestaShop ist eines der komplexesten Formulare in jeder E-Commerce-Plattform. Jede Kombination eines Produkts erzeugt mehrere Eingabefelder: eines fuer die Preisauswirkung, eines fuer die Gewichtsauswirkung, eines fuer die Menge, eines fuer die Referenz, eines fuer die EAN-13, eines fuer den UPC, eines fuer die MPN, eines fuer die Mindestmenge, eines fuer den Niedrigbestandsschwellenwert, eines fuer das Verfuegbarkeitsdatum und noch einige weitere je nach Konfiguration. Eine einzelne Kombination kann leicht 15 bis 25 Formularfelder erzeugen.

Multiplizieren Sie das nun mit der Anzahl der Kombinationen. Ein T-Shirt, erhaeltlich in 5 Groessen und 10 Farben, hat 50 Kombinationen. Bei 20 Feldern pro Kombination sind das bereits 1.000 Felder allein fuer den Kombinationen-Tab. Addieren Sie die Basisproduktfelder, SEO-Felder fuer jede Sprache, Eigenschaftswerte, Spezialpreise und andere Tabs hinzu, und Sie erreichen leicht 1.500 bis 2.000 Felder fuer ein maessig komplexes Produkt.

Fuer Shops, die Produkte mit umfangreichen Attributsaetzen verkaufen, wie Elektronik mit verschiedenen Speicherkapazitaeten, Farben, RAM-Optionen und regionalen Varianten, kann ein einzelnes Produkt 200 oder mehr Kombinationen haben und so 4.000+ Formularfelder erzeugen. Das Standardlimit von 1.000 reicht bei weitem nicht aus.

Symptome eines zu niedrigen max_input_vars

Der frustrierendste Aspekt beim Erreichen des max_input_vars-Limits ist, dass PHP keinen Fehler ausloest. Es kuerzt die Eingabedaten stillschweigend. Das bedeutet, Sie sehen eine Vielzahl verwirrender Symptome ohne klaren Hinweis darauf, was schiefgelaufen ist.

Das haeufigste Symptom ist, dass Kombinationen nach dem Speichern verschwinden. Sie erstellen 80 Kombinationen, klicken auf Speichern, und beim Neuladen der Seite sind nur 40 vorhanden. Das Formular hat alle 80 uebermittelt, aber PHP hat nur den ersten Teil der POST-Daten verarbeitet, bevor es das Limit erreicht hat, sodass die verbleibenden Kombinationen nie vom Server empfangen wurden.

Ein weiteres haeufiges Symptom ist, dass Produktdaten teilweise gespeichert werden. Der Tab mit den grundlegenden Informationen wird korrekt gespeichert, aber die Preis-, SEO- oder Kombinationsdaten gehen verloren. Dies geschieht, weil die Formularfelder in einer bestimmten Reihenfolge uebermittelt werden, und alle Felder, die nach dem Abschneidepunkt kommen, verworfen werden.

Moeglicherweise erleben Sie auch, dass die Produktseite einfach neu laedt, ohne zu speichern, oder PrestaShop zeigt einen generischen Fehler wie "Bei der Aktualisierung des Produkts ist ein Fehler aufgetreten." In PrestaShop 1.7 und 8.x kann die Symfony-basierte Produktseite Validierungsfehler fuer Pflichtfelder anzeigen, die tatsaechlich ausgefuellt, aber von PHP abgeschnitten wurden.

Ein weniger offensichtliches Symptom betrifft mehrsprachige Shops. Wenn Ihr Shop 5 Sprachen unterstuetzt, wird jedes Textfeld mit 5 multipliziert. Ein Produkt, das in einem einsprachigen Shop problemlos gespeichert wird, scheitert in einem mehrsprachigen, weil die zusaetzlichen Sprachfelder die Gesamtzahl ueber das Limit treiben.

So pruefen Sie Ihren aktuellen max_input_vars-Wert

Bevor Sie Aenderungen vornehmen, ueberpruefen Sie Ihre aktuelle Einstellung. Erstellen Sie eine PHP-Datei im Stammverzeichnis Ihres PrestaShop (denken Sie daran, sie anschliessend aus Sicherheitsgruenden zu loeschen):

<?php phpinfo(); ?>

Rufen Sie diese Datei ueber Ihren Browser auf und suchen Sie nach max_input_vars. Sie sehen sowohl den Local Value (was aktuell aktiv ist) als auch den Master Value (die Standardeinstellung aus php.ini). Achten Sie auf den Local Value, da er vom Master Value abweichen kann, wenn eine .htaccess- oder verzeichnisbezogene Konfiguration ihn ueberschreibt.

Alternativ koennen Sie die Einstellung im PrestaShop Back Office pruefen. Navigieren Sie zu Erweiterte Einstellungen, dann Informationen. Der PHP-Konfigurationsbereich zeigt wichtige PHP-Einstellungen einschliesslich max_input_vars an. PrestaShop 1.7.7 und spaetere Versionen zeigen auf dieser Seite auch eine Warnung an, wenn der Wert als zu niedrig eingestuft wird.

Den benoetigten max_input_vars-Wert berechnen

Anstatt blind eine hohe Zahl zu setzen, koennen Sie den Wert abschaetzen, den Ihr Shop benoetigt. Verwenden Sie diese Formel als Ausgangspunkt:

Benoetigter Wert = (Anzahl der Kombinationen x Felder pro Kombination) + Basisproduktfelder + (Textfelder x Anzahl der Sprachen) + Sicherheitsmarge

Fuer ein praktisches Beispiel betrachten Sie einen Shop mit 3 Sprachen und einem Produkt mit 100 Kombinationen. Die Berechnung sieht folgendermassen aus: 100 Kombinationen multipliziert mit 20 Feldern ergibt 2.000. Die Basisproduktfelder ueber alle Tabs tragen rund 200 bei. Textfelder (Name, Beschreibung, Meta-Titel, Meta-Beschreibung, Link-Rewrite und andere) multipliziert mit 3 Sprachen addieren weitere 150. Mit einer 20%-Sicherheitsmarge ergibt sich ein Gesamtbedarf von ungefaehr 2.820.

Fuer die meisten PrestaShop-Shops bietet eine Einstellung von max_input_vars auf 10000 ausreichend Spielraum. Shops mit Produkten, die 300+ Kombinationen haben, oder die in 5+ Sprachen betrieben werden, sollten 20000 oder sogar 50000 in Betracht ziehen. Der Speicher-Overhead eines hoeheren Wertes ist auf modernen Servern vernachlaessigbar.

So erhoehen Sie max_input_vars

Methode 1: php.ini (Empfohlen)

Wenn Sie Zugriff auf die PHP-Konfiguration Ihres Servers haben, ist die Bearbeitung der php.ini der sauberste Ansatz. Suchen Sie Ihre php.ini-Datei (die phpinfo()-Ausgabe zeigt Ihnen genau, welche Datei geladen wird) und finden oder fuegen Sie die folgende Zeile hinzu:

max_input_vars = 10000

Starten Sie nach dem Speichern der Datei Ihren Webserver oder PHP-FPM-Dienst neu, damit die Aenderung wirksam wird. Bei Apache mit mod_php starten Sie Apache neu. Bei Nginx mit PHP-FPM starten Sie den php-fpm-Dienst neu. Der genaue Befehl haengt von Ihrem Betriebssystem und Ihrer PHP-Version ab.

Methode 2: .htaccess (Apache mit mod_php oder mod_fcgid)

Wenn Sie keinen Zugriff auf die php.ini haben, beispielsweise bei Shared Hosting, koennen Sie versuchen, die Direktive in die .htaccess-Datei im Stammverzeichnis Ihres PrestaShop einzufuegen:

php_value max_input_vars 10000

Diese Methode funktioniert nur, wenn PHP als Apache-Modul (mod_php) ausgefuehrt wird. Wenn Ihr Hoster PHP-FPM oder CGI verwendet, verursacht diese Direktive einen 500 Internal Server Error. Entfernen Sie in diesem Fall die Zeile sofort und versuchen Sie die naechste Methode.

Methode 3: .user.ini (PHP-FPM / CGI)

Fuer Server mit PHP-FPM erstellen oder bearbeiten Sie eine .user.ini-Datei im Stammverzeichnis Ihres PrestaShop:

max_input_vars = 10000

Beachten Sie, dass .user.ini-Aenderungen nicht sofort wirksam werden. PHP cached diese Datei fuer einen Zeitraum, der durch user_ini.cache_ttl definiert wird, was standardmaessig 300 Sekunden (5 Minuten) betraegt. Warten Sie mindestens 5 Minuten nach dem Speichern der Datei, bevor Sie testen.

Methode 4: Hosting-Kontrollpanel

Viele Hosting-Anbieter stellen PHP-Einstellungen ueber ihr Kontrollpanel zur Verfuegung. In cPanel navigieren Sie zu "PHP-Version waehlen" oder "MultiPHP INI Editor" und suchen nach max_input_vars. In Plesk gehen Sie zu den PHP-Einstellungen fuer Ihre Domain. DirectAdmin und andere Panels haben aehnliche Optionen. Dies ist oft die einfachste Methode bei Shared Hosting.

Die Suhosin-Patch-Komplikation

Suhosin ist ein PHP-Sicherheitspatch, der auf aelteren Servern verbreitet war, insbesondere auf solchen mit PHP 5.x. Er erzwingt eigene Eingabelimits, die die Standard-Einstellung max_input_vars ueberschreiben. Selbst wenn Sie max_input_vars auf 10000 erhoehen, kann Suhosin durch seine eigenen Direktiven weiterhin ein niedrigeres Limit durchsetzen.

Die Suhosin-spezifischen Einstellungen, die Sie anpassen muessen, sind:

suhosin.post.max_vars = 10000
suhosin.request.max_vars = 10000

Diese muessen zusaetzlich zum Standard-max_input_vars gesetzt werden. Wenn Ihre phpinfo()-Ausgabe einen Suhosin-Abschnitt zeigt, sind Sie betroffen und muessen alle drei Werte anpassen. Suhosin-Einstellungen koennen typischerweise nur in der php.ini geaendert werden, nicht in .htaccess oder .user.ini.

Auf modernen PHP 7.x- und 8.x-Installationen ist Suhosin selten vorhanden. Wenn Sie eine aktuelle PHP-Version ausfuehren, muessen Sie sich fast sicher keine Sorgen darueber machen. Wenn Sie jedoch ein aelteres Shared-Hosting-Konto nutzen, das nicht aktualisiert wurde, lohnt sich die Ueberpruefung.

Alternative Ansaetze fuer Produkte mit 500+ Kombinationen

Waehrend die Erhoehung von max_input_vars das unmittelbare Problem loest, sollten Shops mit extrem vielen Kombinationen pro Produkt alternative Ansaetze in Betracht ziehen, die die Anzahl der Formularfelder reduzieren oder die Beschraenkung vollstaendig umgehen.

Kombinationen per CSV importieren

Die integrierte Importfunktion von PrestaShop verarbeitet Kombinationen ueber Datei-Upload statt ueber Formularuebermittlung und umgeht so das max_input_vars-Limit vollstaendig. Bereiten Sie eine CSV-Datei mit Ihren Kombinationsdaten vor und importieren Sie sie ueber das Back Office unter Erweiterte Einstellungen, Import. Dies ist oft der praktischste Ansatz fuer Produkte mit Hunderten von Kombinationen.

PrestaShop Webservice API verwenden

Die PrestaShop Webservice API ermoeglicht es Ihnen, Kombinationen programmgesteuert zu erstellen und zu aktualisieren. API-Anfragen unterliegen nicht max_input_vars, da sie strukturierte XML- oder JSON-Payloads verwenden statt formularcodierter POST-Daten. Dieser Ansatz erfordert technisches Wissen, skaliert aber auf jede beliebige Anzahl von Kombinationen.

Grosse Produkte aufteilen

In manchen Faellen ist es geschaeftlich sinnvoller, ein Produkt mit 500+ Kombinationen in mehrere Produkte aufzuteilen. Ein Produkt mit 5 Groessen und 100 Farben koennte in 5 Produkte aufgeteilt werden, eines pro Groesse, jeweils mit 100 Farboptionen. Dies vermeidet nicht nur die technische Beschraenkung, sondern verbessert oft auch das Kundenerlebnis.

Kombinationen in Stapeln verwalten

Wenn Sie das Back-Office-Formular verwenden muessen, erstellen Sie Kombinationen in kleineren Stapeln. Generieren Sie jeweils 50 Kombinationen, speichern Sie, dann generieren Sie die naechsten 50. Dies ist muehsam, vermeidet aber das Erreichen des Limits, ohne Aenderungen an der Serverkonfiguration zu erfordern.

Die Loesung ueberpruefen

Ueberpruefen Sie nach der Erhoehung von max_input_vars, ob die Aenderung wirksam geworden ist. Pruefen Sie phpinfo() erneut und bestaetigen Sie, dass der Local Value mit dem uebereinstimmt, was Sie eingestellt haben. Testen Sie dann, indem Sie Ihr komplexestes Produkt bearbeiten, eine kleine Aenderung vornehmen und speichern. Alle Kombinationen und Daten sollten erhalten bleiben.

Wenn das Problem nach der Erhoehung des Wertes weiterhin besteht, pruefen Sie diese zusaetzlichen Moeglichkeiten. Ihr Hosting-Anbieter koennte Ihre Einstellungen mit einer globalen Konfiguration ueberschreiben. Die PHP-Instanz, die Ihre Website bedient, koennte sich von der in einer CLI-phpinfo() angezeigten unterscheiden. Es koennte ein Webserver-Limit wie Apaches LimitRequestBody oder Nginx' client_max_body_size geben, das die Anfrage ebenfalls beschneidet. Einige Web Application Firewalls (WAF) oder Sicherheitsplugins (wie ModSecurity) erzwingen eigene Limits fuer die POST-Datengroesse und Anzahl der Parameter.

PrestaShop-versionsspezifische Hinweise

In PrestaShop 1.6 basiert die Produktseite vollstaendig auf Legacy-PHP mit einer traditionellen Formularuebermittlung. Das max_input_vars-Problem betrifft alle Operationen auf der Produktseite. Es gibt keinen Workaround ausser der Erhoehung des Limits oder der Verwendung von Importen.

PrestaShop 1.7 fuehrte eine teilweise Symfony-basierte Produktseite ein. Obwohl sich die Architektur aenderte, verwendet die zugrunde liegende Formularuebermittlung weiterhin POST-Daten und unterliegt denselben PHP-Limits. Die Symfony-Formularkomponente kann informativere Fehlermeldungen anzeigen, wenn Felder fehlen, aber die Grundursache ist dieselbe.

PrestaShop 8.x bietet eine vollstaendig neu gestaltete Produktseite mit einer neuen Symfony-Formularstruktur. Die Kombinationsverwaltung wurde erheblich ueberarbeitet, wobei Kombinationen nun ueber eine dedizierte Oberflaeche verwaltet werden, die Daten per AJAX in kleineren Stapeln laedt und speichert. Diese architektonische Aenderung reduziert auf natuerliche Weise die Auswirkungen von max_input_vars fuer Kombinationsdaten, obwohl das Hauptproduktformular in mehrsprachigen Shops mit vielen Eigenschaften weiterhin betroffen sein kann.

PrestaShop 9.x setzt den Trend zur AJAX-basierten Datenverarbeitung fort und reduziert die Abhaengigkeit von massiven Formularuebermittlungen weiter. Allerdings bleibt max_input_vars relevant fuer Massenoperationen und Legacy-Module, die weiterhin traditionelle Formularuebermittlungen verwenden.

Zukuenftigen Problemen vorbeugen

Setzen Sie max_input_vars bereits bei der Erstinstallation Ihres PrestaShop auf einen grosszuegigen Wert, anstatt auf das Auftreten von Problemen zu warten. Ein Wert von 20000 ist fuer praktisch alle Szenarien sicher und hat keine nennenswerten Auswirkungen auf die Leistung. Dokumentieren Sie die Einstellung in Ihren Serverkonfigurationsnotizen, damit zukuenftige Servermigrationen sie beibehalten.

Wenn Sie ein Hosting-Anbieter oder Systemadministrator sind, der mehrere PrestaShop-Installationen verwaltet, erwaegen Sie, max_input_vars = 20000 als Standard in Ihren PHP-Konfigurationsvorlagen festzulegen. Diese einzelne Aenderung eliminiert eine der haeufigsten Support-Anfragen im Zusammenhang mit der PrestaShop-Produktverwaltung.

Ueberwachen Sie Ihre Fehlerprotokolle nach dem Vornehmen von Aenderungen. Obwohl die max_input_vars-Kuerzung selbst keine PHP-Fehler generiert, protokollieren einige PrestaShop-Versionen Warnungen, wenn sie erkennen, dass empfangene Daten nicht mit erwarteten Daten uebereinstimmen. Diese Protokolleintraege koennen Ihnen helfen festzustellen, ob das Limit trotz Ihrer Erhoehung immer noch erreicht wird.

Vollständige Antwort lesen

Warum nach PrestaShop-Updates weisse Seiten auftreten

Eine leere weisse Seite, oft als White Screen of Death (WSOD) bezeichnet, ist eines der haeufigsten und alarmierendsten Probleme, mit denen PrestaShop-Shopbetreiber nach der Aktualisierung der Core-Software konfrontiert werden. Sie starten ein Update von 1.7.8.7 auf 1.7.8.8 oder von 8.1.0 auf 8.1.5, der Prozess scheint abzuschliessen, und dann zeigt Ihr gesamter Shop, sowohl Front Office als auch Back Office, nichts ausser einem weissen Bildschirm an. Keine Fehlermeldung, kein teilweiser Inhalt, nur Leere.

Um zu verstehen, warum das passiert, muss man verstehen, was ein PrestaShop Core-Update bewirkt. Der Aktualisierungsprozess ersetzt Hunderte von PHP-Dateien, aendert Datenbanktabellen, regeneriert Klassen-Indizes, leert Caches und fuehrt moeglicherweise Migrations-Queries aus. Jedes Versagen an jedem Punkt dieser Kette kann den Shop in einem inkonsistenten Zustand hinterlassen, in dem PHP auf einen fatalen Fehler stoesst, ihn aber nicht anzeigen kann, weil die Fehlerausgabe im Produktionsmodus deaktiviert ist.

Die haeufigsten Ursachen lassen sich in mehrere Kategorien einteilen: inkompatible Module, die auf entfernte oder geaenderte Core-Klassen verweisen, PHP-Versionsinkompatibilitaeten zwischen der alten und neuen PrestaShop-Version, Override-Dateikonflikte, bei denen benutzerdefinierte Overrides mit geaenderten Core-Dateien kollidieren, unzureichende Serverressourcen, die dazu fuehren, dass das Update mittendrin abgebrochen wird, und fehlgeschlagene Datenbankmigrationen, die Tabellen in einem inkonsistenten Zustand hinterlassen.

Schritt 1: Debug-Modus aktivieren

Die allererste Massnahme bei einer leeren Seite ist, Fehler sichtbar zu machen. PrestaShop unterdrueckt die Fehlerausgabe im Produktionsmodus, um zu verhindern, dass sensible Informationen den Besuchern preisgegeben werden. Sie muessen voruebergehend den Debug-Modus aktivieren, um zu sehen, was tatsaechlich schiefgeht.

Die schnellste Methode ist die Bearbeitung der Datei /config/defines.inc.php. Suchen Sie die Zeile, die _PS_MODE_DEV_ definiert, und aendern Sie sie:

define('_PS_MODE_DEV_', true);

Wenn Sie nicht per FTP oder SSH auf Dateien zugreifen koennen, weil auch Ihr Hosting-Panel unzugaenglich ist, bieten einige Hosting-Anbieter einen Dateimanager ueber ihr Kontrollpanel (cPanel, Plesk, DirectAdmin), der unabhaengig von Ihrer PrestaShop-Installation funktioniert.

In PrestaShop 8.x koennen Sie den Debug-Modus auch ueber die .env-Datei im Stammverzeichnis aktivieren. Aendern Sie APP_ENV=prod zu APP_ENV=dev und setzen Sie APP_DEBUG=1. Dies aktiviert die Symfony-Debug-Toolbar und detaillierte Fehlerseiten.

Laden Sie nach dem Aktivieren des Debug-Modus die Seite neu. Anstelle eines leeren Bildschirms sollten Sie nun eine detaillierte Fehlermeldung mit Dateipfad, Zeilennummer und Stack-Trace sehen. Diese Fehlermeldung ist der Schluessel zur Diagnose und Behebung des Problems.

Schritt 2: Fehlerprotokolle pruefen

Wenn das Aktivieren des Debug-Modus weiterhin eine leere Seite anzeigt (was passieren kann, wenn der Fehler auftritt, bevor PHP ueberhaupt das PrestaShop-Framework laedt), pruefen Sie die Fehlerprotokolle Ihres Servers direkt.

Auf Apache-Servern befindet sich das Fehlerprotokoll typischerweise unter /var/log/apache2/error.log oder /var/log/httpd/error_log. Auf Nginx mit PHP-FPM pruefen Sie /var/log/nginx/error.log und /var/log/php-fpm/error.log (oder /var/log/php8.1-fpm.log, je nach PHP-Version). Auf Shared Hosting sind Fehlerprotokolle normalerweise ueber das Hosting-Kontrollpanel oder in einem logs-Verzeichnis innerhalb Ihres Hosting-Kontos zugaenglich.

PrestaShop pflegt auch eigene Logdateien im Verzeichnis /var/logs/ (PrestaShop 1.7) oder /var/log/ (PrestaShop 8.x). Suchen Sie nach Dateien mit dem aktuellen Datum. Diese Symfony-basierten Logs koennen detaillierte Informationen darueber enthalten, was waehrend des Update-Prozesses schiefgelaufen ist.

Ueberpruefen Sie zusaetzlich das Verzeichnis /log/ im PrestaShop-Stammverzeichnis auf Fehlerprotokolldateien. Einige PrestaShop-Versionen schreiben kritische Fehler hierhin, wenn sie sie nicht auf dem Bildschirm anzeigen koennen.

Haeufige Ursache 1: Inkompatible Module

Module sind die haeufigste Ursache fuer weisse Seiten nach Updates. Ein Modul, das auf PrestaShop 1.7.8.7 perfekt funktionierte, kann den gesamten Shop auf 1.7.8.8 zum Absturz bringen, wenn es interne Core-Klassen oder -Methoden verwendet, die sich im Update geaendert haben.

Die Fehlermeldung sieht typischerweise so aus: Fatal error: Class 'SomeClassName' not found oder Fatal error: Call to undefined method ClassName::methodName() oder Fatal error: Declaration of ModuleClass::hookMethod() must be compatible with CoreClass::hookMethod().

Um dies zu beheben, muessen Sie das problematische Modul identifizieren und deaktivieren. Wenn Sie auf das Back Office zugreifen koennen (manchmal stuerzt nur das Front Office ab), gehen Sie zu Module und deaktivieren Sie kuerzlich installierte oder aktualisierte Module einzeln, bis sich das Problem loest.

Wenn auch das Back Office unzugaenglich ist, deaktivieren Sie Module ueber die Datenbank. Verbinden Sie sich mit Ihrer Datenbank ueber phpMyAdmin oder einen MySQL-Client und fuehren Sie aus:

UPDATE ps_module SET active = 0 WHERE name = 'problematischer_modulname';

Wenn Sie nicht wissen, welches Modul das Problem verursacht, koennen Sie alle Drittanbieter-Module auf einmal deaktivieren, indem Sie deren active-Spalte auf 0 setzen. Identifizieren Sie zunaechst, welche Module von Drittanbietern stammen, indem Sie das Verzeichnis /modules/ auf Nicht-PrestaShop-Module pruefen. Deaktivieren Sie diese dann gezielt.

Ein aggressiverer Ansatz ist die Umbenennung des Modulverzeichnisses. Benennen Sie beispielsweise /modules/somemodule/ in /modules/somemodule_disabled/ um. PrestaShop kann ein Modul nicht laden, dessen Verzeichnis nicht mit seinem registrierten Namen uebereinstimmt, wodurch es effektiv deaktiviert wird, ohne die Datenbank zu beruehren.

Haeufige Ursache 2: PHP-Versionsinkompatibilitaet

Jede PrestaShop-Version erfordert einen bestimmten PHP-Versionsbereich. PrestaShop 1.7.6 und frueher erfordern PHP 7.1 bis 7.3. PrestaShop 1.7.7 bis 1.7.8 unterstuetzen PHP 7.2 bis 8.0. PrestaShop 8.0 erfordert PHP 7.2 bis 8.1. PrestaShop 8.1 erfordert PHP 8.0 bis 8.2. PrestaShop 9.0 erfordert PHP 8.1 oder hoeher.

Wenn Ihre Hosting-Umgebung waehrend oder neben dem PrestaShop-Update die PHP-Version geaendert hat, koennten Sie auf Syntaxfehler oder veraltete Funktionsaufrufe stossen. Haeufige PHP-Kompatibilitaetsfehler umfassen: Deprecated: Function create_function() is deprecated (PHP 7.2+ mit Code fuer PHP 5.x), Fatal error: Uncaught Error: Call to undefined function mysql_connect() (PHP 7.0+ hat die mysql-Erweiterung entfernt) und Fatal error: Array and string offset access syntax with curly braces is no longer supported (PHP 8.0+).

Ueberpruefen Sie Ihre aktuelle PHP-Version durch die phpinfo()-Ausgabe oder durch Ausfuehren von php -v auf der Kommandozeile. Wenn die Version ausserhalb des unterstuetzten Bereichs fuer Ihre PrestaShop-Version liegt, wechseln Sie ueber Ihr Hosting-Kontrollpanel zu einer kompatiblen PHP-Version.

Haeufige Ursache 3: Override-Konflikte

Das Override-System von PrestaShop erlaubt es Modulen und Entwicklern, das Core-Verhalten zu aendern, indem modifizierte Klassendateien im Verzeichnis /override/ platziert werden. Waehrend eines Updates aendern sich die Core-Klassen, aber die Override-Dateien bleiben bestehen. Wenn ein Override auf eine Methodensignatur verweist, die sich geaendert hat, auf eine Eigenschaft, die entfernt wurde, oder auf eine Klasse, die umbenannt wurde, verursacht das Override einen fatalen Fehler.

Die Klassen-Index-Datei unter /var/cache/prod/class_index.php (oder /cache/class_index.php in aelteren Versionen) ordnet Klassennamen ihren Dateispeicherorten zu, einschliesslich Overrides. Ein veralteter oder beschaedigter Klassen-Index kann die falsche Datei fuer eine Klasse laden und so sofortige Abstuerze verursachen.

Um zu testen, ob Overrides das Problem sind, deaktivieren Sie voruebergehend das Override-System. Bearbeiten Sie /config/defines.inc.php und fuegen Sie hinzu oder aendern Sie:

define('_PS_HOST_MODE_', false);

Loeschen Sie dann die Klassen-Index-Datei, um PrestaShop zu zwingen, sie ohne Overrides neu zu generieren. Wenn der Shop nach dieser Aenderung laedt, liegt das Problem in einer Ihrer Override-Dateien.

Um das spezifische problematische Override zu identifizieren, schauen Sie in die Verzeichnisse /override/classes/ und /override/controllers/. Entfernen Sie Override-Dateien einzeln und loeschen Sie nach jeder Entfernung den Klassen-Index, bis Sie die Datei finden, die den Absturz verursacht. Nach der Identifizierung aktualisieren Sie entweder das Override, um es mit der neuen Core-Version kompatibel zu machen, oder entfernen Sie es vollstaendig, wenn es nicht mehr benoetigt wird.

Haeufige Ursache 4: Cache und kompilierte Dateien

PrestaShop generiert kompilierte Smarty-Templates, Symfony-Container-Caches, Klassen-Maps und verschiedene andere gecachte Dateien, die nach einem Update ungueltig werden. Wenn der Update-Prozess diese Caches nicht ordnungsgemaess geleert hat, versucht der Shop, gecachte Dateien zu verwenden, die auf die alte Codestruktur verweisen.

Leeren Sie alle Caches manuell, indem Sie den Inhalt dieser Verzeichnisse loeschen (loeschen Sie den Inhalt, nicht die Verzeichnisse selbst):

/var/cache/prod/ und /var/cache/dev/ fuer den Symfony-Cache. Loeschen Sie alles innerhalb dieser Verzeichnisse. PrestaShop wird sie beim naechsten Seitenaufruf neu generieren.

/cache/smarty/compile/ und /cache/smarty/cache/ fuer Smarty-Template-Caches. Veraltete kompilierte Templates sind eine sehr haeufige Ursache fuer weisse Seiten nach Updates.

/var/cache/prod/class_index.php (oder /cache/class_index.php) fuer die Klassen-Map. Diese Datei muss nach jedem Update neu generiert werden.

Bei PHP-FPM-Setups setzen Sie auch OPcache zurueck. OPcache speichert kompilierten PHP-Bytecode im Arbeitsspeicher und kann den alten Code ausliefern, selbst nachdem Dateien ersetzt wurden. Starten Sie den PHP-FPM-Dienst neu, oder erstellen Sie, falls das nicht moeglich ist, eine kleine PHP-Datei, die opcache_reset() aufruft, und greifen Sie ueber Ihren Browser darauf zu.

Haeufige Ursache 5: Fehlgeschlagene Datenbankmigrationen

PrestaShop-Updates enthalten oft Datenbankschema-Aenderungen: neue Spalten, geaenderte Indizes, neue Tabellen oder Datenmigrationen. Wenn der Update-Prozess unterbrochen wurde (Timeout, Speicherlimit, Verbindungsabbruch), kann sich die Datenbank in einem teilweise migrierten Zustand befinden.

Pruefen Sie in der PrestaShop-Datenbank die Tabelle ps_configuration und suchen Sie den Wert PS_VERSION_DB. Wenn dieser Wert nicht mit der Version der Dateien auf der Festplatte uebereinstimmt, wurde das Update nicht ordnungsgemaess abgeschlossen. PrestaShop kann versuchen, die Migrationen beim naechsten Laden erneut auszufuehren, oder es kann einfach fehlschlagen.

Fehlgeschlagene Datenbankmigrationen sind ohne Backup am schwierigsten zu beheben. Wenn Sie ein Datenbank-Backup von vor dem Update haben, ist die Wiederherstellung und erneute Durchfuehrung des Updates oft der sicherste Weg. Wenn Sie kein Backup haben, muessen Sie moeglicherweise die fehlenden SQL-Migrationsdateien manuell anwenden, die im Verzeichnis /install/upgrade/sql/ zu finden sind.

Schritt-fuer-Schritt-Wiederherstellungsverfahren

Befolgen Sie diese Reihenfolge bei der Wiederherstellung nach einer weissen Seite nach einem Core-Update. Die Reihenfolge ist wichtig, weil jeder Schritt entweder das Problem behebt oder eine moegliche Ursache ausschliesst.

Schritt 1: Aktivieren Sie den Debug-Modus in /config/defines.inc.php, indem Sie _PS_MODE_DEV_ auf true setzen. Laden Sie die Seite neu und lesen Sie die Fehlermeldung.

Schritt 2: Loeschen Sie den Inhalt von /var/cache/prod/, /var/cache/dev/, /cache/smarty/compile/ und /cache/smarty/cache/. Loeschen Sie class_index.php. Laden Sie die Seite neu.

Schritt 3: Wenn der Fehler auf ein bestimmtes Modul verweist, deaktivieren Sie dieses Modul durch Umbenennung seines Verzeichnisses oder durch Setzen von active = 0 in der Datenbanktabelle ps_module. Laden Sie die Seite neu.

Schritt 4: Wenn der Fehler auf eine Override-Datei verweist, verschieben Sie den Inhalt des Verzeichnisses /override/ an einen temporaeren Backup-Speicherort. Loeschen Sie class_index.php erneut. Laden Sie die Seite neu.

Schritt 5: Ueberpruefen Sie, ob Ihre PHP-Version mit der PrestaShop-Version kompatibel ist, auf die Sie aktualisiert haben. Pruefen Sie phpinfo() oder php -v. Wechseln Sie bei Bedarf die PHP-Version.

Schritt 6: Pruefen Sie die Dateiberechtigungen. Der Update-Prozess kann Dateien mit falscher Eigentuemerzuordnung erstellt haben. Alle PrestaShop-Dateien sollten vom Webserver-Benutzer lesbar sein, und die Verzeichnisse /var/, /cache/, /img/, /upload/, /download/, /translations/, /themes/ und /modules/ sollten beschreibbar sein.

Schritt 7: Wenn keiner der obigen Schritte das Problem loest und Sie ein Datenbank-Backup haben, stellen Sie Datenbank und Dateien aus dem Backup wieder her und versuchen Sie das Update erneut, nachdem Sie alle waehrend der Diagnose identifizierten Probleme behoben haben.

Sicheres Update-Verfahren fuer zukuenftige Updates

Praevention ist weitaus besser als Wiederherstellung. Befolgen Sie dieses Verfahren fuer jedes PrestaShop Core-Update, um das Risiko von weissen Seiten und Datenverlust zu minimieren.

Vor dem Update: Erstellen Sie ein vollstaendiges Backup sowohl der Datenbank als auch aller Dateien. Nicht nur die Datenbank, nicht nur die Dateien, sondern beides. Speichern Sie diese Backups moeglichst an einem Ort ausserhalb Ihres Hosting-Kontos. Testen Sie, ob Sie tatsaechlich aus diesen Backups wiederherstellen koennen, bevor Sie fortfahren.

Deaktivieren Sie alle Drittanbieter-Module. Dies ist der einzelne wirksamste Schritt, den Sie unternehmen koennen, um weisse Seiten zu verhindern. Core-Module (die mit PrestaShop ausgeliefert werden) sind so konzipiert, dass sie mit dem Update kompatibel sind, aber fuer Drittanbieter-Module gibt es keine Garantie. Deaktivieren Sie sie vor dem Update und aktivieren Sie sie danach einzeln wieder, wobei Sie den Shop nach jeder Reaktivierung testen.

Deaktivieren Sie das Override-System. Wenn Sie benutzerdefinierte Overrides haben, deaktivieren Sie sie vor dem Update. Bewerten Sie jedes Override nach dem Update neu, um festzustellen, ob es noch kompatibel und noch notwendig ist.

Lesen Sie die Release Notes. Jedes PrestaShop-Release enthaelt Hinweise zu Kompatibilitaetsanforderungen, bekannten Problemen und Breaking Changes. Lesen Sie sie vor dem Update, nicht erst nachdem etwas kaputt ist.

Versetzen Sie den Shop in den Wartungsmodus. Dies verhindert, dass Kunden waehrend des Updates Bestellungen aufgeben und auf Fehler stossen. Navigieren Sie im Back Office zu Shopparameter, Allgemein, Wartung und aktivieren Sie den Wartungsmodus.

Waehrend des Updates: Ueberwachen Sie den Update-Prozess. Schliessen Sie nicht den Browser-Tab und navigieren Sie nicht weg. Wenn das Update laenger als erwartet dauert, pruefen Sie Ihre Server-Fehlerprotokolle auf Timeout- oder Speicherfehler. Wenn der Prozess haengenzubleiben scheint, warten Sie mindestens 10 Minuten, bevor Sie Massnahmen ergreifen, da grosse Shops moeglicherweise umfangreiche Datenbankmigrationen verarbeiten muessen.

Nach dem Update: Leeren Sie alle Caches. Ueberpruefen Sie, ob das Back Office korrekt laedt. Pruefen Sie das Front Office. Aktivieren Sie Module einzeln wieder und pruefen Sie den Shop nach jedem Modul. Aktivieren Sie Overrides einzeln wieder, falls zutreffend. Deaktivieren Sie den Wartungsmodus. Ueberwachen Sie die Fehlerprotokolle fuer die naechsten 24 Stunden.

Rollback-Strategien

Wenn eine Wiederherstellung nicht moeglich oder zu zeitaufwaendig ist, kann ein Rollback auf die vorherige Version die beste Option sein. PrestaShop verfuegt jedoch ueber keinen integrierten Rollback-Mechanismus, sodass Sie diese Moeglichkeit vor Beginn des Updates einplanen muessen.

Vollstaendiger Rollback aus Backup: Stellen Sie sowohl die Datenbank als auch die Dateien aus Ihrem Backup von vor dem Update wieder her. Dies ist der sauberste Ansatz, erfordert aber, dass Sie vor dem Update ein vollstaendiges Backup erstellt haben. Ueberpruefen Sie nach der Wiederherstellung, ob der Shop korrekt funktioniert und keine Bestellungen oder Kundendaten verloren gegangen sind, die waehrend des fehlgeschlagenen Update-Zeitraums erstellt wurden (wenn der Shop im Wartungsmodus war, sollte sich nichts geaendert haben).

Teilweiser Datei-Rollback: Wenn nur die Dateien beschaedigt sind, die Datenbank aber in Ordnung ist, koennen Sie die PrestaShop-Dateien durch die vorherige Version ersetzen und dabei die aktuelle Datenbank beibehalten. Laden Sie die exakte vorherige PrestaShop-Version aus dem offiziellen Release-Archiv herunter, entpacken Sie sie und ueberschreiben Sie die Dateien auf Ihrem Server. Behalten Sie Ihre benutzerdefinierten Module, Themes und Konfigurationsdateien bei. Dieser Ansatz ist riskant, da die Datenbank moeglicherweise teilweise migriert wurde, was eine Inkonsistenz zwischen den Dateien und dem Datenbankschema erzeugt.

Vorwaerts-Fix: Manchmal ist der schnellste Weg nicht der Rollback, sondern die Behebung des spezifischen Fehlers. Wenn der Fehler durch ein einzelnes inkompatibles Modul oder Override verursacht wird, kann das Beheben oder Entfernen dieser einen Komponente Minuten dauern, verglichen mit Stunden fuer einen vollstaendigen Rollback. Dieser Ansatz ist am besten, wenn Sie die Ursache aus der Fehlermeldung klar identifiziert haben.

Die Bedeutung von Datenbank-Backups

Jeder Abschnitt dieses Leitfadens erwaehnt Backups, und das aus gutem Grund. Eine PrestaShop-Datenbank enthaelt jedes Produkt, jede Bestellung, jedes Kundenkonto, jede Konfigurationseinstellung und jeden Inhalt in Ihrem Shop. Sie zu verlieren bedeutet, Ihre Geschaeftsdaten zu verlieren.

Automatische taegliche Backups sind fuer einen produktiven PrestaShop-Shop nicht optional. Konfigurieren Sie das Backup-System Ihres Hosting-Anbieters, verwenden Sie ein Datenbank-Backup-Modul oder richten Sie einen Cronjob ein, der mysqldump in regelmaessigen Abstaenden ausfuehrt. Speichern Sie Backups an mehreren Standorten. Testen Sie Ihr Wiederherstellungsverfahren regelmaessig, um sicherzustellen, dass Backups tatsaechlich verwendbar sind.

Erstellen Sie vor jedem Update ein manuelles Backup zusaetzlich zu Ihren automatischen Backups. Benennen Sie es eindeutig mit dem Datum und der PrestaShop-Version, damit Sie es bei Bedarf sofort identifizieren koennen.

Wann professionelle Hilfe gesucht werden sollte

Wenn Sie alle Schritte in diesem Leitfaden befolgt haben und weiterhin eine weisse Seite sehen, oder wenn die Fehlermeldungen auf tiefgreifende Core-Probleme hinweisen, die Korrekturen auf Code-Ebene erfordern, ist es moeglicherweise an der Zeit, einen PrestaShop-Entwickler hinzuzuziehen. Stellen Sie ihm die gesammelten Fehlermeldungen, die beteiligten PrestaShop-Versionen (vor und nach dem Update), Ihre PHP-Version und alle bereits unternommenen Massnahmen zur Verfuegung. Diese Informationen werden die fuer Diagnose und Loesung benoetigte Zeit erheblich verkuerzen.

Der Versuch, Core-PrestaShop-Dateien manuell zu bearbeiten, ohne die Framework-Architektur zu verstehen, kann zusaetzliche Probleme schaffen. Wenn die Fehlermeldung auf Symfony-Container, Dependency Injection oder Kernel-Konfiguration verweist, sind dies Bereiche, in denen falsche Aenderungen zu mehrfachen Folgefehlern fuehren koennen.

Vollständige Antwort lesen

Wie Warenkorb-Aktualisierungen in PrestaShop funktionieren

Bevor wir mit der Fehlerbehebung beginnen, ist es hilfreich zu verstehen, wie PrestaShop Warenkorb-Operationen handhabt. Wenn ein Kunde auf "In den Warenkorb" klickt, sendet das Front-End-JavaScript eine AJAX-Anfrage an den Server. Der Server verarbeitet die Anfrage, aktualisiert den Warenkorb in der Datenbank und der Session und gibt dann eine JSON-Antwort mit der aktualisierten Warenkorbzusammenfassung zurück. Das JavaScript empfängt diese Antwort und aktualisiert den Warenkorb-Block, die Produktseite und alle anderen warenkorbabhängigen Elemente auf der Seite ohne einen vollständigen Seitenneuladen.

Dieser AJAX-basierte Ansatz, der vollständig in PrestaShop 1.7 eingeführt wurde, ersetzte die ältere Methode des Seitenneuladens aus PrestaShop 1.6. Während er ein deutlich flüssigeres Einkaufserlebnis bietet, führt er auch mehr potenzielle Fehlerquellen ein. Eine Warenkorb-Aktualisierung kann auf der JavaScript-Ebene, der AJAX-Anfrage-Ebene, der Server-Verarbeitungsebene oder der Antwort-Rendering-Ebene fehlschlagen. Jeder Fehlerpunkt erzeugt unterschiedliche Symptome und erfordert unterschiedliche Diagnoseansätze.

In PrestaShop 1.7 und 8.x ist die zentrale JavaScript-Datei für Warenkorb-Operationen core.js, die jQuery verwendet, um AJAX-Anfragen an den Warenkorb-Controller zu senden. Der Warenkorb-Controller verarbeitet die Anfrage und löst Events aus, in die sich Module einhaken können. Die Antwort löst ein seitenweites Event (updateCart) aus, auf das alle warenkorbfähigen Komponenten lauschen, um ihre angezeigten Daten zu aktualisieren.

Symptom: Klick auf "In den Warenkorb" bewirkt nichts

Wenn ein Klick auf die Schaltfläche "In den Warenkorb" absolut keine Reaktion erzeugt – keine Animation, kein Spinner, keine Fehlermeldung – liegt das Problem fast immer an einem JavaScript-Fehler, der die Ausführung des Click-Handlers verhindert. Das Klick-Event des Buttons wird nie erfasst, daher wird keine AJAX-Anfrage an den Server gesendet.

Öffnen Sie die Entwicklertools Ihres Browsers (F12 oder Strg+Umschalt+I in Chrome, Firefox und Edge) und wechseln Sie zum Reiter Konsole. Laden Sie die Produktseite neu und suchen Sie nach roten Fehlermeldungen. Häufige Fehler sind $ is not defined oder jQuery is not defined (jQuery konnte nicht geladen werden), Uncaught TypeError: Cannot read property of undefined (das JavaScript eines Moduls referenziert etwas, das nicht existiert) oder Uncaught SyntaxError (eine JavaScript-Datei hat einen Syntaxfehler, oft von einem Modul, das nicht ordnungsgemäß minifiziert wurde).

Ein einziger JavaScript-Fehler auf der Seite kann die Ausführung aller nachfolgenden JavaScript-Codes stoppen, einschließlich der zentralen Warenkorb-Funktionalität. Wenn ein Modul, das vor PrestaShops Core-JavaScript geladen wird, einen Fehler auslöst, bricht das gesamte Warenkorb-System zusammen, obwohl das Modul nichts mit dem Warenkorb zu tun hat.

Um das verursachende Modul zu identifizieren, schauen Sie auf den Dateinamen in der Fehlermeldung. Er verweist typischerweise auf einen Pfad wie /modules/somemodule/views/js/somefile.js. Deaktivieren Sie dieses Modul vorübergehend, um zu bestätigen, dass es die Ursache ist, und kontaktieren Sie dann den Modulentwickler für eine Lösung.

Symptom: Warenkorb-Button dreht sich, aber wird nie fertig

Wenn ein Klick auf "In den Warenkorb" die Ladeanimation auslöst, diese aber endlos dreht, wurde die AJAX-Anfrage gesendet, hat aber entweder keine Antwort oder eine Fehlerantwort erhalten. Wechseln Sie zum Reiter Netzwerk in den Entwicklertools, klicken Sie auf "In den Warenkorb" und suchen Sie nach der AJAX-Anfrage. Es handelt sich typischerweise um eine POST-Anfrage an eine URL, die controller=cart oder cart im Pfad enthält.

Klicken Sie auf die Anfrage, um sie zu untersuchen. Prüfen Sie die Statusspalte: Ein Status 200 mit einem leeren oder fehlerhaften Antwortkörper deutet auf einen PHP-Fehler auf dem Server hin, der vor der Ausgabe abgefangen wurde. Ein Status 500 deutet auf einen nicht behandelten Serverfehler hin. Ein Status 403 kann darauf hindeuten, dass ein Sicherheitsmodul oder eine WAF die Anfrage blockiert. Ein Status 408 oder Timeout bedeutet, dass der Server zu lange für die Antwort gebraucht hat.

Wenn der Status 200 ist, aber der Antwortkörper HTML statt JSON enthält (achten Sie auf HTML-Tags in der Antwort), bedeutet dies, dass PHP eine Warnung oder einen Hinweis ausgegeben hat, der vor der JSON-Antwort ausgegeben wurde und das JSON-Parsing bricht. Dies ist extrem häufig und wird durch Module oder Overrides verursacht, die Text ausgeben (selbst eine Leerzeile vor dem öffnenden PHP-Tag) während der Warenkorb-Verarbeitungs-Hooks.

Symptom: Warenkorb aktualisiert sich, zeigt aber falsche Daten

Manchmal scheint der Warenkorb zu funktionieren: Die Animation wird abgespielt, das Warenkorb-Symbol aktualisiert sich, aber die angezeigten Mengen, Preise oder Produkte sind falsch. Dies ist typischerweise ein Caching-Problem, bei dem der Kunde veraltete Daten statt der frisch berechneten Warenkorbdaten sieht.

PrestaShop verfügt über mehrere Caching-Ebenen, von denen jede veraltete Warenkorbinformationen liefern kann. Das Verständnis und die systematische Überprüfung jeder Ebene ist entscheidend für die Diagnose dieser Art von Problem.

Browser-Cache-Probleme

Der Browser selbst kann AJAX-Antworten oder statische JavaScript-Dateien zwischenspeichern. Während AJAX-POST-Anfragen normalerweise nicht vom Browser zwischengespeichert werden sollten, können einige aggressive Caching-Konfigurationen oder Service Worker interferieren.

Testen Sie, indem Sie ein Inkognito- oder privates Browserfenster öffnen. Wenn der Warenkorb im Inkognito-Modus korrekt funktioniert, handelt es sich um ein Browser-Cache-Problem. Weisen Sie den Kunden an, seinen Browser-Cache zu leeren, oder genauer gesagt, eine harte Aktualisierung mit Strg+Umschalt+R (Windows/Linux) oder Cmd+Umschalt+R (Mac) durchzuführen.

Wenn Ihr PrestaShop-Theme einen Service Worker für Progressive-Web-App-Funktionalität (PWA) verwendet, fängt der Service Worker möglicherweise AJAX-Anfragen ab und speichert sie zwischen. Überprüfen Sie den Reiter Anwendung in den Entwicklertools, dann Service Workers, um zu sehen, ob einer registriert ist. Heben Sie die Registrierung vorübergehend auf, um zu testen, ob er das Problem verursacht.

Statische JavaScript-Dateien können ebenfalls zwischengespeichert werden. Wenn Sie kürzlich ein Modul aktualisiert haben, das das Warenkorb-Verhalten ändert, verwendet der Browser des Kunden möglicherweise noch die alte JavaScript-Datei. PrestaShop hängt einen Versions-Query-String an JavaScript-URLs an (wie cart.js?v=1.0.0), aber dies funktioniert nur, wenn das Modul seine Versionsnummer bei der Aktualisierung ordnungsgemäß erhöht.

Smarty-Cache-Konflikte

PrestaShop verwendet die Smarty-Template-Engine zum Rendern von HTML auf der Serverseite. Smarty verfügt über ein eigenes Kompilierungs- und Caching-System, das veraltete Template-Ausgaben liefern kann.

Wenn warenkorbbezogene Templates geändert wurden (durch ein Theme-Update, eine Modulinstallation oder eine manuelle Bearbeitung), aber der Smarty-Cache nicht geleert wurde, wird weiterhin das alte Template ausgeliefert. Die kompilierten Templates werden in /var/cache/prod/smarty/compile/ und die gecachte Ausgabe in /var/cache/prod/smarty/cache/ gespeichert. Das Löschen des Inhalts beider Verzeichnisse zwingt Smarty, alle Templates aus den aktuellen Quelldateien neu zu kompilieren.

Sie können den Smarty-Cache auch über das Back Office leeren. Navigieren Sie zu Erweiterte Einstellungen, dann Leistung, und klicken Sie auf die Schaltfläche "Cache leeren". In PrestaShop 8.x können Sie auch die Schaltfläche "Symfony-Cache leeren" verwenden, die sowohl den Symfony-Container-Cache als auch den Smarty-Cache leert.

Ein subtileres Smarty-Problem betrifft die Einstellungen "Kompilierung erzwingen" und "Cache" unter Erweiterte Einstellungen, Leistung, Smarty. Während der Entwicklung oder beim Debugging setzen Sie die Template-Kompilierung auf "Kompilierung erzwingen" und den Cache auf "Nein". Dies stellt sicher, dass jeder Seitenaufruf die neuesten Template-Dateien verwendet. Denken Sie daran, diese nach dem Debugging auf "Templates neu kompilieren, wenn die Dateien aktualisiert wurden" und "Ja" zurückzusetzen, da die erzwungene Kompilierung die Leistung erheblich beeinträchtigt.

CCC-Einstellungen und ihre Auswirkungen

PrestaShops CCC-Funktion (Combine, Compress, Cache), zu finden unter Erweiterte Einstellungen, Leistung, fasst CSS- und JavaScript-Dateien zusammen und minifiziert sie, um die Seitenladezeiten zu verbessern. Obwohl dies für die Leistung vorteilhaft ist, kann CCC auf verschiedene Weise Warenkorb-Probleme verursachen.

Wenn CCC aktiviert ist, kombiniert PrestaShop mehrere JavaScript-Dateien zu einer einzigen gecachten Datei. Wenn das JavaScript eines Moduls von der Ladereihenfolge abhängt (es muss nach jQuery, aber vor dem Code eines anderen Moduls ausgeführt werden), kann der Kombinierungsprozess die Dateien falsch anordnen, wodurch der abhängige Code fehlschlägt.

CCC speichert die kombinierten Dateien außerdem aggressiv. Nach der Installation, Aktualisierung oder Entfernung eines Moduls wird möglicherweise noch die alte kombinierte Datei ausgeliefert. Die Lösung besteht darin, den CCC-Cache manuell zu leeren, indem Sie zu Erweiterte Einstellungen, Leistung gehen und auf "Cache leeren" klicken oder die gecachten Dateien in /themes/your_theme/cache/ löschen.

Ein besonders frustrierendes CCC-Problem tritt auf, wenn die JavaScript-Datei eines Moduls einen Syntaxfehler enthält. Wenn CCC sie mit anderen Dateien kombiniert, bricht der Syntaxfehler das gesamte kombinierte JavaScript-Paket und deaktiviert alle JavaScript-Funktionen auf der Seite, einschließlich des Warenkorbs. Ohne CCC würde nur das JavaScript des einen Moduls fehlschlagen, während der Rest weiter funktioniert. Das vorübergehende Deaktivieren von CCC kann helfen, diese Art von Problem zu isolieren.

Um zu testen, ob CCC Ihr Warenkorb-Problem verursacht, deaktivieren Sie alle drei CCC-Optionen (Smart Cache für CSS, Smart Cache für JavaScript und Apache-Optimierung) unter den Leistungseinstellungen. Leeren Sie alle Caches. Wenn der Warenkorb funktioniert, aktivieren Sie die Optionen nacheinander wieder, um zu identifizieren, welche den Konflikt verursacht.

CDN-Cache-Probleme

Wenn Ihr PrestaShop-Shop ein CDN (Content Delivery Network) wie Cloudflare, KeyCDN oder CloudFront verwendet, kann das CDN möglicherweise Antworten zwischenspeichern, die nicht zwischengespeichert werden sollten. CDNs sind dafür konzipiert, statische Inhalte zu cachen, aber Fehlkonfigurationen können dazu führen, dass sie dynamische AJAX-Antworten oder sessionabhängige Seiten cachen.

Insbesondere Cloudflare ist dafür bekannt, POST-Anfrage-Antworten zu cachen, wenn bestimmte Seitenregeln oder Cache-Everything-Regeln zu breit konfiguriert sind. Der Warenkorb-AJAX-Endpunkt gibt kundenspezifische Daten zurück, die niemals von einem CDN gecacht werden dürfen.

Um zu testen, ob das CDN beteiligt ist, umgehen Sie es vorübergehend. In Cloudflare können Sie das CDN pausieren oder eine Seitenregel hinzufügen, die den Cache für Ihre gesamte Domain vorübergehend umgeht. Wenn der Warenkorb ohne das CDN korrekt funktioniert, überprüfen Sie Ihre Caching-Regeln, um sicherzustellen, dass AJAX-Endpunkte und dynamische Seiten vom Caching ausgeschlossen sind.

Stellen Sie speziell für Cloudflare sicher, dass die Seitenregel "Cache Everything" nicht Ihre gesamte Domain abdeckt. Wenn Sie sie verwenden müssen, fügen Sie eine Regel mit höherer Priorität hinzu, die den Cache für URLs umgeht, die controller=cart, ajax=true und den Checkout-Pfad enthalten. Überprüfen Sie auch, ob die "Browser-Cache-TTL" nicht zu hoch für dynamische Assets eingestellt ist.

Cookie- und Session-Probleme

PrestaShop verwendet Cookies zur Aufrechterhaltung der Einkaufssession, einschließlich des Warenkorbs. Wenn Cookies nicht korrekt funktionieren, kann der Warenkorb zwischen Anfragen nicht bestehen bleiben. Jede AJAX-Warenkorbaktualisierung erstellt eine neue Session, anstatt die bestehende zu aktualisieren, was dazu führt, dass der Warenkorb nach jedem Seitenaufruf leer erscheint.

Häufige Cookie-Probleme sind: Die Cookie-Domain ist falsch konfiguriert (das Cookie ist für www.example.com gesetzt, aber die AJAX-Anfrage geht an example.com ohne das www-Präfix oder umgekehrt), der Cookie-Pfad ist falsch, das SameSite-Attribut ist auf Strict gesetzt, was Cookies in bestimmten Cross-Origin-Szenarien blockiert, oder das Cookie ist zu groß und wird vom Browser abgelehnt (Browser begrenzen die Cookie-Größe typischerweise auf 4KB).

Überprüfen Sie Cookies im Reiter Anwendung der Entwicklertools. Suchen Sie nach dem PrestaShop-Session-Cookie (in neueren Versionen PrestaShop-[hash] genannt). Überprüfen Sie, ob es die korrekte Domain und den korrekten Pfad hat und ob es bei AJAX-Anfragen mitgesendet wird (prüfen Sie den Cookie-Header im Reiter Netzwerk für die Warenkorb-AJAX-Anfrage).

Bei Multi-Domain- oder Multi-Shop-Setups sind Cookie-Probleme besonders häufig. Wenn der Shop sowohl über http als auch https oder sowohl über die www- als auch die Nicht-www-Version erreichbar ist, wird das Cookie möglicherweise nicht zwischen diesen Variationen geteilt. Stellen Sie sicher, dass Ihr Shop eine einzige kanonische URL verwendet und alle anderen Variationen darauf umleiten.

SSL-Zertifikatsprobleme können ebenfalls die Funktion von Cookies beeinträchtigen. Wenn das Secure-Flag auf dem Cookie gesetzt ist, die Seite aber über HTTP geladen wird (oder gemischte Inhalte vorliegen), sendet der Browser das Cookie nicht. Stellen Sie sicher, dass Ihr gesamter Shop konsistent über HTTPS ausgeliefert wird.

Modulkonflikte: Diagnoseprozess

Modulkonflikte sind die häufigste Ursache für Warenkorb-Probleme in PrestaShop. Zwei oder mehr Module können sich in dieselben Warenkorb-Events einhaken und sich gegenseitig stören, oder ein einzelnes Modul kann einen Fehler haben, der die Warenkorbreaktion beschädigt.

Der systematische Ansatz zur Diagnose von Modulkonflikten beinhaltet das gruppenweise Deaktivieren von Modulen. Beginnen Sie damit, alle Drittanbieter-Module zu deaktivieren (behalten Sie PrestaShops native Module aktiv). Wenn der Warenkorb funktioniert, aktivieren Sie Module in Gruppen von 5. Wenn das Problem wieder auftritt, haben Sie es auf 5 Module eingegrenzt. Deaktivieren Sie diese 5 und aktivieren Sie sie einzeln wieder, um den genauen Verursacher zu finden.

Achten Sie besonders auf Module, die sich in diese PrestaShop-Hooks einhaken, da sie das Warenkorb-Verhalten direkt beeinflussen: actionCartSave, actionCartUpdate, displayShoppingCart, displayShoppingCartFooter, actionBeforeCartUpdateQty, actionAfterCartUpdateQty, displayHeader (Module, die hier JavaScript hinzufügen, können mit dem Warenkorb-JS in Konflikt geraten) und actionFrontControllerSetMedia.

Um zu sehen, welche Module in warenkorbspezifischen Hooks registriert sind, prüfen Sie die Datenbank:

SELECT h.name, m.name FROM ps_hook_module hm JOIN ps_hook h ON h.id_hook = hm.id_hook JOIN ps_module m ON m.id_module = hm.id_module WHERE h.name LIKE '%cart%' ORDER BY h.name, hm.position;

Diese Abfrage listet alle Module auf, die in warenkorbspezifischen Hooks registriert sind, zusammen mit ihrer Ausführungsreihenfolge. Konflikte entstehen oft, wenn zwei Module beide versuchen, den Warenkorb-Gesamtbetrag zu ändern oder Rabatte auf inkompatible Weise anzuwenden.

Debugging mit Browser-Entwicklertools: Eine detaillierte Anleitung

Browser-Entwicklertools sind Ihre mächtigste Waffe zur Diagnose von Warenkorb-Problemen. Hier ist eine Schritt-für-Schritt-Anleitung, wie Sie sie effektiv nutzen.

Schritt 1: Öffnen Sie die Entwicklertools und gehen Sie zum Reiter Konsole. Löschen Sie alle vorhandenen Meldungen. Laden Sie die Produktseite neu. Notieren Sie alle Fehler oder Warnungen, die erscheinen. Dies sind bereits bestehende Probleme, die mit dem Warenkorb-Problem zusammenhängen können oder nicht, aber dokumentiert werden sollten.

Schritt 2: Wechseln Sie zum Reiter Netzwerk. Aktivieren Sie das Kontrollkästchen "Protokoll beibehalten", damit Anfragen nicht bei der Seitennavigation gelöscht werden. Filtern Sie nach "XHR" oder "Fetch", um nur AJAX-Anfragen zu sehen. Klicken Sie auf die Schaltfläche "In den Warenkorb".

Schritt 3: Untersuchen Sie die AJAX-Anfrage. Klicken Sie auf die Warenkorb-Anfrage, die erscheint. Im Unter-Reiter Header überprüfen Sie, ob die Anfrage-URL korrekt ist und der Statuscode 200 beträgt. Im Unter-Reiter Anfrage-Payload oder Formulardaten überprüfen Sie, ob die korrekte Produkt-ID, Menge und Attributkombination gesendet werden.

Schritt 4: Überprüfen Sie die Antwort. Wechseln Sie zum Unter-Reiter Antwort oder Vorschau. Die Antwort sollte gültiges JSON sein. Wenn Sie HTML eingemischt sehen, wird ein PHP-Fehler oder eine Warnung ausgegeben. Wenn die Antwort leer ist, ist die serverseitige Verarbeitung abgestürzt, bevor eine Ausgabe generiert wurde. Wenn das JSON gültig ist, aber Fehlermeldungen enthält, lesen Sie diese für Hinweise.

Schritt 5: Überprüfen Sie die Konsole nach der AJAX-Antwort. JavaScript-Fehler, die während der Verarbeitung der AJAX-Antwort auftreten, erscheinen in der Konsole, nachdem die Netzwerkanfrage abgeschlossen ist. Diese Fehler zeigen an, dass die Antwort empfangen wurde, aber nicht ordnungsgemäß vom Front-End-JavaScript verarbeitet werden konnte.

PrestaShop 8.x – Spezifische Besonderheiten

PrestaShop 8.x verwendet im Vergleich zu 1.7 eine deutlich aktualisierte Front-End-Architektur. Das Warenkorb-JavaScript wurde refaktoriert, und einiger zuvor jQuery-abhängiger Code verwendet jetzt Vanilla-JavaScript oder aktualisierte jQuery-Methoden. Module, die für PrestaShop 1.7 geschrieben wurden und den Warenkorb-DOM direkt manipulieren, können in 8.x fehlschlagen, weil sich die HTML-Struktur und CSS-Klassennamen geändert haben.

Die Symfony-Integration in PrestaShop 8.x bedeutet auch, dass das Cache-Leeren aufwendiger ist. Der Symfony-Container-Cache, der sich in /var/cache/prod/ und /var/cache/dev/ befindet, kann kompilierte Dienstdefinitionen und Routen-Zuordnungen enthalten, die beeinflussen, wie Warenkorb-Controller Anfragen verarbeiten. Nur den Smarty-Cache zu leeren reicht nicht aus; Sie müssen auch den Symfony-Cache leeren.

PrestaShop 8.x hat in einigen Konfigurationen auch strengere Content-Security-Policy-Header (CSP) eingeführt. Wenn Ihr Server oder ein Sicherheitsmodul CSP-Header hinzufügt, die Inline-JavaScript oder AJAX-Anfragen auf bestimmte Domains beschränken, können die Warenkorb-AJAX-Aufrufe blockiert werden. Prüfen Sie die Konsole auf CSP-Verletzungsmeldungen, die als rote Fehler mit dem Hinweis "Content Security Policy" erscheinen.

Serverseitige Probleme: PHP-Sessions und Konfiguration

Die PHP-Session-Konfiguration kann Warenkorb-Probleme verursachen, die schwer zu diagnostizieren sind, da sie intermittierend auftreten. Wenn das Session-Speicherverzeichnis voll ist, falsche Berechtigungen hat oder sich auf einem Dateisystem befindet, das kein File-Locking unterstützt, können Sessions zwischen Anfragen verloren gehen oder beschädigt werden.

Überprüfen Sie Ihre PHP-Session-Konfiguration: session.save_path muss auf ein beschreibbares Verzeichnis mit ausreichend Speicherplatz zeigen. session.gc_maxlifetime steuert, wie lange Sessions aufbewahrt werden; wenn dieser Wert zu niedrig eingestellt ist, verlieren Kunden ihren Warenkorb während langer Browsing-Sitzungen. session.cookie_lifetime sollte dem gc_maxlifetime-Wert entsprechen oder ihn überschreiten.

Auf Shared Hosting mit vielen Websites kann das Session-Verzeichnis Millionen von Dateien aller gehosteten Websites enthalten, was den Zugriff auf Session-Dateien verlangsamt. Falls Ihr Hosting-Anbieter es unterstützt, konfigurieren Sie ein standortspezifisches Session-Verzeichnis oder verwenden Sie datenbankbasierte Sessions.

Für Shops, die mehrere Webserver hinter einem Load Balancer verwenden, müssen Sessions zwischen den Servern geteilt werden. Wenn der Session-Speicher dateibasiert und lokal auf jedem Server ist, kann eine nachfolgende Anfrage eines Kunden einen anderen Server treffen, der dessen Session nicht hat, was zu einem leeren Warenkorb führt. Verwenden Sie in Load-Balanced-Umgebungen einen gemeinsamen Session-Speicher wie Redis, Memcached oder Datenbank-Sessions.

Schritt-für-Schritt-Diagnose-Checkliste

Wenn ein Kunde meldet, dass sich der Warenkorb nicht aktualisiert, arbeiten Sie diese Checkliste der Reihe nach durch:

1. Reproduzieren Sie das Problem. Versuchen Sie, das Problem in einem Inkognito-Fenster mit demselben Produkt und Browser zu replizieren, die der Kunde gemeldet hat. Wenn Sie es nicht reproduzieren können, fragen Sie den Kunden nach seiner Browser-Version, seinem Gerätetyp und den genauen Schritten.

2. Prüfen Sie die Browser-Konsole auf JavaScript-Fehler. Jede rote Fehlermeldung ist potenziell die Ursache, selbst wenn sie nicht mit dem Warenkorb zusammenzuhängen scheint.

3. Überprüfen Sie die Netzwerkanfrage. Verifizieren Sie, dass die AJAX-Anfrage gesendet wird, einen Status 200 zurückgibt und gültiges JSON enthält.

4. Leeren Sie alle Caches: Smarty-Kompilierungscache, Smarty-Cache, Symfony-Cache, CCC-Cache, OPcache und CDN-Cache, falls zutreffend.

5. Deaktivieren Sie CCC. Wenn der Warenkorb mit deaktiviertem CCC funktioniert, ist ein JavaScript-Kombinierungsfehler die Ursache.

6. Testen Sie mit dem Standard-Theme. Wechseln Sie vorübergehend zu PrestaShops Standard-Theme "Classic". Wenn der Warenkorb mit dem Standard-Theme funktioniert, liegt das Problem im JavaScript oder den Templates Ihres benutzerdefinierten Themes.

7. Deaktivieren Sie Drittanbieter-Module. Wenn der Warenkorb mit allen deaktivierten Drittanbieter-Modulen funktioniert, verwenden Sie die binäre Suchmethode, um das konfliktverursachende Modul zu identifizieren.

8. Prüfen Sie die PHP-Fehlerprotokolle. Serverseitige Fehler, die den Browser nicht erreichen, werden hier protokolliert.

9. Überprüfen Sie die Cookie- und Session-Konfiguration. Prüfen Sie das Session-Cookie in den Entwicklertools und verifizieren Sie die PHP-Session-Einstellungen auf dem Server.

10. Testen Sie auf einem anderen Gerät und Netzwerk. Dies schließt lokale Browser-Probleme, Netzwerk-Proxys und gerätespezifische JavaScript-Kompatibilitätsprobleme als potenzielle Ursachen aus.

Vollständige Antwort lesen

Warum PrestaShop-Fehlerprotokolle wichtig sind

Jeder PrestaShop-Shop erzeugt Fehler. Einige sind harmlose Hinweise, die Ihre Kunden nie betreffen. Andere sind kritische Ausfälle, die Ihren gesamten Checkout zum Stillstand bringen. Der Unterschied zwischen einem Shop-Betreiber, der tagelang auf Support wartet, und einem, der Probleme in Minuten behebt, liegt oft an einer einzigen Fähigkeit: dem Lesen von Fehlerprotokollen.

Fehlerprotokolle sind die diagnostische Ausgabe Ihres Servers und Ihrer PrestaShop-Anwendung. Sie zeichnen jeden PHP-Fehler, jede fehlgeschlagene Datenbankabfrage, jedes Berechtigungsproblem und jede nicht abgefangene Ausnahme auf. Wenn etwas schiefgeht, liegt die Antwort fast immer in einer Protokolldatei. Die Herausforderung besteht darin zu wissen, wo man suchen muss, wonach man suchen muss und wie man das Gefundene interpretiert.

Dieser Leitfaden deckt die gesamte Landschaft der PrestaShop-Fehlerprotokollierung ab. Sie werden lernen, wo jede Art von Protokoll liegt, wie man die detaillierte Fehlerberichterstattung aktiviert, wie man Stack Traces liest und wie man Kommandozeilenwerkzeuge nutzt, um die Nadel im Heuhaufen zu finden. Ob Sie einen weißen Bildschirm des Todes debuggen oder einen sporadischen Checkout-Fehler aufspüren – dies ist das Wissen, das Sie brauchen.

Wo PrestaShop-Protokolle gespeichert werden

PrestaShop generiert Protokolle auf mehreren Ebenen, und jede Ebene hat ihre eigenen Protokolldateien. Zu verstehen, welches Protokoll zuerst geprüft werden sollte, spart enorm viel Zeit.

PrestaShop-Anwendungsprotokolle (var/logs)

Ab PrestaShop 1.7 verwendet die Anwendung das Symfony-Framework für das Back Office und das zentrale Routing. Symfony schreibt seine eigenen Protokolle in das Verzeichnis var/logs/ in Ihrem PrestaShop-Stammverzeichnis. Sie finden dort Dateien, die nach der aktuellen Umgebung benannt sind:

var/logs/dev.log enthält Protokolle, wenn PrestaShop im Entwicklungsmodus läuft. Diese Datei ist äußerst ausführlich und zeichnet alles von Routing-Entscheidungen bis hin zu Datenbankabfragen auf. Sie kann schnell auf Hunderte von Megabyte anwachsen.

var/logs/prod.log enthält Protokolle aus dem Produktionsmodus. Diese Datei ist standardmäßig deutlich weniger ausführlich und zeichnet nur Warnungen und Fehler auf. Dies ist die Datei, die Sie zuerst überprüfen sollten, wenn bei einem Live-Shop etwas nicht funktioniert.

Diese Protokolldateien folgen dem Monolog-Format, der Standard-Protokollierungsbibliothek in Symfony. Jede Zeile enthält einen Zeitstempel, den Protokoll-Kanal (wie request, security oder doctrine), den Schweregrad und die Meldung. Ein typischer Eintrag sieht so aus:

[2024-03-15 14:22:33] request.CRITICAL: Uncaught PHP Exception Symfony\Component\HttpKernel\Exception\NotFoundHttpException: "No route found for GET /admin/nonexistent" at /var/www/html/vendor/symfony/http-kernel/EventListener/RouterListener.php line 136

Die Schweregrade, vom geringsten zum höchsten, sind: DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT und EMERGENCY. Bei der Fehlerbehebung filtern Sie zuerst nach ERROR und CRITICAL.

PHP-Fehlerprotokoll

PHP selbst führt ein Fehlerprotokoll, das von den Anwendungsprotokollen von PrestaShop getrennt ist. Dieses Protokoll erfasst Fehler, die auftreten, bevor PrestaShops Protokollierungs-Framework initialisiert wird, oder Fehler in Code, der den Symfony-Logger nicht verwendet. Der Speicherort dieser Datei hängt von Ihrer Serverkonfiguration ab.

Auf den meisten Linux-Servern mit Apache befindet sich das PHP-Fehlerprotokoll unter /var/log/php_errors.log oder /var/log/php/error.log. Auf Shared Hosting mit cPanel befindet es sich oft unter /home/username/logs/error.log oder im public_html-Verzeichnis als error_log.

Den genauen Speicherort können Sie über Ihre PHP-Konfiguration ermitteln. Erstellen Sie eine temporäre PHP-Datei mit phpinfo(); und suchen Sie nach der Direktive error_log. Alternativ führen Sie php -i | grep error_log über die Kommandozeile aus.

PHP-Fehlerprotokolle erfassen fatale Fehler, Parse-Fehler, Warnungen und Hinweise. Ein typischer Eintrag eines fatalen Fehlers sieht so aus:

[15-Mar-2024 14:22:33 UTC] PHP Fatal error: Uncaught Error: Class 'SomeModule\SomeClass' not found in /var/www/html/modules/somemodule/somemodule.php:45

Webserver-Protokolle (Apache und Nginx)

Ihr Webserver führt eigene Protokolle, die unabhängig von PHP und PrestaShop sind. Diese Protokolle sind unverzichtbar für die Diagnose von 500-Fehlern, 404-Fehlern und Leistungsproblemen.

Apache-Protokolle befinden sich typischerweise unter:

/var/log/apache2/error.log für das Fehlerprotokoll auf Debian- und Ubuntu-Systemen.
/var/log/httpd/error_log für das Fehlerprotokoll auf CentOS- und RHEL-Systemen.
/var/log/apache2/access.log für das Zugriffsprotokoll, das jede HTTP-Anfrage aufzeichnet.

Nginx-Protokolle befinden sich typischerweise unter:

/var/log/nginx/error.log für das Fehlerprotokoll.
/var/log/nginx/access.log für das Zugriffsprotokoll.

Wenn Ihre Website eine Virtual-Host-Konfiguration verwendet, befinden sich die Protokolle möglicherweise an einem standortspezifischen Speicherort, der durch die Direktive ErrorLog (Apache) oder error_log (Nginx) in Ihrer Virtual-Host-Datei definiert ist.

Webserver-Fehlerprotokolle erfassen Probleme wie Zugriffsverweigerungsfehler, wenn PHP versucht, in ein Verzeichnis zu schreiben, Konfigurationssyntaxfehler nach einer .htaccess-Änderung und Proxy-Timeout-Fehler, wenn Sie PHP-FPM hinter Nginx betreiben. Dies sind die Protokolle, die Sie überprüfen sollten, wenn ein generischer 500-Internal-Server-Error ohne Details in den PHP- oder PrestaShop-Protokollen erscheint.

PrestaShop-Legacy-Protokolle (Back Office)

PrestaShop unterhält auch einen Protokoll-Viewer im Back Office unter Erweiterte Einstellungen > Protokolle. Diese Oberfläche zeigt Protokolleinträge, die in der Datenbanktabelle ps_log gespeichert sind. Diese Protokolle erfassen Events, die PrestaShop explizit aufzeichnet, wie fehlgeschlagene Anmeldeversuche, Modulinstallationsfehler und Fehler beim E-Mail-Versand.

Obwohl der Back-Office-Protokoll-Viewer praktisch ist, hat er erhebliche Einschränkungen. Er erfasst keine PHP-Fehler, keine Webserver-Fehler und die meisten fatalen Fehler, die das Laden der Seite verhindern, nicht. Betrachten Sie ihn als Ergänzung zu den dateibasierten Protokollen, nicht als Ersatz.

Debug-Modus in PrestaShop aktivieren

Standardmäßig läuft PrestaShop im Produktionsmodus und verbirgt detaillierte Fehlermeldungen vor Besuchern. Dies ist für einen Live-Shop korrekt, macht das Debugging jedoch nahezu unmöglich. Wenn etwas nicht funktioniert, sollte Ihr erster Schritt das Aktivieren des Debug-Modus sein.

Methode 1: Die Datei defines.inc.php

Öffnen Sie die Datei config/defines.inc.php und suchen Sie die Zeile, die _PS_MODE_DEV_ setzt. Ändern Sie den Wert von false auf true:

define('_PS_MODE_DEV_', true);

Diese einzelne Änderung hat mehrere Auswirkungen. Die PHP-Fehlerberichterstattung wird auf die maximale Stufe gesetzt und zeigt alle Fehler, Warnungen und Hinweise an. Das Smarty-Template-Caching wird deaktiviert, sodass Template-Änderungen sofort sichtbar sind. Die Symfony-Profiler-Toolbar erscheint am unteren Rand der Back-Office-Seiten. Und vor allem werden Fehlerdetails auf dem Bildschirm angezeigt, anstatt eine generische Fehlerseite zu zeigen.

Methode 2: Der Debug-Profiling-Modus

Für eine tiefergehende Analyse können Sie auch das Profiling aktivieren. Setzen Sie in derselben Datei:

define('_PS_DEBUG_PROFILING_', true);

Dies fügt am Ende jeder Seite detaillierte Timing- und Speicherverbrauchsinformationen hinzu und zeigt Ihnen, welche Hooks am längsten dauern, welche Module den meisten Speicher verbrauchen und wie viele Datenbankabfragen jede Seite generiert. Dies ist für das Performance-Debugging unschätzbar wertvoll, sollte aber niemals in der Produktion aktiviert bleiben.

Sicherheitswarnung

Der Debug-Modus legt sensible Informationen offen, darunter Dateipfade, Datenbankzugangsdaten in Stack Traces und die interne Anwendungsstruktur. Lassen Sie den Debug-Modus niemals auf einem Produktions-Shop aktiviert, der öffentlich zugänglich ist. Wenn Sie einen Live-Shop debuggen müssen, erwägen Sie, den Debug-Modus auf Ihre IP-Adresse zu beschränken, indem Sie die Define-Anweisung in eine IP-Prüfung einbetten, oder verwenden Sie eine Staging-Umgebung.

Stack Traces lesen

Wenn PrestaShop im Debug-Modus auf einen fatalen Fehler oder eine nicht abgefangene Ausnahme stößt, zeigt es einen Stack Trace an. Ein Stack Trace ist eine Momentaufnahme der Aufrufkette, die zum Fehler geführt hat – er liest sich vom Fehlerpunkt zurück bis zum ursprünglichen Einstiegspunkt. Das Lesen von Stack Traces zu erlernen, ist die wertvollste Debugging-Fähigkeit, die Sie entwickeln können.

Anatomie eines Stack Trace

Ein typischer PrestaShop-Stack-Trace sieht so aus:

PHP Fatal error: Uncaught TypeError: Argument 1 passed to Product::getProductProperties() must be of the type int, null given, called in /var/www/html/classes/Product.php on line 4523

Stack trace: #0 /var/www/html/classes/Product.php(4523): Product::getProductProperties(NULL, Array) #1 /var/www/html/modules/somemodule/somemodule.php(127): Product::getProductProperties(1, Array) #2 /var/www/html/classes/Hook.php(523): SomeModule->hookDisplayHome(Array) #3 /var/www/html/classes/Hook.php(460): Hook::coreCallHook(Object(SomeModule), 'hookDisplayHome', Array) #4 /var/www/html/classes/Hook.php(408): Hook::exec('displayHome', Array)

Lesen Sie den Stack Trace von oben nach unten. Die erste Zeile sagt Ihnen, was schiefgelaufen ist: Eine Funktion erwartete einen Integer, erhielt aber null. Die Zeile #0 sagt Ihnen, wo der Fehler aufgetreten ist. Die Zeile #1 sagt Ihnen, was den Code bei #0 aufgerufen hat. Die Zeile #2 sagt Ihnen, was #1 aufgerufen hat, und so weiter.

In diesem Beispiel ist die Kette klar: PrestaShop hat den Hook displayHome ausgeführt, der die Methode hookDisplayHome in SomeModule aufgerufen hat, die wiederum Product::getProductProperties() mit einem null-Wert aufgerufen hat, wo ein Integer erwartet wurde. Der Fehler liegt im Modul in Zeile 127, wo ein falscher Wert übergeben wird.

Den relevanten Frame finden

Stack Traces in PrestaShop können lang sein – manchmal 20 oder 30 Frames tief. Der Schlüssel liegt darin, den Frame zu finden, der Ihren Code oder das verursachende Modul enthält. Suchen Sie nach Pfaden, die /modules/ oder /themes/ enthalten, da diese die wahrscheinlichsten Fehlerquellen sind. Frames, die auf /classes/, /src/ oder /vendor/ verweisen, sind PrestaShop-Kerncode oder Code von Drittanbieter-Bibliotheken, die weniger wahrscheinlich die Problemquelle sind – es sei denn, Sie haben Core-Dateien modifiziert.

Häufige PrestaShop-Fehlermuster

Nach dem Lesen tausender PrestaShop-Fehlerprotokolle zeichnen sich bestimmte Muster ab, die sich immer wieder wiederholen. Das Erkennen dieser Muster ermöglicht es Ihnen, Probleme in Sekunden statt in Stunden zu diagnostizieren.

Class-Not-Found-Fehler

PHP Fatal error: Uncaught Error: Class 'ModuleName\ClassName' not found

Dies bedeutet, dass der Autoloader die angegebene Klasse nicht finden kann. Häufige Ursachen sind: eine fehlende vendor/autoload.php-Datei (das Modul benötigt composer install), eine nicht übereinstimmende Namespace-Deklaration, eine Datei, die nicht im Modul-ZIP während der Installation enthalten war, oder ein Groß-/Kleinschreibungsproblem auf Linux-Servern, wo ClassName.php und classname.php unterschiedliche Dateien sind.

Zugriffsverweigerungsfehler

Warning: file_put_contents(/var/www/html/var/cache/prod/some_file): failed to open stream: Permission denied

Diese treten auf, wenn der Webserver-Benutzer (normalerweise www-data auf Debian/Ubuntu oder apache auf CentOS) keine Schreibberechtigung für eine Datei oder ein Verzeichnis hat. Beheben Sie dies durch Korrektur der Eigentümerschaft: chown -R www-data:www-data var/cache/ und der Berechtigungen: chmod -R 775 var/cache/.

Speicherlimitfehler

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 65536 bytes)

Die Zahl 134217728 Bytes entspricht 128MB, dem Standard-PHP-Speicherlimit. PrestaShop empfiehlt mindestens 256MB. Erhöhen Sie es in Ihrer php.ini-Datei: memory_limit = 512M. Wenn der Fehler auch bei hohen Speicherlimits weiterhin auftritt, hat der Code wahrscheinlich ein Speicherleck, das oft durch das Laden zu vieler Produkte oder Kategorien in einer einzigen Abfrage ohne Paginierung verursacht wird.

Datenbankverbindungsfehler

Link to database cannot be established: SQLSTATE[HY000] [2002] Connection refused

Dies bedeutet, dass PrestaShop keine Verbindung zum MySQL-Server herstellen kann. Überprüfen Sie, ob der Datenbankserver läuft, ob die Zugangsdaten in app/config/parameters.php korrekt sind und ob der Datenbank-Host vom Webserver aus erreichbar ist.

Smarty-Template-Fehler

SmartyException: Unable to load template file 'module:somemodule/views/templates/hook/display.tpl'

Die Template-Datei fehlt, ist falsch geschrieben oder befindet sich im falschen Verzeichnis. Überprüfen Sie, ob die Datei am erwarteten Pfad existiert und ob der Dateiname exakt übereinstimmt, einschließlich Groß-/Kleinschreibung.

CSRF-Token-Fehler

Invalid token. Please try to log in again.

Dieser Fehler erscheint im Back Office, wenn eine Formularübermittlung ein abgelaufenes oder fehlendes Sicherheitstoken enthält. Er tritt typischerweise auf, wenn eine Session während einer langen Bearbeitungssitzung abläuft, wenn mehrere Tabs auf derselben Admin-Seite geöffnet sind oder wenn ein Modul seine Formular-URLs falsch generiert.

Mit grep Fehler finden

Wenn Protokolldateien groß werden, ist das manuelle Durchscrollen unpraktisch. Der Befehl grep ist Ihr bester Freund, um relevante Einträge schnell zu finden.

Grundlegende Fehlersuche

Um alle fatalen Fehler im PHP-Fehlerprotokoll zu finden:

grep 'Fatal error' /var/log/php_errors.log

Um Fehler eines bestimmten Moduls zu finden:

grep 'somemodule' /var/www/html/var/logs/prod.log

Um nur Fehler von heute zu finden (unter Annahme des Datumsformats im Protokoll):

grep '2024-03-15' /var/www/html/var/logs/prod.log | grep 'ERROR\|CRITICAL'

Erweiterte Filterung

Um Fehler mit umgebendem Kontext zu sehen (3 Zeilen vor und nach jedem Treffer):

grep -C 3 'Fatal error' /var/log/php_errors.log

Um zu zählen, wie oft jeder eindeutige Fehler auftritt:

grep 'Fatal error' /var/log/php_errors.log | sort | uniq -c | sort -rn | head -20

Diese Pipeline sortiert die Fehler, zählt Duplikate, sortiert nach Anzahl in absteigender Reihenfolge und zeigt die Top 20 an. Dies ist unglaublich nützlich, um die häufigsten Fehler zu identifizieren, die zuerst behoben werden müssen.

Um gleichzeitig in mehreren Protokolldateien zu suchen:

grep -r 'Fatal error' /var/log/ --include='*.log'

Das Flag -r sucht rekursiv, und --include beschränkt die Suche auf Dateien mit der Endung .log.

Echtzeit-Protokollüberwachung mit tail -f

Wenn Sie aktiv ein Problem debuggen, müssen Sie Fehler sehen, sobald sie auftreten. Der Befehl tail -f folgt einer Protokolldatei in Echtzeit und zeigt neue Einträge an, sobald sie geschrieben werden.

Grundlegende Echtzeitüberwachung

Um das PrestaShop-Produktionsprotokoll in Echtzeit zu beobachten:

tail -f /var/www/html/var/logs/prod.log

Um das PHP-Fehlerprotokoll zu beobachten:

tail -f /var/log/php_errors.log

Um mehrere Protokolldateien gleichzeitig zu beobachten:

tail -f /var/www/html/var/logs/prod.log /var/log/php_errors.log /var/log/apache2/error.log

Gefilterte Echtzeitüberwachung

Um nur Einträge auf Fehlerebene in Echtzeit zu beobachten, kombinieren Sie tail mit grep:

tail -f /var/www/html/var/logs/prod.log | grep --line-buffered 'ERROR\|CRITICAL'

Das Flag --line-buffered ist hier wichtig. Ohne es puffert grep seine Ausgabe und Sie sehen Treffer möglicherweise nicht sofort.

Um bestimmte Schlüsselwörter hervorzuheben und gleichzeitig alle Ausgaben anzuzeigen:

tail -f /var/www/html/var/logs/prod.log | grep --color=always -E 'ERROR|CRITICAL|$'

Dies hebt ERROR und CRITICAL farblich hervor und zeigt trotzdem alle Zeilen an.

Der Debugging-Workflow

Der effektivste Debugging-Workflow kombiniert Echtzeitüberwachung mit aktivem Testen. Öffnen Sie ein Terminalfenster mit tail -f auf den relevanten Protokolldateien. Reproduzieren Sie in Ihrem Browser die Aktion, die den Fehler verursacht. Beobachten Sie das Terminal auf neue Protokolleinträge, die genau in dem Moment erscheinen, in dem Sie das Problem auslösen. Dieser Ansatz eliminiert Rätselraten und zeigt Ihnen präzise, was beim Auftreten des Fehlers passiert.

Protokollrotation und -verwaltung

Protokolldateien wachsen kontinuierlich und können den gesamten verfügbaren Speicherplatz verbrauchen, wenn sie nicht verwaltet werden. Die meisten Linux-Server verwenden logrotate zur automatischen Verwaltung, aber PrestaShops eigene Protokolle in var/logs/ sind möglicherweise nicht in der Standard-logrotate-Konfiguration enthalten.

Logrotate verstehen

Das Dienstprogramm logrotate wird täglich ausgeführt (normalerweise über cron) und übernimmt die Rotation, Komprimierung und Löschung von Protokolldateien. Konfigurationsdateien befinden sich in /etc/logrotate.d/. Apache- und Nginx-Protokollrotation ist typischerweise standardmäßig konfiguriert.

Für das Verzeichnis var/logs von PrestaShop müssen Sie möglicherweise eine benutzerdefinierte logrotate-Konfiguration erstellen:

/var/www/html/var/logs/*.log { daily missingok rotate 14 compress delaycompress notifempty create 0640 www-data www-data }

Diese rotiert Protokolle täglich, behält 14 Tage Historie, komprimiert alte Protokolle und erstellt neue Protokolldateien mit korrekten Berechtigungen.

Manuelle Protokollbereinigung

Wenn eine Protokolldatei extrem groß geworden ist und Sie sie leeren müssen, ohne den Datei-Handle zu verlieren (wichtig, wenn ein Prozess aktiv in die Datei schreibt):

truncate -s 0 /var/www/html/var/logs/prod.log

Löschen Sie die Datei nicht und erstellen Sie sie neu, denn jeder Prozess, der die Datei geöffnet hat, schreibt weiterhin in den Inode der gelöschten Datei, bis er neu gestartet wird. Der truncate-Ansatz leert den Inhalt und bewahrt gleichzeitig den Inode.

PrestaShop-spezifische Fehlerkontexte verstehen

PrestaShop-Fehler enthalten oft Kontext, der für die Plattform einzigartig ist. Das Verständnis dieses Kontexts hilft Ihnen, Probleme schneller zu finden und zu beheben.

Hook-bezogene Fehler

Wenn ein Fehler innerhalb eines Hooks auftritt, enthält der Stack Trace Verweise auf Hook::exec() und Hook::coreCallHook(). Der Hook-Name sagt Ihnen genau, an welchem Punkt des Seitenrendering-Prozesses der Fehler auftritt. Zum Beispiel treten displayHome-Fehler auf der Startseite auf, actionValidateOrder-Fehler treten während des Checkouts auf, und displayBackOfficeHeader-Fehler treten beim Laden einer beliebigen Back-Office-Seite auf.

Wenn ein Hook-Fehler eine Seite zum Absturz bringt, können Sie das verursachende Modul vorübergehend über die Datenbank deaktivieren:

UPDATE ps_module SET active = 0 WHERE name = 'somemodule';

So erhalten Sie Zugang zum Back Office, um das Problem ordnungsgemäß zu diagnostizieren und zu beheben.

Override-Konflikte

Das Override-System von PrestaShop ermöglicht es Modulen, Kernklassen zu erweitern, aber Konflikte entstehen, wenn zwei Module dieselbe Klasse überschreiben. Der Fehler erscheint typischerweise als Methodensignatur-Konflikt oder unerwartete Verhaltensänderung. Überprüfen Sie das Verzeichnis override/, um zu sehen, welche Overrides aktiv sind, und prüfen Sie die Datei cache/class_index.php, die Klassen ihren Override-Dateien zuordnet. Das Löschen dieser Cache-Datei zwingt PrestaShop, die Override-Zuordnung neu zu generieren.

Cache-bezogene Fehler

Viele PrestaShop-Fehler werden durch veraltete Cache-Dateien verursacht. Wenn Sie Fehler sehen, die nicht zum aktuellen Code passen (zum Beispiel ein Fehler, der auf eine Zeilennummer verweist, die in der Datei nicht existiert), ist der Cache wahrscheinlich veraltet. Leeren Sie ihn, indem Sie den Inhalt von var/cache/prod/ und var/cache/dev/ löschen. Bei PrestaShop 1.6 leeren Sie stattdessen cache/smarty/compile/ und cache/smarty/cache/.

Modulinstallations- und Upgrade-Fehler

Modulinstallationen können stillschweigend fehlschlagen und das Modul in einem teilweise installierten Zustand hinterlassen. Prüfen Sie var/logs/prod.log auf Einträge zum Zeitpunkt der Installation. Häufige Probleme sind fehlende Datenbanktabellen (die SQL der install()-Methode des Moduls ist fehlgeschlagen), fehlende Hooks (der registerHook()-Aufruf ist fehlgeschlagen) und Fehler durch doppelte Einträge in der Tabelle ps_authorization_role bei der Neuinstallation eines Moduls, das nicht vollständig deinstalliert wurde.

Eine Debugging-Checkliste erstellen

Wenn Sie auf einen PrestaShop-Fehler stoßen, folgen Sie dieser systematischen Checkliste, um die Ursache effizient zu finden:

Erstens, identifizieren Sie den Fehlertyp. Handelt es sich um einen weißen Bildschirm (500-Fehler), eine spezifische Fehlermeldung, ein defektes Layout oder unerwartetes Verhalten? Jeder Typ verweist auf unterschiedliche Protokolldateien.

Zweitens, überprüfen Sie zuerst das spezifischste Protokoll. Für PHP-Fehler prüfen Sie das PHP-Fehlerprotokoll. Für HTTP-Fehler prüfen Sie das Webserver-Fehlerprotokoll. Für Anwendungsfehler prüfen Sie var/logs/prod.log.

Drittens, aktivieren Sie den Debug-Modus, wenn die Protokolle nicht genügend Informationen liefern. Ändern Sie _PS_MODE_DEV_ auf true und reproduzieren Sie den Fehler.

Viertens, verwenden Sie tail -f auf den relevanten Protokollen und reproduzieren Sie den Fehler in Ihrem Browser. So erhalten Sie einen Echtzeitblick auf genau das, was passiert.

Fünftens, lesen Sie den Stack Trace von oben nach unten. Finden Sie den Frame, der auf Ihren Modul- oder Theme-Code verweist. Dort muss die Korrektur erfolgen.

Sechstens, suchen Sie nach der Fehlermeldung in PrestaShops GitHub-Issues und Foren. Die Chancen stehen gut, dass jemand dasselbe Problem bereits erlebt und gelöst hat.

Siebtens, nach Anwendung einer Korrektur leeren Sie alle Caches und überwachen Sie die Protokolle, um zu bestätigen, dass der Fehler behoben ist. Eine Korrektur, die kein sauberes Protokoll erzeugt, ist keine vollständige Korrektur.

Zusammenfassung

Das Lesen von PrestaShop-Fehlerprotokollen ist keine geheimnisvolle Kunst, die erfahrenen Entwicklern vorbehalten ist. Es ist eine praktische Fähigkeit, die darauf aufbaut zu wissen, wo Protokolle gespeichert sind, wie man sie filtert und wie man interpretiert, was sie enthalten. Die Protokolle unter var/logs/, das PHP-Fehlerprotokoll und das Webserver-Fehlerprotokoll dienen jeweils einem anderen Zweck und geben zusammen ein vollständiges Bild jedes Problems. Das Aktivieren des Debug-Modus liefert detaillierte Fehlermeldungen. Stack Traces zeigen Ihnen die exakte Kette von Funktionsaufrufen, die zum Fehler geführt hat. Werkzeuge wie grep und tail -f ermöglichen es, Fehler auch in großen, stark frequentierten Protokolldateien effizient zu finden und zu überwachen. Beherrschen Sie diese Techniken, und Sie werden Probleme schneller lösen, mit weniger Frustration und deutlich weniger Abhängigkeit von externem Support.

Vollständige Antwort lesen

HTTP-Fehlercodes in PrestaShop verstehen

HTTP-Fehlercodes sind standardisierte Antworten von Ihrem Webserver, die darauf hinweisen, dass beim Versuch eines Browsers oder Suchmaschinen-Bots, auf eine Seite zuzugreifen, etwas schiefgelaufen ist. Für PrestaShop-Shopbetreiber können diese Fehler verlorene Verkäufe, frustrierte Kunden und beschädigte SEO-Rankings bedeuten.

Fehler 403 - Verboten

Ein 403-Fehler bedeutet, dass der Server Ihre Anfrage verstanden hat, sie aber nicht autorisiert. Dies ist typischerweise ein Berechtigungs- oder Zugriffskontrollproblem.

Häufige Ursachen in PrestaShop

1. Falsche Datei- und Verzeichnisberechtigungen

Verzeichnisse sollten auf 755 und Dateien auf 644 gesetzt sein.

# Berechtigungen über SSH korrigieren
find /var/www/html/prestashop -type d -exec chmod 755 {} \;
find /var/www/html/prestashop -type f -exec chmod 644 {} \;
chown -R www-data:www-data /var/www/html/prestashop

2. .htaccess-Regeln blockieren den Zugang

Eine zu restriktive .htaccess-Datei kann legitime Anfragen blockieren.

3. ModSecurity oder WAF blockieren Anfragen

Web Application Firewalls können Falsch-Positive erzeugen und legitime Admin-Anfragen blockieren.

4. IP-basierte Zugriffsbeschränkungen

Wenn sich Ihre IP geändert hat, können Sie ausgesperrt sein.

403-Fehler beheben

Dateiberechtigungen überprüfen und korrigieren
.htaccess auf zu restriktive Regeln prüfen
Hosting-Sicherheitsprotokolle auf WAF-Blockierungen prüfen
Prüfen, ob Ihre IP auf einer Sperrliste steht
Notfalls .htaccess temporär umbenennen und testen

Fehler 404 - Nicht gefunden

Ein 404-Fehler bedeutet, dass der Server die angeforderte Seite nicht finden kann.

1. Deaktivierte oder falsch konfigurierte Friendly URLs

Gehen Sie zu Shopparameter > Traffic & SEO, stellen Sie sicher, dass Friendly URLs aktiviert ist, und klicken Sie auf Speichern. Prüfen Sie, ob mod_rewrite auf Ihrem Server aktiviert ist.

2. Gelöschte Produkte oder Kategorien ohne Weiterleitungen

Richten Sie immer 301-Weiterleitungen ein, wenn Sie Inhalte entfernen.

3. Fehlende oder beschädigte .htaccess

Generieren Sie eine neue .htaccess über Shopparameter > Traffic & SEO.

404-Fehler beheben

Überprüfen, ob .htaccess existiert und korrekt konfiguriert ist
mod_rewrite auf dem Server überprüfen
.htaccess regenerieren
301-Weiterleitungen für gelöschte Inhalte einrichten
Google Search Console auf Crawl-Fehler prüfen

Fehler 500 - Interner Serverfehler

Ein 500-Fehler bedeutet, dass auf der Serverseite etwas schiefgelaufen ist, der Server aber nicht spezifischer sein kann.

1. PHP-Speicherlimit überschritten

# In php.ini
memory_limit = 512M

2. PHP-Syntaxfehler oder fatale Fehler

# In config/defines.inc.php ändern:
define('_PS_MODE_DEV_', true);

3. PHP-Versionsinkompatibilität

PrestaShop	PHP Minimum	PHP Empfohlen
1.7.x	7.1	7.4
8.x	7.2	8.1
9.x	8.1	8.2+

4. Datenbankverbindungsprobleme

Überprüfen Sie die Datenbankzugangsdaten in app/config/parameters.php.

5. Modulkonflikte

# Problematischen Modulordner umbenennen
mv modules/problematic_module modules/problematic_module_disabled

500-Fehler beheben

Debug-Modus aktivieren
PHP-Fehlerprotokoll prüfen
PrestaShop-Fehlerprotokoll prüfen
PHP-Speicherlimit und Ausführungszeit erhöhen
PHP-Versionskompatibilität überprüfen
Kürzlich installierte Module deaktivieren

Fehler 503 - Dienst nicht verfügbar

Ein 503-Fehler bedeutet, dass der Server die Anfrage vorübergehend nicht bearbeiten kann.

1. Wartungsmodus noch aktiv

UPDATE ps_configuration SET value = '0' WHERE name = 'PS_SHOP_ENABLE';

2. Serverüberlastung

Hosting-Plan upgraden
PrestaShop-Caching aktivieren
CDN wie Cloudflare nutzen
OPcache für PHP aktivieren

3. PHP-FPM-Worker-Erschöpfung

# In der PHP-FPM-Pool-Konfiguration
pm = dynamic
pm.max_children = 50
pm.start_servers = 10

503-Fehler beheben

Wartungsmodus prüfen und deaktivieren
Serverressourcen überwachen
PHP-FPM-Protokolle prüfen
Cron-Job-Planung überprüfen
Hosting upgraden falls nötig

Allgemeine Debugging-Tipps

Serverprotokolle prüfen

Apache - /var/log/apache2/error.log
Nginx - /var/log/nginx/error.log
PHP-FPM - /var/log/php-fpm/error.log
PrestaShop - /var/logs/

Alle Caches leeren

Nach jeder Korrektur alle Caches leeren - PrestaShop-Cache, OPcache, CDN-Cache und Browser-Cache.

Vollständige Antwort lesen

Wie PrestaShop Cookies verwendet

Jeder PrestaShop-Shop ist auf Cookies angewiesen, um zu funktionieren. Sie verwalten Kundensitzungen, merken sich Warenkorbinhalte, speichern Sprach- und Währungspräferenzen, verfolgen den Anmeldestatus und ermöglichen es dem Back-Office, Administratoren zu authentifizieren. Ohne Cookies kann ein PrestaShop-Shop keinen Zustand zwischen Seitenaufrufen aufrechterhalten, was bedeutet: kein Warenkorb, keine Kundenanmeldung und kein Admin-Zugriff.

PrestaShop verwendet zwei primäre Cookies. Das Front-Office-Cookie, das typischerweise nach Ihrem Shop benannt ist (wie PrestaShop-abc123), verwaltet alles, was die kundenseitige Oberfläche benötigt. Das Back-Office-Cookie mit einem ähnlichen Benennungsmuster, aber anderem Geltungsbereich, verwaltet die Administrator-Authentifizierung. Beide Cookies speichern serialisierte Daten direkt im Cookie-Wert, was eine Designentscheidung ist, die erhebliche Auswirkungen auf Leistung, Sicherheit und DSGVO-Konformität hat.

PrestaShop-Cookie-Struktur und Inhalte

Anders als viele Webanwendungen, die nur eine Sitzungs-ID im Cookie speichern und alle Sitzungsdaten auf dem Server halten, speichert PrestaShop umfangreiche Daten direkt im Cookie selbst. Das Front-Office-Cookie enthält Felder einschließlich der Kunden-ID, des Kundennamens und der E-Mail, ob der Kunde angemeldet ist, der Warenkorb-ID, der ausgewählten Sprache, der ausgewählten Währung, der zuletzt besuchten Kategorie, des zuletzt besuchten Produkts, des Checkout-Schritts und verschiedener anderer Zustandsinformationen.

Diese Daten werden mit PrestaShops eigener Cookie-Klasse (Cookie.php im Verzeichnis classes) serialisiert. Der Cookie-Wert wird mit einem Schlüssel verschlüsselt, der aus Ihrer _COOKIE_KEY_-Konstante in config/settings.inc.php (PrestaShop 1.6/1.7) oder app/config/parameters.php (PrestaShop 8.x) abgeleitet wird. Diese Verschlüsselung verhindert Manipulation und schützt sensible Daten wie die Kunden-ID und E-Mail davor, im Browser lesbar zu sein.

Warum PrestaShop Daten im Cookie speichert

Der historische Grund für dieses Design ist die Leistung. Durch die Speicherung von Sitzungsdaten im Cookie vermeidet PrestaShop eine serverseitige Sitzungsabfrage bei jeder Anfrage. Es ist kein Lesen aus einer Sitzungsdatei, keine Datenbankabfrage und keine Verbindung zu einem Sitzungsserver erforderlich. Die Daten kommen mit der Anfrage und sind sofort verfügbar.

Dieser Ansatz hat jedoch Nachteile, die mit wachsenden Shops relevanter werden. Die Cookie-Größe nimmt mit der Menge der gespeicherten Daten zu, und jede HTTP-Anfrage (einschließlich Anfragen für Bilder, CSS- und JavaScript-Dateien) sendet das vollständige Cookie an den Server. Ein 4 KB großes Cookie, das mit 30 Asset-Anfragen pro Seite gesendet wird, bedeutet 120 KB unnötige Upload-Bandbreite pro Seitenaufruf. Dieser Overhead ist bei mobilen Verbindungen und im großen Maßstab messbar.

Cookie-Größe und Leistungsauswirkungen

Browser-Cookies haben ein praktisches Größenlimit von etwa 4.096 Bytes pro Cookie. PrestaShops Front-Office-Cookie kann sich diesem Limit nähern oder es überschreiten, insbesondere wenn Module ihre eigenen Daten zum Cookie hinzufügen, sei es über den hookActionBeforeSubmitAccount oder durch direkte Änderung des Cookie-Objekts.

Messung der Cookie-Größen-Auswirkung

Um zu sehen, wie Cookies die Leistung Ihres Shops beeinflussen, öffnen Sie die Entwicklertools Ihres Browsers und gehen Sie zum Tab Netzwerk. Schauen Sie sich die Anfrage-Header für jede Anfrage an Ihre Domain an. Der Cookie-Header zeigt alle gesendeten Cookies. Notieren Sie die Größe. Schauen Sie sich nun die Anfrage-Header für eine statische Ressource (ein Bild oder eine CSS-Datei) auf derselben Domain an. Dieselben Cookies werden auch mit dieser Anfrage gesendet und erzeugen Overhead ohne Grund.

Reduzierung des Cookie-Overheads für statische Ressourcen

Der effektivste Weg, den Cookie-Overhead für statische Dateien zu eliminieren, ist, sie von einer anderen Domain (einer cookielosen Domain) auszuliefern. In PrestaShop können Sie Medienserver im Back-Office unter Erweiterte Einstellungen > Leistung konfigurieren. Wenn Sie einen Medienserver wie static.ihredomain.de einrichten, liefert PrestaShop Bilder, CSS und JavaScript von dieser Domain aus. Da Cookies domainspezifisch sind, werden keine Cookies mit Anfragen an die Medien-Domain gesendet.

Alternativ kann ein CDN wie Cloudflare, Fastly oder CloudFront Ihre statischen Ressourcen ausliefern. CDN-Edge-Server entfernen typischerweise Cookies aus zwischengespeicherten Antworten, sodass selbst wenn Cookies in der Anfrage gesendet werden, die Antwort aus dem Cache kommt, ohne den Overhead eines Roundtrips zu Ihrem Ursprungsserver.

Cookie-Aufblähung durch Module

Drittanbieter-Module fügen manchmal Daten zum PrestaShop-Cookie hinzu, ohne die Größenauswirkungen zu berücksichtigen. Jedes Modul, das einen Wert im Cookie speichert, erhöht dessen Größe und den Overhead bei jeder Anfrage. Wenn Ihr Cookie ungewöhnlich groß ist, prüfen Sie, welche Daten Module hinzugefügt haben, indem Sie den entschlüsselten Cookie-Inhalt untersuchen oder den Modulcode auf Aufrufe wie $this->context->cookie->mymodule_value = ... überprüfen.

Gut konzipierte Module verwenden serverseitigen Speicher (Datenbank oder Cache) und speichern höchstens einen kleinen Identifikator im Cookie. Schlecht konzipierte Module laden vollständige Datenstrukturen in das Cookie und blähen es auf. Wenn Sie ein problematisches Modul identifizieren, wenden Sie sich an den Entwickler oder ersetzen Sie die Cookie-Speicherung durch datenbankgestützten Speicher mit einer Sitzungskennung.

Sitzungsverwaltung: Dateien, Datenbank und Redis

Während PrestaShop einige Daten direkt in Cookies speichert, unterhält PHP auch sein eigenes Sitzungssystem. PrestaShops Back-Office ist stärker auf PHP-Sitzungen angewiesen als das Front-Office. Der Sitzungs-Handler bestimmt, wo Sitzungsdaten auf der Serverseite gespeichert werden.

Dateibasierte Sitzungen (Standard)

Standardmäßig speichert PHP Sitzungen als Dateien im Verzeichnis session.save_path (typischerweise /tmp oder /var/lib/php/sessions). Jede Sitzung erstellt eine Datei. Für einen Shop mit Tausenden aktiver Sitzungen bedeutet dies Tausende kleiner Dateien. Dateibasierte Sitzungen funktionieren gut für kleine bis mittlere Shops, können aber bei Skalierung Probleme verursachen.

Häufige Probleme mit dateibasierten Sitzungen umfassen eine langsame Sitzungs-Garbage-Collection, wenn das Sitzungsverzeichnis zu viele Dateien enthält, Dateisperren, die eine Serialisierung von Anfragen verursachen können (zwei Anfragen derselben Sitzung können nicht gleichzeitig verarbeitet werden), und Shared-Hosting-Umgebungen, in denen das Sitzungsverzeichnis voll wird oder restriktive Berechtigungen hat.

Datenbank-Sitzungen

PrestaShop unterstützt das Speichern von Sitzungen in der Datenbank. Dies wird in den PHP-Einstellungen oder über PrestaShops Sitzungs-Handler konfiguriert. Datenbank-Sitzungen beseitigen die Dateisystemprobleme, fügen aber jeder Anfrage eine Datenbankabfrage hinzu. Für Shops mit bereits hoher Datenbankbelastung kann dies die Leistung verschlechtern. Datenbank-Sitzungen haben jedoch den Vorteil, dass sie über mehrere Webserver in einem lastverteilten Setup gemeinsam genutzt werden können.

Redis- oder Memcached-Sitzungen

Für PrestaShop-Shops mit hohem Traffic ist Redis der optimale Sitzungsspeicher-Backend. Redis speichert Sitzungsdaten im Arbeitsspeicher und bietet Zugriffszeiten unter einer Millisekunde. Es unterstützt automatisches Ablaufen (Sitzungs-Timeout), und Sitzungsdaten werden über alle Webserver-Instanzen hinweg gemeinsam genutzt.

Um PHP für die Verwendung von Redis für Sitzungen zu konfigurieren, setzen Sie session.save_handler = redis und session.save_path = "tcp://127.0.0.1:6379" in Ihrer php.ini oder PHP-FPM-Pool-Konfiguration. Wenn Ihre Redis-Instanz eine Authentifizierung erfordert, fügen Sie das Passwort zum Speicherpfad hinzu: "tcp://127.0.0.1:6379?auth=ihrpasswort".

PrestaShop unterstützt bereits Redis für Objekt-Caching (konfiguriert im Back-Office unter Erweiterte Einstellungen > Leistung). Die Verwendung derselben Redis-Instanz für Sitzungen und Objekt-Caching vereinfacht Ihre Infrastruktur und bietet gleichzeitig hervorragende Leistung für beides.

SameSite-, Secure- und HttpOnly-Attribute

Moderne Browser erzwingen Cookie-Sicherheitsattribute, die direkt beeinflussen, wie PrestaShop-Cookies funktionieren. Falsch konfigurierte Cookie-Attribute verursachen Anmeldefehler, verlorene Warenkörbe und Fehler bei der Zahlungsabwicklung.

SameSite-Attribut

Das SameSite-Attribut steuert, ob ein Cookie mit Cross-Site-Anfragen gesendet wird. Es hat drei mögliche Werte:

SameSite=Strict bedeutet, dass das Cookie niemals mit Cross-Site-Anfragen gesendet wird. Dies ist zu restriktiv für PrestaShop, da Kunden, die einen Link zu Ihrem Shop aus einer E-Mail oder einem Social-Media-Beitrag anklicken, ihr Sitzungs-Cookie nicht gesendet bekommen und somit effektiv abgemeldet werden.

SameSite=Lax ist der Standard in modernen Browsern. Das Cookie wird mit Top-Level-Navigationen (Klick auf einen Link) gesendet, aber nicht mit Cross-Site-Unteranfragen (Bilder, Iframes, AJAX). Dies funktioniert in den meisten Fällen gut für PrestaShops Front-Office-Cookie.

SameSite=None bedeutet, dass das Cookie immer gesendet wird, auch mit Cross-Site-Anfragen. Dies muss mit dem Secure-Attribut kombiniert werden. Es wird benötigt, wenn Ihr Shop in einem Iframe auf einer anderen Website eingebettet ist oder wenn Zahlungsgateways von Drittanbietern mit intakter Sitzung zu Ihrem Shop zurückleiten müssen.

Zahlungsgateway-Probleme

Viele PrestaShop-Zahlungsprobleme werden durch SameSite-Cookie-Probleme verursacht. Das typische Szenario ist: Ein Kunde geht zur Kasse, wird zur Website des Zahlungsgateways weitergeleitet, schließt die Zahlung ab und wird zu Ihrem Shop zurückgeleitet. Wenn das Sitzungs-Cookie SameSite=Lax hat, wird es bei der Rückleitung vom Zahlungsgateway möglicherweise nicht gesendet, abhängig davon, wie die Weiterleitung implementiert ist. Wenn das Gateway eine POST-Weiterleitung verwendet (üblich bei 3D Secure), blockiert die Lax-Richtlinie das Cookie, und PrestaShop verliert die Sitzung. Der Kunde sieht einen leeren Warenkorb oder eine generische Fehlerseite anstelle der Bestellbestätigung.

Die Lösung besteht darin, das PrestaShop-Cookie auf SameSite=None; Secure zu setzen. In PrestaShop 1.7.7+ und 8.x kann dies in den Cookie-Einstellungen konfiguriert werden. Für ältere Versionen müssen Sie möglicherweise die Cookie-Klasse ändern oder Header über Ihre Webserver-Konfiguration hinzufügen. Testen Sie immer die Zahlungsabläufe nach der Änderung der SameSite-Einstellungen.

Secure-Attribut

Das Secure-Attribut stellt sicher, dass das Cookie nur über HTTPS-Verbindungen gesendet wird. Wenn Ihr Shop über HTTPS läuft (was der Fall sein sollte), verhindert dieses Attribut, dass das Cookie über eine unverschlüsselte Verbindung übertragen wird und schützt es vor Abfangen. PrestaShop setzt dieses Attribut, wenn der Shop eine HTTPS-Verbindung erkennt.

Ein häufiges Problem tritt bei gemischten HTTP/HTTPS-Konfigurationen auf. Wenn Ihr Back-Office auf HTTPS läuft, aber einige Front-Office-Seiten auf HTTP, werden als Secure markierte Cookies auf HTTP-Seiten nicht gesendet und die Sitzung wird unterbrochen. Die Lösung ist, HTTPS überall zu erzwingen, was Sie ohnehin aus Sicherheits- und SEO-Gründen tun sollten.

HttpOnly-Attribut

Das HttpOnly-Attribut verhindert, dass JavaScript über document.cookie auf das Cookie zugreifen kann. Dies ist eine wichtige Sicherheitsmaßnahme gegen Cross-Site-Scripting (XSS)-Angriffe. Wenn ein Angreifer bösartiges JavaScript in Ihren Shop injiziert (z. B. über ein anfälliges Modul), verhindert das HttpOnly-Attribut, dass dieser Code Sitzungs-Cookies stehlen kann.

PrestaShop setzt das HttpOnly-Flag standardmäßig auf seine Cookies. Deaktivieren Sie dies nicht, es sei denn, Sie haben einen sehr spezifischen Grund und verstehen die Sicherheitsimplikationen.

Fehlersuche bei Sitzungs- und Cookie-Problemen

Cookie- und Sitzungsprobleme äußern sich durch mysteriöse Symptome: Kunden werden zufällig abgemeldet, Warenkörbe leeren sich von selbst, Admin-Sitzungen laufen sofort ab, Checkout-Prozesse scheitern still. Systematische Fehlersuche erfordert die Überprüfung mehrerer Ebenen.

Browser-Entwicklertools

Öffnen Sie den Tab Anwendung (Chrome) oder Speicher (Firefox) und navigieren Sie zu Cookies. Finden Sie die Domain Ihres Shops und untersuchen Sie alle Cookies. Prüfen Sie die Spalten Name, Wert, Domain, Pfad, Ablaufdatum, Größe, HttpOnly, Secure und SameSite. Achten Sie auf Cookies, die unerwartet groß sind, falsche Domain-Einstellungen haben (ein Cookie für www.beispiel.de wird nicht an beispiel.de gesendet) oder denen Sicherheitsattribute fehlen.

Serverseitige Sitzungsüberprüfung

Wenn Sitzungen in Dateien gespeichert werden, prüfen Sie das Sitzungsverzeichnis auf Vorhandensein und Alter der Sitzungsdateien. Wenn ein Kunde berichtet, abgemeldet worden zu sein, finden Sie seine Sitzungsdatei (der Dateiname ist die Sitzungs-ID aus dem PHPSESSID-Cookie) und prüfen Sie, wann sie zuletzt geändert wurde. Wenn die Datei fehlt, wurde die Sitzung entweder durch die Garbage Collection bereinigt oder nie korrekt erstellt.

Für Redis-Sitzungen verwenden Sie redis-cli, um zu prüfen, ob der Sitzungsschlüssel existiert: EXISTS PHPREDIS_SESSION:session_id. Prüfen Sie die TTL, um zu sehen, ob sie bald abläuft: TTL PHPREDIS_SESSION:session_id.

Häufige Ursachen für zufällige Abmeldungen

Der _COOKIE_KEY_ hat sich geändert. Wenn sich dieser Schlüssel ändert (bei einer fehlkonfigurierten Bereitstellung, einem Überschreiben der Einstellungsdatei oder einem Upgrade), werden alle vorhandenen Cookies unlesbar, da sie mit dem alten Schlüssel verschlüsselt wurden. Jeder Kunde wird effektiv abgemeldet. Die Lösung besteht darin, den ursprünglichen Schlüssel aus einem Backup wiederherzustellen.

Die Sitzungs-Garbage-Collection ist zu aggressiv. PHPs session.gc_maxlifetime bestimmt, wie lange (in Sekunden) eine Sitzungsdatei als gültig betrachtet wird. Wenn dieser Wert zu niedrig eingestellt ist (der Standard ist 1440 Sekunden oder 24 Minuten), werden Sitzungen für Kunden, die langsam browsen, gelöscht. Für einen Shop sollten Sie diesen Wert auf mindestens 3600 (1 Stunde) oder höher setzen.

Load Balancer ohne Sitzungsaffinität. Wenn Ihr Shop auf mehreren Webservern hinter einem Load Balancer läuft und Sitzungen in Dateien gespeichert werden, hat jeder Server sein eigenes Sitzungsverzeichnis. Ein Kunde, dessen Anfragen zwischen Servern alternieren, verliert bei jedem Wechsel seine Sitzung. Die Lösung ist entweder Sitzungsaffinität (Sticky Sessions) auf dem Load Balancer oder gemeinsamer Sitzungsspeicher über Redis oder eine Datenbank.

Cookie-Domain-Nichtübereinstimmung. Wenn Ihr Shop sowohl unter www.beispiel.de als auch unter beispiel.de erreichbar ist, aber die Cookie-Domain auf www.beispiel.de gesetzt ist, haben Kunden, die die Seite ohne das www-Präfix aufrufen, das Cookie nicht. Stellen Sie eine konsistente Domain-Nutzung mit einer Weiterleitung sicher und überprüfen Sie die Cookie-Domain in den PrestaShop-Einstellungen.

DSGVO-Cookie-Konformität

Die Datenschutz-Grundverordnung (DSGVO) und die ePrivacy-Richtlinie erfordern eine informierte Einwilligung, bevor nicht-essentielle Cookies im Browser eines Nutzers gesetzt werden. PrestaShop-Shops müssen diese Vorschriften einhalten, und Nichteinhaltung kann zu erheblichen Bußgeldern führen.

Essentielle vs. nicht-essentielle Cookies

Die DSGVO unterscheidet zwischen Cookies, die für die Funktion der Website streng notwendig sind, und Cookies, die anderen Zwecken dienen, wie Analysen, Marketing oder Personalisierung. PrestaShops Sitzungs-Cookie ist essentiell, da der Shop ohne es nicht funktionieren kann. Ein Kunde kann keine Produkte zum Warenkorb hinzufügen oder einen Kauf abschließen, ohne ein Sitzungs-Cookie. Essentielle Cookies erfordern keine Einwilligung nach der DSGVO.

Viele andere Cookies, die häufig in PrestaShop-Shops zu finden sind, sind jedoch nicht-essentiell und erfordern eine ausdrückliche Einwilligung, bevor sie gesetzt werden. Dazu gehören Google Analytics Tracking-Cookies (_ga, _gid), Facebook-Pixel-Cookies, Werbe-Cookies von Remarketing-Plattformen, Live-Chat-Widget-Cookies, Social-Media-Sharing-Button-Cookies und alle Cookies, die von Drittanbieter-Modulen für Tracking oder Personalisierung gesetzt werden.

Implementierung der Cookie-Einwilligung

PrestaShop enthält keinen eingebauten Cookie-Einwilligungsmechanismus, der den DSGVO-Anforderungen entspricht. Sie benötigen entweder ein PrestaShop-Modul, das für die Cookie-Einwilligung konzipiert ist, oder die Integration mit einer Consent-Management-Plattform (CMP) wie Cookiebot, Osano oder Usercentrics.

Eine ordnungsgemäße Cookie-Einwilligungs-Implementierung muss dem Nutzer eine klare Wahl präsentieren, bevor nicht-essentielle Cookies gesetzt werden. Sie muss dem Nutzer ermöglichen, einzelne Cookie-Kategorien (Analyse, Marketing usw.) zu akzeptieren oder abzulehnen, und nicht nur eine Alles-oder-Nichts-Wahl anbieten. Sie muss die Wahl des Nutzers speichern und nicht erneut fragen, bis die Einwilligung abläuft. Und sie muss tatsächlich verhindern, dass die blockierten Cookies gesetzt werden, anstatt nur die Präferenz aufzuzeichnen und trotzdem Tracking-Codes zu laden.

Der letzte Punkt ist entscheidend und wird häufig falsch gehandhabt. Ein Einwilligungsbanner, das angezeigt wird, aber unabhängig von der Wahl des Nutzers trotzdem Google Analytics lädt, bietet keinen rechtlichen Schutz. Die Implementierung muss das Laden von Tracking- und Marketing-Ressourcen konditional auf der Grundlage der Einwilligung des Nutzers steuern.

Technische Implementierung der Einwilligung

Der technische Ansatz für einwilligungsbasiertes Cookie-Management umfasst das Einbetten von nicht-essentiellem Code in Einwilligungsprüfungen. Für Inline-JavaScript, das Cookies setzt oder Tracking-Pixel lädt, wird die direkte Ausführung durch einen einwilligungsgesteuerten Loader ersetzt. Der Tracking-Code wird gespeichert, aber erst ausgeführt, wenn der Nutzer seine Einwilligung gibt.

Für Drittanbieter-Module, die Cookies setzen, ist die Implementierung komplexer. Einige Module bieten Hooks oder Konfigurationsoptionen für die Einwilligungsintegration. Andere laden ihre Cookies bedingungslos und müssen modifiziert oder ersetzt werden. Prüfen Sie jedes Modul in Ihrem Shop auf Cookie-Nutzung und bestimmen Sie, welche nicht-essentielle Cookies setzen.

Cookie-Einwilligung und Caching

Ganzseiten-Caching erzeugt einen Konflikt mit der Cookie-Einwilligung. Wenn eine Seite mit geladenem Google Analytics zwischengespeichert und einem Nutzer ausgeliefert wird, der keine Einwilligung gegeben hat, verstoßen Sie gegen die DSGVO. Es gibt zwei Ansätze, um damit umzugehen.

Der erste Ansatz besteht darin, die Seite ohne nicht-essentielle Ressourcen zwischenzuspeichern und sie dynamisch per JavaScript nach der Einwilligungsprüfung zu injizieren. Dies funktioniert gut mit PrestaShops CCC-System (Combine, Compress, Cache) und mit Varnish oder anderen Reverse-Proxy-Caches.

Der zweite Ansatz besteht darin, Seiten für Nutzer, die noch keine Einwilligungsentscheidung getroffen haben (Erstbesucher), nicht zwischenzuspeichern. Dies beeinträchtigt die Leistung für neue Besucher, stellt aber die Konformität sicher. Die meisten Consent-Management-Plattformen verwenden den ersten Ansatz, da er die Caching-Vorteile erhält.

Cookie-bezogene Sicherheitsbedenken

Über die bereits besprochenen HttpOnly- und Secure-Attribute hinaus gibt es zusätzliche Sicherheitsaspekte für PrestaShop-Cookies.

Cookie-Diebstahl und Sitzungsübernahme

Wenn ein Angreifer ein gültiges PrestaShop-Sitzungs-Cookie erhält, kann er den Kunden oder Administrator imitieren. Der primäre Schutz besteht aus HTTPS überall (verhindert Abfangen), HttpOnly-Cookies (verhindert XSS-Diebstahl) und dem Secure-Attribut (verhindert Übertragung über HTTP). PrestaShop bindet Sitzungen in einigen Konfigurationen auch an IP-Adressen, was eine zusätzliche Schutzschicht bietet, aber Probleme für Nutzer verursachen kann, deren IP-Adressen sich ändern (mobile Nutzer, VPN-Nutzer).

Cookie-Schlüsselsicherheit

Der _COOKIE_KEY_ in Ihrer PrestaShop-Konfiguration ist der Hauptschlüssel für die Cookie-Verschlüsselung. Wenn dieser Schlüssel kompromittiert wird, kann ein Angreifer jedes PrestaShop-Cookie entschlüsseln und gültige Sitzungs-Cookies fälschen. Schützen Sie diesen Schlüssel, indem Sie den Zugriff auf Ihre Konfigurationsdateien einschränken, ihn nie in öffentlichen Repositories committen und ihn nie in Supportanfragen teilen.

Cookie-Fixierung-Prävention

Sitzungsfixierungsangriffe beinhalten, dass ein Angreifer eine bekannte Sitzungs-ID im Browser des Opfers setzt, bevor das Opfer sich anmeldet. Wenn sich das Opfer anmeldet, wird die vom Angreifer voreingestellte Sitzungs-ID authentifiziert. PrestaShop mindert dies, indem die Sitzungs-ID bei der Anmeldung neu generiert wird. Stellen Sie sicher, dass die Sitzungs-ID-Neugenerierung korrekt funktioniert und nicht durch ein Modul oder eine Konfigurationsänderung deaktiviert wurde.

Fehlerbehebung häufiger Cookie-Probleme

Admin-Panel Anmelde-Schleife

Das Symptom ist die Eingabe gültiger Anmeldedaten im PrestaShop Back-Office, kurzes Sehen des Dashboards und Weiterleitung zurück zur Anmeldeseite. Dies ist fast immer ein Cookie-Problem. Prüfen Sie, ob die Cookie-Domain korrekt ist, ob sich der Admin-Verzeichnisname geändert hat, ob HTTPS korrekt konfiguriert ist (Mixed Content kann verhindern, dass das Secure-Cookie gesendet wird) und ob das Sitzungsspeicherverzeichnis vom Webserver beschreibbar ist.

Warenkorb leert sich bei Seitennavigation

Wenn sich der Warenkorb leert, wenn der Kunde zu einer anderen Seite navigiert, wird das Sitzungs-Cookie nicht aufrechterhalten. Häufige Ursachen sind eine fehlende oder falsche Cookie-Domain-Einstellung, eine fehlkonfigurierte session.cookie_lifetime in PHP (der Wert 0 bedeutet, dass das Cookie abläuft, wenn der Browser geschlossen wird, was korrekt ist, aber einige Konfigurationen setzen ihn auf eine sehr kurze Zeit) oder ein CDN oder eine Caching-Schicht, die den Set-Cookie-Header aus Antworten entfernt.

Checkout-Fehler nach Zahlung

Wenn Kunden die Zahlung abschließen, aber beim Zurückkehren zu Ihrem Shop einen Fehler oder leeren Warenkorb sehen, ist die SameSite-Cookie-Richtlinie in der Regel die Ursache, wie im Abschnitt zu Zahlungsgateways oben beschrieben. Testen Sie den gesamten Checkout-Ablauf mit geöffneten Browser-Entwicklertools und beobachten Sie die Cookies in jedem Schritt, um festzustellen, wo die Sitzung verloren geht.

Mehrere Shops auf derselben Domain

Wenn Sie mehrere PrestaShop-Installationen auf derselben Domain betreiben (z. B. in Unterverzeichnissen), können deren Cookies in Konflikt geraten. Jede Installation verwendet einen ähnlichen Cookie-Namen, und wenn der Cookie-Pfad auf / gesetzt ist, überschreibt das Cookie eines Shops das des anderen. Setzen Sie eindeutige Cookie-Namen für jede Installation über den _COOKIE_KEY_ (der den Cookie-Namen beeinflusst) oder konfigurieren Sie den Cookie-Pfad so, dass er dem Unterverzeichnis jeder Installation entspricht.

Optimierung der Cookie-Konfiguration für Leistung

Eine gut optimierte PrestaShop-Cookie-Konfiguration minimiert den Overhead bei Erhaltung der Funktionalität. Verwenden Sie eine cookielose Domain oder ein CDN für statische Ressourcen, um das Senden von Cookies mit Bild-, CSS- und JavaScript-Anfragen zu vermeiden. Halten Sie die Cookie-Größe klein, indem Sie verhindern, dass Module unnötige Daten darin speichern. Setzen Sie angemessene Sitzungs-Timeouts, die Sicherheit (kürzer ist sicherer) mit Benutzererfahrung (länger bedeutet weniger erneute Anmeldungen) in Einklang bringen. Verwenden Sie Redis für den Sitzungsspeicher, um schnellen Zugriff mit gemeinsamem Zustand über Server-Instanzen hinweg zu kombinieren. Aktivieren Sie die Secure- und HttpOnly-Attribute, um die Cookie-Integrität zu schützen, ohne die Leistung zu beeinträchtigen. Implementieren Sie eine ordnungsgemäße Cookie-Einwilligung, um das Laden unnötiger Tracking-Cookies zu vermeiden, die Overhead und rechtliches Risiko hinzufügen.

Jede dieser Optimierungen ist für sich genommen klein, aber zusammen ergeben sie eine deutliche Verbesserung sowohl der Leistung als auch der Konformität. Cookie-Management ist keine glamouröse Arbeit, aber es liegt jeder Interaktion zwischen Ihrem Shop und Ihren Kunden zugrunde und ist es daher wert, richtig gemacht zu werden.

Vollständige Antwort lesen

Warum die Datenbankleistung in PrestaShop wichtig ist

PrestaShop ist eine datenbankintensive Anwendung. Jede Produktseite, Kategorieliste, jedes Suchergebnis, jede Warenkorbaktualisierung und jeder Checkout-Schritt beinhaltet mehrere Datenbankabfragen. Eine typische Produktseite kann je nach Anzahl der installierten Module, der Komplexität des Produkts (Kombinationen, Eigenschaften, Anhänge) und dem Theme 50 bis 200 oder mehr SQL-Abfragen erzeugen. Wenn eine dieser Abfragen langsam läuft, verlangsamt sich die gesamte Seite, und der Effekt potenziert sich unter Last.

Die Herausforderung besteht darin, zu identifizieren, welche Abfragen tatsächlich langsam sind. Bei Hunderten von Abfragen pro Seitenaufruf können Sie nicht einfach raten. Sie brauchen Daten. Das MySQL Slow Query Log ist das direkteste und zuverlässigste Werkzeug zum Sammeln dieser Daten. Es zeichnet jede Abfrage auf, die einen von Ihnen definierten Zeitschwellenwert überschreitet, und gibt Ihnen ein klares Bild davon, wo Ihre Datenbank die meiste Zeit verbringt.

Dieser Leitfaden behandelt, wie Sie das Slow Query Log aktivieren und konfigurieren, wie Sie die Ergebnisse analysieren, wie Sie Abfrageausführungspläne interpretieren und wie Sie die gängigsten Optimierungen für PrestaShop-Datenbanken anwenden.

Das Slow Query Log aktivieren

Das Slow Query Log ist eine MySQL-Funktion, die Abfragen, die eine bestimmte Ausführungszeit überschreiten, in eine Protokolldatei schreibt. Es ist auf den meisten Installationen standardmäßig deaktiviert, da es einen geringen I/O-Overhead verursacht, aber die Leistungskosten sind im Vergleich zum diagnostischen Wert vernachlässigbar.

Konfiguration über my.cnf

Um das Slow Query Log dauerhaft zu aktivieren, fügen Sie die folgenden Zeilen zu Ihrer MySQL-Konfigurationsdatei hinzu. Auf den meisten Linux-Systemen befindet sich diese Datei unter /etc/mysql/my.cnf, /etc/my.cnf oder in einem Verzeichnis wie /etc/mysql/conf.d/:

slow_query_log = 1 aktiviert die Funktion.

slow_query_log_file = /var/log/mysql/slow-query.log gibt an, wohin das Log geschrieben wird. Stellen Sie sicher, dass der MySQL-Prozess Schreibberechtigungen für dieses Verzeichnis hat.

long_query_time = 1 setzt den Schwellenwert in Sekunden. Jede Abfrage, die länger als dieser Wert dauert, wird protokolliert. Beginnen Sie mit 1 Sekunde, um die schlimmsten Übeltäter zu erfassen, und senken Sie dann auf 0,5 oder sogar 0,1 Sekunden, wenn Sie die schlimmsten Abfragen optimiert haben und subtilere Engpässe finden möchten.

log_queries_not_using_indexes = 1 protokolliert Abfragen, die keinen Index verwenden, unabhängig davon, wie lange sie dauern. Dies ist äußerst nützlich für PrestaShop, da viele Leistungsprobleme durch vollständige Tabellenscans auf großen Tabellen verursacht werden. Dies kann jedoch bei einem ausgelasteten Shop viele Protokolleinträge erzeugen, daher sollten Sie es möglicherweise nur vorübergehend während der Analyse aktivieren und danach wieder deaktivieren.

Starten Sie MySQL nach der Bearbeitung der Konfigurationsdatei neu, damit die Änderungen wirksam werden.

Aktivierung zur Laufzeit

Sie können das Slow Query Log auch ohne MySQL-Neustart aktivieren, indem Sie SQL-Befehle ausführen. Verbinden Sie sich als Root mit MySQL und führen Sie aus:

SET GLOBAL slow_query_log = 'ON';

SET GLOBAL long_query_time = 1;

SET GLOBAL log_queries_not_using_indexes = 1;

Laufzeitänderungen werden sofort wirksam, bleiben aber nach einem MySQL-Neustart nicht bestehen. Dieser Ansatz ist nützlich für temporäre Analysesitzungen, in denen Sie Daten für einen bestimmten Zeitraum sammeln und die Protokollierung dann deaktivieren möchten.

Den richtigen Schwellenwert wählen

Der Wert von long_query_time bestimmt, was protokolliert wird. Ein zu hoher Wert bedeutet, dass Sie mäßig langsame Abfragen verpassen, die zusammen die Leistung beeinträchtigen. Ein zu niedriger Wert überflutet das Log mit Einträgen, die einzeln nicht problematisch sind.

Für eine erste Analyse beginnen Sie mit 1 Sekunde. Dies erfasst Abfragen, die eindeutig zu langsam sind. Nach deren Optimierung senken Sie den Schwellenwert auf 0,5 Sekunden, dann auf 0,2 Sekunden. Bei einer gut optimierten PrestaShop-Datenbank ist das Ziel, dass keine Abfrage länger als 0,1 Sekunden dauert, aber dieses Niveau zu erreichen erfordert erhebliche Optimierungsarbeit.

Bedenken Sie, dass die Abfrageausführungszeit mit der Serverlast variiert. Eine Abfrage, die unter normaler Last 0,3 Sekunden dauert, kann während eines Traffic-Spitze 2 Sekunden dauern, aufgrund von CPU-Wettbewerb, Festplatten-I/O-Engpässen oder Sperrkonflikten. Das Slow Query Log erfasst die tatsächlichen Ausführungszeiten, daher gibt Ihnen die Analyse von Logs aus Spitzenverkehrszeiten das realistischste Bild.

Das Slow Query Log analysieren

Das rohe Slow Query Log ist eine Textdatei mit Einträgen, die so aussehen:

# Time: 2024-03-15T14:22:33.456789Z
# User@Host: prestashop[prestashop] @ localhost []
# Query_time: 3.456123 Lock_time: 0.000234 Rows_sent: 1 Rows_examined: 847293
SET timestamp=1710511353;
SELECT * FROM ps_product WHERE active = 1 AND id_product NOT IN (SELECT id_product FROM ps_category_product WHERE id_category = 2);

Die wichtigen Felder sind Query_time (wie lange die Abfrage dauerte), Lock_time (wie lange sie auf eine Sperre gewartet hat), Rows_sent (wie viele Zeilen zurückgegeben wurden) und Rows_examined (wie viele Zeilen MySQL durchsuchen musste, um das Ergebnis zu finden). Eine Abfrage, die 847.293 Zeilen durchsucht, um 1 Zeile zurückzugeben, ist ein klares Zeichen für einen fehlenden Index oder eine ineffiziente Abfragestruktur.

mysqldumpslow verwenden

Das Lesen der rohen Logdatei ist bei ausgelasteten Shops, die Tausende langsamer Abfrageeinträge erzeugen, unpraktisch. Das Tool mysqldumpslow, das mit MySQL mitgeliefert wird, aggregiert und fasst Slow-Query-Log-Einträge zusammen. Es gruppiert identische Abfragen (abstrahiert von spezifischen Werten) und sortiert sie nach verschiedenen Kriterien.

Um die 10 langsamsten Abfragen nach Durchschnittszeit zu finden: mysqldumpslow -s at -t 10 /var/log/mysql/slow-query.log

Um die Abfragen mit der höchsten Gesamtausführungszeit zu finden: mysqldumpslow -s t -t 10 /var/log/mysql/slow-query.log

Um die Abfragen zu finden, die die meisten Zeilen durchsucht haben: mysqldumpslow -s r -t 10 /var/log/mysql/slow-query.log

Das -s-Flag gibt die Sortierreihenfolge an: at für Durchschnittszeit, t für Gesamtzeit, c für Anzahl (wie oft die Abfrage vorkam), r für durchsuchte Zeilen. Das -t-Flag begrenzt die Ausgabe auf die Top-N-Abfragen.

Die nützlichste Sortierung für die erste Analyse ist nach Gesamtzeit (-s t), die Ihnen zeigt, welche Abfragen insgesamt die meiste Datenbankzeit verbrauchen. Eine Abfrage, die 0,5 Sekunden dauert, aber 1000 Mal pro Stunde ausgeführt wird, verbraucht mehr Gesamtzeit als eine Abfrage, die 5 Sekunden dauert, aber nur einmal pro Stunde ausgeführt wird.

pt-query-digest verwenden

Für eine detailliertere Analyse ist Percona Toolkits pt-query-digest das Branchenstandardtool. Es liefert weitaus detailliertere Statistiken als mysqldumpslow, einschließlich Perzentilverteilungen der Abfragezeiten, Varianzanalyse und Statistiken auf Tabellenebene.

Grundlegende Verwendung: pt-query-digest /var/log/mysql/slow-query.log

Die Ausgabe beginnt mit einem Profilabschnitt, der Abfragen nach Gesamtzeit sortiert, ähnlich wie mysqldumpslow, aber mit mehr Details. Jede Abfrage erhält dann einen detaillierten Abschnitt mit Minimum, Maximum, Durchschnitt, Median und 95. Perzentil der Ausführungszeiten sowie der Verteilung der durchsuchten und gesendeten Zeilen.

Das 95. Perzentil ist besonders wichtig für die PrestaShop-Leistung. Es sagt Ihnen die Ausführungszeit, unter die 95 % der Ausführungen fallen. Wenn der Durchschnitt 0,3 Sekunden beträgt, aber das 95. Perzentil 2,5 Sekunden, haben Sie ein Konsistenzproblem: Meistens ist die Abfrage akzeptabel, aber 5 % der Nutzer erleben eine viel langsamere Antwort.

Sie können Percona Toolkit auf Debian und Ubuntu mit apt install percona-toolkit installieren oder von der Percona-Website herunterladen. Die Installation lohnt sich auf jedem Server, auf dem Sie PrestaShop betreiben.

Häufige langsame Abfragen in PrestaShop

Bestimmte Abfragemuster tauchen wiederholt in PrestaShop-Slow-Query-Logs auf. Die Kenntnis dieser Muster hilft Ihnen, Probleme schneller zu diagnostizieren.

Vollständige Tabellenscans auf ps_product

Abfragen gegen die Tabelle ps_product ohne ordnungsgemäße Index-Nutzung gehören zu den häufigsten langsamen Abfragen. Wenn Ihr Katalog über einige tausend Produkte hinaus wächst, wird jede Abfrage, die die gesamte Produkttabelle scannt, problematisch. Achten Sie auf Abfragen mit WHERE-Klauseln auf Spalten, die nicht indiziert sind, oder Abfragen, die ps_product mit ps_product_lang und ps_product_shop verbinden, ohne die Primärschlüssel effizient zu nutzen.

Kategorieproduktlisten mit vielen Filtern

Wenn Kunden die Facettennavigation (Facettensuche) verwenden, um Produkte nach Attributen, Eigenschaften oder Preisbereichen zu filtern, erzeugt PrestaShop komplexe Abfragen, die mehrere Tabellen verbinden. Die ps_layered_*-Tabellen, die vom Facettensuchmodul verwendet werden, können zu Leistungsengpässen werden, wenn Indizes fehlen oder der Indizierungsprozess nicht kürzlich ausgeführt wurde.

Suchabfragen

PrestaShops integrierte Suche verwendet die Tabellen ps_search_word und ps_search_index. Bei Shops mit großen Katalogen und vielen Suchbegriffen werden diese Tabellen groß und Abfragen dagegen langsam. Die Suchabfrage beinhaltet typischerweise eine Volltextoperation oder mehrere LIKE-Bedingungen, die beide inhärent langsamer sind als Index-Lookups.

Warenkorb- und Bestellabfragen

Abfragen, die Warenkorb- oder Bestelldaten aggregieren, können bei Shops mit langer Geschichte langsam sein. Wenn Ihre ps_cart-Tabelle Millionen von Zeilen hat (was üblich ist, da PrestaShop für fast jeden Besucher einen neuen Warenkorb erstellt), werden Abfragen, die diese Tabelle scannen, langsam. Dasselbe gilt für ps_orders und ps_order_detail bei Shops mit hohem Volumen.

Statistik- und Berichtabfragen

Back-Office-Statistikmodule führen häufig Aggregatabfragen (SUM, COUNT, GROUP BY) über große Tabellen wie ps_orders, ps_connections und ps_page_viewed aus. Diese Abfragen können extrem langsam sein, da sie große Datensätze scannen. Bei Shops, die seit Jahren laufen, können diese Tabellen Millionen von Zeilen enthalten, und Statistikabfragen, die bei einem kleinen Datensatz problemlos funktionierten, dauern jetzt Minuten.

Modulgenierte Abfragen

Drittanbieter-Module erzeugen häufig ineffiziente Abfragen, weil Modulentwickler oft gegen kleine Datensätze testen. Ein Modul, das mit 100 Produkten perfekt funktioniert, kann bei 10.000 Produkten katastrophal langsame Abfragen erzeugen. Das Slow Query Log hilft Ihnen zu identifizieren, welche Module verantwortlich sind, da der Abfragetext oft Tabellennamen oder Muster enthält, die auf bestimmte Module hinweisen.

EXPLAIN zur Abfrageanalyse verwenden

Sobald Sie langsame Abfragen aus dem Log identifiziert haben, besteht der nächste Schritt darin zu verstehen, warum sie langsam sind. Die EXPLAIN-Anweisung zeigt Ihnen, wie MySQL plant, eine Abfrage auszuführen, einschließlich welche Indizes es verwendet, wie viele Zeilen es voraussichtlich durchsuchen muss und welche Join-Strategien es einsetzt.

EXPLAIN-Ausgabe lesen

Führen Sie EXPLAIN gefolgt von der langsamen Abfrage aus. Die Ausgabe zeigt eine Zeile pro Tabelle in der Abfrage mit diesen wichtigen Spalten:

type: Wie MySQL auf die Tabelle zugreift. Werte von gut bis schlecht: system/const (eine Zeile, praktisch kostenlos), eq_ref (eine Zeile pro Join, mit eindeutigem Index), ref (mehrere Zeilen, mit nicht-eindeutigem Index), range (Index-Bereichsscan), index (vollständiger Indexscan), ALL (vollständiger Tabellenscan). Wenn Sie ALL bei einer Tabelle mit mehr als einigen tausend Zeilen sehen, ist das fast sicher Ihr Engpass.

key: Welchen Index MySQL tatsächlich für diese Tabelle gewählt hat. Wenn dies NULL ist, wird kein Index verwendet und MySQL scannt die gesamte Tabelle.

rows: Die geschätzte Anzahl der Zeilen, die MySQL durchsuchen muss. Dies ist eine Schätzung, kein exakter Wert, gibt Ihnen aber ein Gefühl für die Größenordnung. Wenn der geschätzte Zeilenwert nahe der Gesamtzahl der Zeilen in der Tabelle liegt, haben Sie einen vollständigen Tabellenscan.

Extra: Zusätzliche Informationen über den Ausführungsplan. Achten Sie auf Using filesort (MySQL muss Ergebnisse ohne Index sortieren, was bei großen Datensätzen langsam ist), Using temporary (MySQL erstellt eine temporäre Tabelle, oft für GROUP BY oder DISTINCT-Operationen) und Using where (MySQL filtert Zeilen nach dem Lesen, was bedeutet, dass der Index die WHERE-Klausel nicht vollständig abdeckt).

EXPLAIN-Beispiel

Betrachten Sie eine langsame Abfrage: SELECT p.id_product, pl.name FROM ps_product p LEFT JOIN ps_product_lang pl ON p.id_product = pl.id_product WHERE pl.id_lang = 1 AND p.active = 1 AND p.price > 100 ORDER BY p.date_add DESC LIMIT 20

EXPLAIN für diese Abfrage könnte zeigen, dass auf die Tabelle ps_product mit Typ ALL (vollständiger Tabellenscan) zugegriffen wird, kein Schlüssel verwendet wird und die Extra-Spalte Using where; Using filesort zeigt. Dies sagt Ihnen, dass MySQL jede Zeile der Produkttabelle liest, nach aktivem Status und Preis filtert und die Ergebnisse dann nach Datum sortiert. Bei einer Tabelle mit 50.000 Produkten bedeutet dies das Lesen und Sortieren von Tausenden von Zeilen, um nur 20 zurückzugeben.

Die Lösung wäre die Erstellung eines zusammengesetzten Index auf (active, price, date_add) oder die Umstrukturierung der Abfrage, um bestehende Indizes besser zu nutzen.

Index-Optimierung für PrestaShop

Das Hinzufügen der richtigen Indizes ist der effektivste Weg, langsame Abfragen zu beschleunigen. Ein Index ermöglicht MySQL, Zeilen zu finden, ohne die gesamte Tabelle zu scannen, ähnlich wie ein Buchindex Ihnen ermöglicht, ein Thema zu finden, ohne jede Seite zu lesen.

Wann einen Index hinzufügen

Fügen Sie einen Index hinzu, wenn EXPLAIN einen vollständigen Tabellenscan (Typ ALL) bei einer Tabelle mit vielen Zeilen zeigt, wenn eine Abfrage häufig ausgeführt wird und konsistent im Slow Query Log erscheint, und wenn die WHERE-Klausel, JOIN-Bedingung oder ORDER BY-Klausel der Abfrage Spalten referenziert, die derzeit nicht indiziert sind.

Fügen Sie Indizes nicht blind hinzu. Jeder Index beschleunigt Lesevorgänge, verlangsamt aber Schreibvorgänge (INSERT, UPDATE, DELETE), da MySQL den Index bei jeder Datenänderung aktualisieren muss. PrestaShop führt viele Schreibvorgänge durch (Warenkorbaktualisierungen, Bestellerstellung, Statistik-Tracking), daher erzeugt übermäßige Indizierung eigene Leistungsprobleme.

Zusammengesetzte Indizes

Für PrestaShop-Abfragen sind zusammengesetzte (mehrspaltige) Indizes oft effektiver als einspaltige Indizes. Ein zusammengesetzter Index auf (id_shop, id_lang, active) ermöglicht MySQL die effiziente Verarbeitung von Abfragen, die nach allen drei Spalten filtern. Die Reihenfolge der Spalten im Index ist wichtig: MySQL verwendet den Index von links nach rechts, daher sollte die selektivste Spalte (die am meisten Zeilen herausfiltert) generell an erster Stelle stehen.

PrestaShops Multishop- und Mehrsprachenarchitektur bedeutet, dass viele Abfragen id_shop- und id_lang-Bedingungen enthalten. Diese Spalten erscheinen in praktisch jeder Abfrage gegen Produkt-, Kategorie- und CMS-Tabellen. Wenn Sie benutzerdefinierte Indizes hinzufügen, ist die Einbeziehung dieser Spalten oft notwendig, damit der Index nützlich ist.

Abdeckende Indizes

Ein abdeckender Index enthält alle Spalten, die eine Abfrage benötigt, sodass MySQL die gesamte Abfrage aus dem Index beantworten kann, ohne die eigentlichen Tabellendaten zu lesen. Dies wird in EXPLAIN als Using index in der Extra-Spalte angezeigt. Abdeckende Indizes bieten die bestmögliche Leistung, da das Lesen aus einem Index schneller ist als das Lesen aus der Tabelle selbst (Indizes sind kleiner und passen eher in den Speicher).

Häufige Index-Ergänzungen für PrestaShop

Mehrere Indizes, die in einer Standard-PrestaShop-Installation nicht vorhanden sind, können die Leistung bei großen Shops erheblich verbessern. Dazu gehören Indizes auf der Spalte date_add in ps_cart und ps_orders für Abfragen, die nach Datum filtern oder sortieren, zusammengesetzte Indizes auf ps_product_attribute für kombinationslastige Abfragen und Indizes auf benutzerdefinierten Spalten, die von Modulen hinzugefügt wurden und häufige Abfragen dagegen ausführen.

Überprüfen Sie vor dem Hinzufügen eines Index die Verbesserung, indem Sie die langsame Abfrage mit und ohne Index ausführen. Verwenden Sie EXPLAIN, um zu bestätigen, dass MySQL den neuen Index tatsächlich verwendet. Ein ungenutzter Index verschwendet Speicherplatz und verlangsamt Schreibvorgänge, ohne einen Nutzen zu bieten.

Verbindungsmanagement und Abfrageoptimierung

Verbindungspooling

PrestaShop verwendet standardmäßig eine einzelne Datenbankverbindung pro Anfrage. Jeder PHP-Prozess öffnet eine Verbindung zu MySQL, führt seine Abfragen aus und schließt die Verbindung, wenn die Anfrage abgeschlossen ist. Bei ausgelasteten Shops mit vielen gleichzeitigen Besuchern erzeugt dies eine hohe Rate an Verbindungsaufbau und -abbau, was Overhead verursacht.

Die MySQL-Einstellung max_connections begrenzt die Anzahl gleichzeitiger Verbindungen. Wenn Ihrem Shop die Verbindungen ausgehen, sehen Besucher "Too many connections"-Fehler. Der Standardwert ist oft 151, was für Shops mit hohem Traffic und vielen PHP-FPM-Workern unzureichend sein kann.

Um den richtigen Wert zu bestimmen, prüfen Sie die Statusvariable Max_used_connections, die Ihnen die Spitzenanzahl gleichzeitiger Verbindungen seit dem MySQL-Start anzeigt. Setzen Sie max_connections auf mindestens 20 % über diesem Spitzenwert, um Spielraum bei Traffic-Spitzen zu haben.

Abfrageoptimierungstechniken

Neben der Indizierung können mehrere Optimierungen auf Abfrageebene die PrestaShop-Datenbankleistung verbessern:

SELECT * vermeiden: Abfragen, die alle Spalten selektieren, übertragen mehr Daten als nötig zwischen MySQL und PHP. PrestaShop-Kern verwendet manchmal SELECT * zur Vereinfachung, aber benutzerdefinierte Abfragen sollten nur die benötigten Spalten angeben.

Unterabfragen begrenzen: MySQLs Optimizer verarbeitet Unterabfragen in vielen Fällen weniger effizient als JOINs. Wenn Sie langsame Abfragen mit IN (SELECT ...)-Mustern sehen, verbessert das Umschreiben als JOINs oft die Leistung. Dies gilt besonders für von Modulen erzeugte Abfragen.

LIMIT weise einsetzen: Für paginierte Listen verwendet PrestaShop typischerweise LIMIT offset, count. Bei großen Offsets (wie Seite 500 einer Produktliste) wird dies langsam, da MySQL alle Zeilen bis zum Offset lesen und verwerfen muss. Ein effizienterer Ansatz ist die Keyset-Paginierung, bei der nach der zuletzt gesehenen ID gefiltert wird, statt einen Offset zu verwenden.

Batch-Operationen: Module, die Produkte in Schleifen verarbeiten, führen oft eine Abfrage pro Produkt aus. Das Umschreiben als Batch-Abfragen (unter Verwendung von IN-Klauseln oder CASE-Anweisungen für Updates) reduziert die Anzahl der Roundtrips zur Datenbank dramatisch.

Überwachung und laufende Optimierung

Datenbankoptimierung ist keine einmalige Aufgabe. Da Ihr Katalog wächst, sich Trafficmuster ändern und Sie neue Module installieren, tauchen neue langsame Abfragen auf. Etablieren Sie eine Routine zur Überwachung der Datenbankleistung.

Aktivieren Sie das Slow Query Log dauerhaft mit einem angemessenen Schwellenwert (0,5 bis 1 Sekunde). Überprüfen Sie das Log wöchentlich oder monatlich mit pt-query-digest. Achten Sie auf neue Abfragen, die im Log auftauchen, und auf bestehende Abfragen, deren Ausführungszeit im Laufe der Zeit zunimmt.

Überwachen Sie die wichtigsten MySQL-Leistungskennzahlen: die Bufferpool-Trefferquote (sollte über 99 % liegen), die Anzahl langsamer Abfragen pro Stunde, die durchschnittliche Abfragezeit und die Verbindungsauslastung. Diese Metriken geben Ihnen eine Frühwarnung vor Leistungsverschlechterungen, bevor sie die Nutzer beeinträchtigen.

Wenn Sie Module hinzufügen oder aktualisieren, prüfen Sie, ob sie neue langsame Abfragen einführen. Führen Sie die Funktionalität des Moduls aus, während Sie das Slow Query Log überwachen, um Probleme zu erfassen, bevor sie den Produktions-Traffic beeinträchtigen. Ein Modul, das bei einem Test-Shop mit 50 Produkten effiziente Abfragen erzeugt, kann bei einem Produktions-Shop mit 50.000 Produkten schwere Engpässe erzeugen. Testen mit Produktionsdaten in Produktionsgröße ist der einzig zuverlässige Weg, die Modulleistung zu überprüfen.

Zusammenfassung

Das MySQL Slow Query Log ist Ihr wertvollstes Werkzeug zum Finden und Beheben von Datenbankengpässen in PrestaShop. Aktivieren Sie es, setzen Sie einen angemessenen Schwellenwert und verwenden Sie Analysetools wie mysqldumpslow oder pt-query-digest, um die schlimmsten Übeltäter zu identifizieren. Verwenden Sie EXPLAIN, um zu verstehen, warum bestimmte Abfragen langsam sind, und wenden Sie gezielte Indizes an, um vollständige Tabellenscans zu eliminieren. Überwachen Sie Ihre Datenbankleistung kontinuierlich, denn Optimierung ist ein fortlaufender Prozess, da Ihr Shop wächst. Die Kombination aus Slow-Query-Log-Analyse, EXPLAIN-gesteuerter Optimierung und ordnungsgemäßer Indizierung kann einen trägen PrestaShop-Shop in einen verwandeln, der große Kataloge und hohen Traffic mit reaktionsschnellen Seitenaufrufen bewältigt.

Vollständige Antwort lesen

Wenn PrestaShop-Kombinationen die Performance toten: Grenzen und Losungen

Das PrestaShop-Kombinationssystem ermoglicht es, Produktvarianten zu erstellen - verschiedene Groessen, Farben, Materialien und andere Attribute. Es funktioniert perfekt fuer Produkte mit wenigen Varianten. Aber wenn Produkte Hunderte oder Tausende von Kombinationen haben, verschlechtert sich die Performance dramatisch. Produktseiten brauchen 10-30 Sekunden zum Laden, das Back Office wird unbrauchbar und Kategorielistenseiten kriechen.

Warum Kombinationen Performance-Probleme verursachen

Datenbankarchitektur

PrestaShop speichert Kombinationsdaten in mehreren Tabellen: ps_product_attribute (eine Zeile pro Kombination), ps_product_attribute_combination (Verknuepfung zu Attributwerten), ps_stock_available (Lagerbestand pro Kombination), ps_specific_price (Preisuebersteuerungen).

Ein Produkt mit 5 Groessen und 10 Farben erzeugt 50 Kombinationen mit ueber 350 Datenbankzeilen. Ein Produkt mit 3 Attributen (10 x 15 x 4) erzeugt 600 Kombinationen mit ueber 4.200 Zeilen.

Das exponentielle Wachstumsproblem

Attribute	Werte pro Attribut	Kombinationen	DB-Zeilen ca.
2	5 x 5	25	~175
2	10 x 10	100	~700
3	10 x 15 x 8	1.200	~8.400
4	10 x 15 x 8 x 5	6.000	~42.000

Auswirkungen auf das Front Office

Wenn ein Kunde eine Produktseite mit vielen Kombinationen besucht, muss PrestaShop alle Kombinationen abfragen, den Preis fuer jede berechnen, die Verfuegbarkeit pruefen und die JSON-Datenstruktur generieren. Bei 1.000+ Kombinationen kann dies 5-30 Sekunden dauern.

Praktische Grenzen

Anzahl	Front Office	Back Office	Bewertung
1-50	Schnell	Schnell	Keine Probleme
50-200	Akzeptabel	Akzeptabel	Handhabbar
200-500	Langsam (3-8s)	Langsam	Optimierung noetig
500-1000	Sehr langsam	Sehr langsam	Umstrukturierung erwaegen
1000+	Unbrauchbar	Oft Abstuerze	Umstrukturierung erforderlich

Loesung 1 - Produktkatalog umstrukturieren

Die effektivste Loesung: Reduktion der Kombinationen pro Produkt durch Aufteilung.

Produkte nach Hauptattribut aufteilen

Statt eines Produkts "T-Shirt" mit 50 Kombinationen erstellen Sie separate Produkte pro Farbe mit je 5 Groessen-Kombinationen. Schnelleres Frontend, besser fuer SEO.

Loesung 2 - Datenbank- und Server-Optimierung

Datenbankindizes hinzufuegen

ALTER TABLE ps_product_attribute 
  ADD INDEX idx_product_default (id_product, default_on);

ALTER TABLE ps_stock_available 
  ADD INDEX idx_product_attribute (id_product, id_product_attribute);

MySQL-Konfiguration

innodb_buffer_pool_size = 2G
query_cache_type = 1
query_cache_size = 128M

Loesung 3 - Lazy Loading von Kombinationen

Statt alle Kombinationen beim Seitenaufruf zu laden, nur die Daten fuer die ausgewaehlten Attribute per AJAX nachladen. Dies reduziert die initiale Ladezeit erheblich.

Loesung 4 - Caching-Strategien

Full-Page-Cache (Varnish, LiteSpeed) fuer Produktseiten implementieren. Redis oder Memcached statt dateibasiertem Caching nutzen.

Wann Kombinationen ganz vermeiden

Konfigurierbare Produkte mit 4+ Attributen - Produkt-Konfigurator-Modul nutzen
Dimensionale Produkte (Breite x Hoehe x Tiefe) - Spezielles Dimensionen-Modul nutzen
Print-on-Demand-Produkte - Produkt-Designer-Modul nutzen

Empfehlungen nach Kombinationsanzahl

Anzahl	Empfohlene Massnahme
Unter 100	Keine Aktion noetig
100-300	DB-Indizes, OPcache, Redis
300-1000	Produkte aufteilen, Indizes, Lazy Loading
Ueber 1000	Katalog umstrukturieren, Konfigurator-Modul

Vollständige Antwort lesen

PrestaShop Admin-Performance: Warum das Back Office langsam ist

Ein langsames PrestaShop-Back-Office ist eines der frustrierendsten Probleme fuer Shop-Administratoren. Dieser Leitfaden identifiziert die haeufigsten Ursachen und bietet konkrete Loesungen.

Die haeufigsten Ursachen

1. PrestaShop Addons API-Verbindung

Die Nummer-eins-Ursache. Das Back Office macht HTTP-Anfragen an addons.prestashop.com. Wenn diese API langsam ist, wartet Ihr gesamtes Back Office.

Loesung - Vom Addons-Konto abmelden oder API-Aufrufe deaktivieren.

2. Debug-Modus aktiviert

Deaktiviert alle Caches und kompiliert Templates bei jeder Anfrage neu.

define('_PS_MODE_DEV_', false);
define('_PS_DEBUG_PROFILING_', false);

3. Zu viele installierte Module

Jedes Modul fuegt Overhead hinzu. Deinstallieren Sie unbenutzte Module, besonders Statistik- und Gamification-Module.

4. Grosse Datenbank ohne Optimierung

DELETE FROM ps_cart WHERE id_cart NOT IN (
    SELECT id_cart FROM ps_orders
) AND date_add < DATE_SUB(NOW(), INTERVAL 30 DAY);

DELETE FROM ps_connections WHERE date_add < DATE_SUB(NOW(), INTERVAL 30 DAY);
OPTIMIZE TABLE ps_cart, ps_connections, ps_guest;

5. Shared-Hosting-Einschraenkungen

Empfehlung: VPS mit mindestens 2 CPU-Kernen, 4 GB RAM, SSD und PHP 8.1+.

6. OPcache nicht aktiviert

opcache.enable = 1
opcache.memory_consumption = 256
opcache.max_accelerated_files = 16229

7. Langsame Dashboard-Widgets

Dashboard vereinfachen. Nicht benoetigte Widgets entfernen. Datumsbereiche einschraenken.

8. Grosser Produktkatalog

Produkte pro Seite auf 20-50 reduzieren. Suchfunktion statt Blaettern nutzen.

Optimierungscheckliste

Debug-Modus deaktivieren
Template-Kompilierung auf "Nie neu kompilieren" setzen
Caching aktivieren (Redis bevorzugt)
OPcache aktivieren
Von Addons API trennen
Unbenutzte Module deinstallieren
Datenbank-Bloat bereinigen
Dashboard vereinfachen
Auf VPS/Dedicated upgraden
PHP 8.1+ verwenden

Vollständige Antwort lesen

Cookie	Anbieter	Zweck	Dauer
PrestaShop-*	PrestaShop	Sitzungsverwaltung und Warenkorb-Funktionalität	Sitzung
PHPSESSID	PHP	PHP-Sitzungskennung	Sitzung
mprcr_consent	MPR Cookies Revolution	Speichert Cookie-Einwilligungseinstellungen	365 Tag(e)
mprcr_version	MPR Cookies Revolution	Verfolgt die Version der Einwilligungskonfiguration	365 Tag(e)

Cookie	Anbieter	Zweck	Dauer
TawkConnectionTime	Tawk.to	Verfolgt die Verbindungszeit der Chat-Sitzung	Sitzung
__tawkuuid	Tawk.to	Identifiziert wiederkehrende Chat-Besucher	6 Monat(e)

Fehlerbehebung

Das Problem: Sie brauchen das Modul, aber nicht seine Assets auf jeder Seite

Methode 1: Theme.yml verwenden, um Modul-Assets zu entfernen

Methode 2: Media::unregisterStylesheet und Media::unregisterJavascript

Methode 3: Benutzerdefiniertes Modul zum Blockieren bestimmter Assets

Methode 4: Der Hook-Abhänge-Ansatz

Methode 5: Modul-Assets über Ihr Theme überschreiben

PrestaShop 1.7 vs. 8.x: Unterschiede im Ansatz

Leistungsgewinne nach dem Deaktivieren von Assets messen

Risiken und Kompatibilitätsbedenken

Ein praktischer Workflow für sichere Asset-Entfernung

PHP memory_limit verstehen

So pruefen Sie Ihr aktuelles Memory Limit

Aus dem PrestaShop Back Office

Mittels phpinfo()

Ueber die Kommandozeile

Haeufige Ursachen fuer Memory-Limit-Fehler

Grosse Produktimporte

Produkte mit vielen Kombinationen

Aufgeblaehte oder schlecht programmierte Module

Grosse Kataloge und komplexe Abfragen

Smarty-Template-Kompilierung

So erhoehen Sie das Memory Limit

Methode 1: php.ini

Methode 2: .htaccess (nur Apache mit mod_php)

Methode 3: .user.ini (PHP-FPM)

Methode 4: Im PrestaShop-Code

Methode 5: Pool-spezifische Konfiguration (PHP-FPM)

Pro-Prozess- vs. gemeinsamer Speicher

Speicherlecks und uebermassige Nutzung diagnostizieren

PrestaShop Debug-Modus aktivieren

Speichernutzung im Code ueberwachen

Xdebug-Profiling verwenden

Langsame Abfragen und MySQL pruefen

OPcache-Speicher

MySQL-Speicherkonfiguration

Wann Sie Ihr Hosting upgraden sollten

Kurzreferenz: Empfohlene Einstellungen nach Shopgroesse

max_input_vars in PrestaShop verstehen

Warum PrestaShop hohe max_input_vars-Werte benoetigt

Symptome eines zu niedrigen max_input_vars

So pruefen Sie Ihren aktuellen max_input_vars-Wert

Den benoetigten max_input_vars-Wert berechnen

So erhoehen Sie max_input_vars

Methode 1: php.ini (Empfohlen)

Methode 2: .htaccess (Apache mit mod_php oder mod_fcgid)

Methode 3: .user.ini (PHP-FPM / CGI)

Methode 4: Hosting-Kontrollpanel

Die Suhosin-Patch-Komplikation

Alternative Ansaetze fuer Produkte mit 500+ Kombinationen

Kombinationen per CSV importieren

PrestaShop Webservice API verwenden

Grosse Produkte aufteilen

Kombinationen in Stapeln verwalten

Die Loesung ueberpruefen

Verwandte PHP-Einstellungen zum Ueberpruefen

PrestaShop-versionsspezifische Hinweise

Zukuenftigen Problemen vorbeugen

Warum nach PrestaShop-Updates weisse Seiten auftreten

Schritt 1: Debug-Modus aktivieren

Schritt 2: Fehlerprotokolle pruefen

Haeufige Ursache 1: Inkompatible Module

Haeufige Ursache 2: PHP-Versionsinkompatibilitaet

Haeufige Ursache 3: Override-Konflikte

Haeufige Ursache 4: Cache und kompilierte Dateien

Haeufige Ursache 5: Fehlgeschlagene Datenbankmigrationen

Schritt-fuer-Schritt-Wiederherstellungsverfahren

Sicheres Update-Verfahren fuer zukuenftige Updates

Rollback-Strategien

Die Bedeutung von Datenbank-Backups

Wann professionelle Hilfe gesucht werden sollte

Wie Warenkorb-Aktualisierungen in PrestaShop funktionieren

Symptom: Klick auf "In den Warenkorb" bewirkt nichts

Symptom: Warenkorb-Button dreht sich, aber wird nie fertig

Symptom: Warenkorb aktualisiert sich, zeigt aber falsche Daten

Browser-Cache-Probleme

Smarty-Cache-Konflikte

CCC-Einstellungen und ihre Auswirkungen

CDN-Cache-Probleme

Cookie- und Session-Probleme