PrestaShop-Fehlersuche: Leere Seiten, Fehler und Wiederherstellung

So würden wir vorgehen

Wir würden den Wiederherstellungsweg anhand Ihres tatsächlich betriebenen Shops wählen: genaue PrestaShop- und PHP-Versionen, Module, Theme-Overrides, Katalog- und Bestelldaten, Integrationen und Hosting. Auch Sprachen, Währungen, Kundengruppen und die Zugriffsrechte Ihres Teams bestimmen, was sich reproduzieren und sicher ändern lässt. Ein Modulfehler braucht den Modulbetreuer, ein Installations- oder Konfigurationsproblem eine geprüfte Einrichtung und ein Serverausfall den Hoster oder Infrastrukturverantwortlichen.

Verwenden Sie für Änderungen an Code, Modulen, Theme oder Laufzeit eine private Staging-Kopie mit der relevanten Live-Konfiguration, getrennt von echten Zahlungen, Kunden-E-Mails und Exporten zur Auftragsabwicklung. Reproduzieren Sie den Fehler, erproben Sie eine rückgängig zu machende Korrektur und vereinbaren Sie die zur Wiederöffnung erforderlichen Nachweise. Übernehmen Sie die getestete Änderung in einem geplanten Live-Zeitfenster, mit gesicherten Einstellungen, zusammenpassenden Paketen und einer benannten Person, die sie rückgängig machen kann. Ist eine sofortige Eindämmung nötig, sichern Sie zuerst den betroffenen Ablauf ab und begrenzen Sie die Diagnoseänderungen eng.

Für die vereinbarte Installation und Konfiguration eines bestehenden Moduls umfasst der PrestaShop Module Installation & Configuration Service dessen Einstellungen und die Prüfung des Ablaufs. Lizenzen und Entwicklung sind separate Leistungen; der Service dient nicht der allgemeinen Wiederherstellung in Notfällen.

Wählen Sie den ersten Ansatz

Entdecken Sie ein unerklärliches Administratorkonto, ein geändertes Zahlungsziel oder eine unerwartete ausführbare Datei, sichern Sie die Belege und ziehen Sie die für Sicherheitsvorfälle zuständige Person hinzu. Die übliche Eingrenzung durch Isolieren von Modulen reicht nicht aus, um eine sichere Wiederöffnung des Shops zu bestätigen.

Den Fehler erfassen und den aktuellen Zustand sichern

1. Stoppen Sie Installationen, Updates und Importe ohne Bezug zum Fehler sowie wiederholtes Cache-Leeren.
2. Notieren Sie genaue Uhrzeit, Zeitzone, URL oder Admin-Aktion, HTTP-Status, Antworttext und Browserfehler. Halten Sie fest, wer betroffen ist.
3. Listen Sie die letzten Änderungen an Core, Modulen, Theme, PHP, Hosting, Proxy-Regeln oder geplanten Jobs auf.
4. Sichern Sie Protokolle und erstellen Sie vor Wiederherstellungsänderungen eine Datei- und Datenbanksicherung. Bewahren Sie eine Sicherung aus der Zeit vor dem Vorfall separat auf.
5. Beschränken Sie öffentlichen Traffic oder nutzen Sie den Wartungsmodus, wenn der Fehler Checkout, Datenintegrität oder öffentliche Fehlerausgaben betrifft.
6. Reproduzieren Sie den Fehler nach Möglichkeit auf Staging, grenzen Sie eine Ursache ein, testen Sie und dokumentieren Sie das Ergebnis.

Eine leere Antwort ist ein Symptom, kein Beweis für einen fatalen PHP-Fehler. Auch eine leere Ausgabe, ein vorzeitiger Abbruch, eine Proxy-Antwort oder ein Fehler eines vorgelagerten Dienstes kann dazu führen. Prüfen Sie den tatsächlichen Status und Antwortinhalt in den Browser-Entwicklerwerkzeugen. Bei einem „AJAX-Fehler“ benötigen Sie die fehlgeschlagene Netzwerkanfrage und ihre Antwort, nicht nur die Meldung der Oberfläche.

Prüfen Sie nach jeder wesentlichen Korrektur Startseite, Kategorie, Produkt, Warenkorb, Checkout und Admin-Anmeldung. Nutzen Sie auf Staging den Sandbox-Modus des Zahlungsanbieters und prüfen Sie Bestellsummen, Bestand und Bestätigungsausgaben. Bestätigen Sie vor der Wiederöffnung des Live-Checkouts die Produktionszugangsdaten, den Anbietermodus und den Callback-Endpunkt und vereinbaren Sie gegebenenfalls eine kontrollierte Live-Zahlungsprüfung. Testen Sie auch die ursprünglich fehlgeschlagene Aktion.

Das richtige Protokoll finden und den gesamten Fehler lesen

Erweiterte Einstellungen > Logs enthält Ereignisse, die der Datenbanklogger von PrestaShop unter Berücksichtigung des Schweregradfilters erfasst. Es ist kein vollständiges Protokoll von PHP-, Symfony- oder Bootstrap-Fehlern.

Ändern Sie var/logs/ nicht allein deshalb in var/log/, weil der Shop PrestaShop 8 oder 9 verwendet. Gehen Sie nicht davon aus, dass jede Umgebung exakt prod.log oder dev.log nutzt. Auch eine CLI-PHP-Konfiguration kann auf ein anderes Protokoll als Web-PHP verweisen.

# From the shop root, inspect available application logs.
ls -lt var/logs/
# Follow the configured file after confirming its name.
tail -n 100 -f var/logs/prod.log

Ordnen Sie Einträge anhand von Anfragezeit, Umgebung und gegebenenfalls Anfragekennung zu. Lesen Sie Ausnahmemeldung, Datei, Zeile und relevante Stack-Frames. Ein Frame in einem Modul oder Theme ist ein Hinweis, kein Beweis für die eigentliche Ursache. Fehlerhafte Eingaben oder eine vorgelagerte Abhängigkeit können dort zum Fehler führen.

Wenn kein passender Fehler erscheint, prüfen Sie Protokollierungskonfiguration, Schreibzugriff, Rotation und freien Speicherplatz. PHP-Fehleranzeige und Protokollierung lassen sich separat konfigurieren. Eine unterdrückte Ausgabe garantiert daher keinen geschriebenen Protokolleintrag. Schwärzen Sie Zugangsdaten, Tokens und personenbezogene Daten, bevor Sie Protokolle weitergeben.

Befunde aus Browser, Proxy und Anwendung zusammenführen

Behandeln Sie jede Weiterleitung und Hintergrundanfrage als separate Anfrage. Eine funktionierende Produktseite kann dennoch eine fehlschlagende Bestands-, Warenkorb- oder Konfigurationsanfrage enthalten. Liefert die Infrastruktur bereits eine Anfragekennung, übernehmen Sie diese in den Supportbericht. Andernfalls verwenden Sie Zeitstempel, Methode und genauen Pfad, um die Einträge zuzuordnen. Berücksichtigen Sie unterschiedliche Protokollzeitzonen und verzögerte Jobs, die erst nach der Browserantwort laufen.

Verzeichnet die Edge-Schicht einen Fehler, aber der Ursprungsserver keine passende Anfrage, prüfen Sie den Proxy- oder Hosting-Pfad, bevor Sie PHP bearbeiten. Protokolliert der Ursprungsserver eine erfolgreiche Antwort, während der Browser andere Inhalte erhält, untersuchen Sie zwischengeschaltetes Caching oder das Umschreiben von Antworten. Keine dieser Beobachtungen identifiziert für sich allein die fehlerhafte Komponente.

Debug-Modus und Profiling für unterschiedliche Aufgaben nutzen

Verwenden Sie, soweit verfügbar, Erweiterte Einstellungen > Leistung > Debug-Modus. Der Core-Schalter ist _PS_MODE_DEV_ in config/defines.inc.php. Ändern Sie für eine geschützte Diagnosesitzung seine bestehende Deklaration und setzen Sie sie anschließend zurück:

define('_PS_MODE_DEV_', true);
// Restore production mode after collecting the error:
define('_PS_MODE_DEV_', false);

Das sind alternative Zustände, keine zwei Deklarationen zum gemeinsamen Einfügen. Der Debug-Modus beeinflusst Fehleranzeige und Auswahl der Anwendungsumgebung. Er deaktiviert nicht grundsätzlich das Smarty-Caching. Die Standard-Debug-Maske schließt kompatibilitätsbezogene Warnungen zu veralteten Funktionen aus, sofern die Einstellung für Kompatibilitätswarnungen nicht aktiviert ist.

Verwenden Sie die PrestaShop-Steuerung, statt anzunehmen, dass allgemeine Variablen wie APP_ENV oder APP_DEBUG sie ersetzen. Der Anwendungskernel verwendet die Umgebungs- und Debug-Konstanten von PrestaShop. ini_set()-Aufrufe zur Laufzeit umgehen keine spätere Core-Konfiguration und können keinen Parse-Fehler sichtbar machen, der die Ausführung desselben Einstiegsskripts verhindert. Diagnostizieren Sie Startfehler über PHP-/Serverkonfiguration und Protokolle.

Der Symfony-Profiler ist nur bei entsprechender Konfiguration für geeignete Symfony-Anfragen verfügbar. Er wird nicht automatisch an jede Shop-, Legacy-, AJAX- oder fehlgeschlagene Anfrage angehängt. Der separate bisherige Profiler für Laufzeiten und Abfragen nutzt _PS_DEBUG_PROFILING_ in config/defines.inc.php. Aktivieren Sie Profiling kurzzeitig auf geschütztem Staging und vergleichen Sie repräsentative Anfragen.

Öffentliche Debug-Ausgaben können Pfade, SQL, Tokens und sensible Konfiguration offenlegen. Schalten Sie sie ab, sobald Sie den Fehler erfasst haben. Bevorzugen Sie bei Zahlungs-Callbacks die Serverprotokollierung gegenüber der Anzeige von Ausnahmen.

Performance Revolution kann nach der Authentifizierung eines Backoffice-Mitarbeiters ein Mitarbeiter-Debug-Cookie ausstellen. Sein früher Bootstrap akzeptiert den Besitz dieses Tokens; die erneuerte vierstündige Browser-Gültigkeit ist keine serverseitige Sitzungs- oder Inaktivitätsprüfung. Behandeln Sie es wie Zugangsdaten für den Debug-Zugriff und nutzen Sie die Modulhilfeseite für Einrichtung und Widerruf.

Leere Seiten und HTTP-Fehler anhand des Status diagnostizieren

Verwenden Sie Syntaxprüfungen für kürzlich bearbeitete PHP-Dateien. Zum Beispiel:

php -l config/defines.inc.php
php -v
php --ini

Verwenden Sie die für den Shop vorgesehene PHP-Binärdatei. Ein erfolgreicher CLI-Test belegt nicht, dass die Web-Laufzeit dieselbe Version, Erweiterungen, Berechtigungen oder Konfiguration hat.

Umschreibungen und .htaccess

Prüfen Sie bei Apache die genaue fehlerhafte Anweisung und ob der virtuelle Host die erforderlichen Rewrite-Regeln erlaubt. Nicht unterstützte Anweisungen wie Options oder php_value können Fehler auslösen. Nginx liest .htaccess nicht; prüfen Sie dort stattdessen die Serverkonfiguration.

Bewahren Sie vor Änderungen an .htaccess eine Kopie auf. Wenn Sie die Datei vorübergehend aus dem Zugriff nehmen, tun Sie dies unter kontrolliertem Zugang, da sie auch Sicherheitsregeln enthalten kann. Das Speichern von URLs einrichten unter Shop-Einstellungen > Traffic & SEO erzeugt .htaccess neu, sofern die Berechtigungen dies zulassen. Die Erstellung von robots.txt ist eine separate Aktion.

Prüfen Sie Eigentümer und tatsächlichen PHP-Ausführungsbenutzer, bevor Sie Berechtigungen ändern. Gewähren Sie nur die verzeichnisspezifischen Schreibrechte, die der Shop benötigt, einschließlich relevanter Caches, Protokolle, Bilder, Uploads oder modulgenerierter Dateien. Ein allgemeines rekursives chmod-Rezept kann nötigen Zugriff entfernen oder Dateien offenlegen.

Modulkonflikte und fehlende Shop-Ausgaben eingrenzen

Testen Sie auf Staging zuerst die jüngste Änderung. Wenn mehrere Module interagieren, vergleichen Sie beide aktiviert, jedes einzeln und keines. Grenzen Sie bei größeren Mengen kontrollierte Gruppen ein und testen Sie Abhängigkeiten erneut. Das zuletzt aktivierte Modul kann eine Wechselwirkung sichtbar machen, ohne allein verantwortlich zu sein.

Bevorzugen Sie die Aktion Deaktivieren im Modulmanager. Eine funktionierende Konsole kann den unterstützten Modulbefehl verwenden. Prüfen Sie die Hilfe, bevor Sie den technischen Modulnamen und Shop-Kontext auswählen:

php bin/console help prestashop:module

Der Befehl unterstützt unter anderem disable, enable, install, upgrade und uninstall. Diese Aktionen haben unterschiedliche Auswirkungen. Nur module.active per SQL zu ändern, bildet die normale Deaktivierung nicht nach, die auch Shop-Zuordnungen und Modulverhalten behandelt. Vermeiden Sie eine pauschale Aktualisierung sämtlicher Drittanbieter-Moduldatensätze.

Wenn weder Admin noch Konsole starten, kann das vorübergehende Verschieben des verdächtigen Modulverzeichnisses aus dem Modul-Suchpfad die Dateien isolieren. Dokumentieren Sie den genauen ursprünglichen Ort, bewahren Sie das Verzeichnis nicht öffentlich zugänglich auf und planen Sie die Wiederherstellung. Das entfernt keine installierten Overrides, macht keine Migrationen rückgängig und garantiert keine Wiederherstellung bei Referenzen in kompilierten Diensten.

Verwenden Sie zur Override-Diagnose Alle Overrides deaktivieren unter Leistung, gesteuert durch PS_DISABLE_OVERRIDES, und erzeugen Sie den Klassenindex neu. _PS_ALLOW_OVERRIDES_ und _PS_DISABLE_OVERRIDES_ sind nicht die richtigen Schalter. Auch beim manuellen Verschieben eines Verzeichnisses muss der Index berücksichtigt werden.

Der Core kann unterschiedliche Override-Methoden in einer Klasse kombinieren. Überschneidende Methoden oder Eigenschaften können jedoch ausdrücklich zu Konflikten führen. Koordinieren Sie einen Kompatibilitätspatch mit einem Verantwortlichen und einem Installations-/Updateplan. Gehen Sie nicht davon aus, dass das Zusammenkopieren zweier Implementierungen beiden Installationsroutinen zum Erfolg verhilft.

Wenn ein installiertes Anzeigemodul nichts ausgibt, prüfen Sie Konfiguration, aktiven Shop, Seiten-/Produktgeltungsbereich und ob das Theme einen unterstützten Hook ausgibt. Prüfen Sie unter Design > Positionen unterstützte Platzierungen und Reihenfolge. Versetzen Sie ein Modul nicht in einen beliebigen Hook, den es nicht implementiert. Untersuchen Sie anschließend Template-Kopien, Browserfehler und Caches.

Einen Defekt von unvollständiger Konfiguration unterscheiden

Vergleichen Sie die fehlerhafte Einrichtung mit der Anleitung der installierten Version: erforderliche Kontoeinstellungen, Shop-Zuordnungen, Hooks und abgeschlossene Migrationen. Vom Anbieter abgelehnte API-Zugangsdaten sind ein anderer Supportfall als eine Ausnahme bei gültigen Zugangsdaten. Liefern Sie dem Betreuer eine minimale Reproduktion mit einer unterstützten Konfiguration und dokumentieren Sie eigenen Code, der zum Auslösen erforderlich ist. Eine Neuinstallation oder Deinstallation als Diagnoseabkürzung kann Konfiguration oder Daten entfernen und diesen Vergleich erschweren.

Den zur Änderung passenden Cache leeren und Autoloading prüfen

Die Backoffice-Aktion Cache leeren ruft eine umfassendere Kette zur Cache-Bereinigung auf, nicht nur Smarty. Sie garantiert dennoch nicht das Leeren sämtlicher Hosting-, Proxy-, Modul- oder Browser-Caches.

Bevorzugen Sie die Backoffice-Aktion oder eine abgestimmte Konsolenbereinigung aus dem Shop-Stammverzeichnis:

php bin/console cache:clear --env=prod

Verwenden Sie die richtige PHP-Binärdatei und den richtigen Dateisystemeigentümer. Wenn ein defekter Bootstrap eine Wiederherstellung über das Dateisystem erfordert, stoppen Sie eingehenden Traffic und Worker, sichern Sie Protokolle, bestätigen Sie die genauen Pfade generierter Caches und bauen Sie sie mit korrekten Eigentumsrechten neu auf. Cache-Löschung ist unter PrestaShop 9 nicht grundsätzlich verboten; unkoordinierte Anfragen und fehlgeschlagene Neuaufbauten verursachen das Risiko. Löschen Sie keine Anwendungsdateien oder undokumentierten Moduldaten als „Cache“.

Ein CLI-opcache_reset() setzt keinen unabhängigen Web-OPcache-Pool zurück. Verwenden Sie je nach Bedarf das kontrollierte FPM- oder Apache-Neulade-/Invalidierungsverfahren Ihres Hosters. Lassen Sie keinen öffentlichen Reset-Endpunkt im Shop zurück.

Klasse oder Namensraum nicht gefunden

1. Notieren Sie die genaue fehlende Klasse und den erwarteten Namensraum.
2. Prüfen Sie, dass das vollständige Release-Paket vorhanden ist, einschließlich vendor/autoload.php des Moduls und mitgelieferter Abhängigkeitsdateien.
3. Prüfen Sie auf einem Dateisystem, das Groß- und Kleinschreibung unterscheidet, die Schreibweise von Dateinamen und Namensraum sowie den Lesezugriff und die PHP-Anforderungen des Pakets.
4. Stellen Sie ein sauberes Paket wieder her, statt Dateien verschiedener Releases zu mischen. Sichern Sie dokumentierte Uploads oder Exporte separat.
5. Bauen Sie den relevanten Container und Klassenindex neu auf und stimmen Sie anschließend den Web-OPcache ab.

Führen Sie die Composer-Autoload-Erzeugung nur im passenden Quellcode-/Bereitstellungsablauf mit den richtigen Abhängigkeiten und der richtigen Lockdatei aus. Sie stellt keine fehlenden Bibliotheken wieder her. Der Neuaufbau des Klassenindex behebt keine fehlende Composer-Abhängigkeit mit Namensraum. Löschen Sie keine Modul- oder Hook-Datenbankzeilen allein deshalb, weil eine Klasse fehlt.

Speichererschöpfung und unvollständiges Speichern von Formularen beheben

Allowed memory size exhausted bedeutet, dass eine Anfrage ihr wirksames PHP-Speicherlimit überschritten hat. Die Stelle der letzten Speicheranforderung beim fatalen Fehler ist nicht automatisch die Ursache des Wachstums. Große Importe, Bildabmessungen, variantenreiche Formulare, vollständiges Einlesen von Tabellen, Rekursion und das Protokollieren großer Objekte können dazu beitragen.

Prüfen Sie den Web-Wert unter Informationen, soweit angezeigt, und in der aktiven FPM-Konfiguration. Schätzen Sie verfügbaren RAM und gleichzeitige Worker ab, bevor Sie Limits erhöhen. Beispielsweise kann memory_limit = 512M für eine bestimmte Arbeitslast geeignet sein. Es ist aber weder eine garantierte Lösung noch ein Wert, den jede Seite benötigen muss.

Teilen Sie übergroße Importe in kontrollierte Chargen auf, verarbeiten Sie Bilder separat, soweit unterstützt, und untersuchen Sie unbegrenzte Ergebnismengen per Profiling. Ein wiederkehrender Fehler beweist kein Speicherleck. Lassen Sie erforderliche Integrationen aktiv, solange Sie die Folgen ihrer Deaktivierung nicht getestet haben.

Einstellungen oder Produkte werden nur teilweise gespeichert

1. Öffnen Sie Konsole und Netzwerkansicht des Browsers. Prüfen Sie, ob eine POST-Anfrage gesendet wurde, sowie deren Größe, Antwort und Weiterleitung.
2. Öffnen Sie die Konfigurationsseite über einen neuen Admin-Link erneut, um einen aktuellen Token zu erhalten. Schließen Sie das Backoffice vom öffentlichen Caching aus.
3. Prüfen Sie die Konfigurationsberechtigungen des Mitarbeiters und den aktuellen Shop-Kontext.
4. Prüfen Sie PHP-Eingabe-/Body-Limits und etwaige Proxy- oder Webserver-Limits.
5. Prüfen Sie eine passende WAF-Regel, statt die Firewall umfassend abzuschalten.
6. Untersuchen Sie erforderliche Modultabellen, abgeschlossene Migrationen und dokumentierte beschreibbare Pfade.

max_input_vars begrenzt die eingelesenen Eingabevariablen. Eine Überschreitung schneidet Eingaben ab und erzeugt E_WARNING; diese Warnung erscheint möglicherweise nicht im Backoffice. Viele Varianten und Sprachen können ein großes Formular erzeugen, beweisen aber nicht, dass dieses Limit die Ursache ist. Ermitteln Sie den wirksamen Web-Wert über die Hosting-Konfiguration oder eine geschützte Diagnose; nicht jede Informationsseite zeigt ihn an.

Konfigurieren Sie das Limit vor dem Einlesen der Anfrage. Es innerhalb der Formularverarbeitung zu erhöhen, ist zu spät. Ein anhand einer Messung gewähltes Beispiel für ein großes Formular könnte sein:

max_input_vars = 5000
post_max_size = 64M
upload_max_filesize = 48M
max_execution_time = 300
memory_limit = 512M

Das sind Beispiellimits, keine allgemeingültigen Anforderungen. Halten Sie die POST-Kapazität oberhalb eines erlaubten Uploads zuzüglich Zusatzdaten und planen Sie Zeit für Entpacken oder Verarbeitung ein. Verwenden Sie php.ini, eine unterstützte .user.ini, FPM-Konfiguration oder Ihr Hosting-Panel. Apache-mod_php-Anweisungen sind keine allgemeine FPM-Lösung. Bestätigen Sie die wirksamen Werte nach dem Neuladen durch den Hoster oder nach Ablauf der Konfigurationscache-Verzögerung.

Erwägen Sie für sehr große Variantenmengen den integrierten CSV-Import oder den Webservice als Alternativen zu einem riesigen Formular. Ihre Parsing- und Ressourcenbeschränkungen unterscheiden sich; Upload-, Body-, Laufzeit- und Speicherlimits gelten weiterhin. Siehe PHP-Dokumentation zu Eingabelimits.

Praxisbeispiel: Ein umfangreiches Produkt verliert übersetzte Felder

Angenommen, ein kleines Produkt lässt sich speichern, doch ein Produkt mit vielen Varianten und Sprachen verliert beim erneuten Öffnen Werte. Dieses Muster deutet auf eine Grenze bei Größe oder Feldanzahl hin. Die Anfragebefunde müssen es jedoch von Anwendungsvalidierung, einer abgelehnten Anfrage oder einem späteren Schreibvorgang unterscheiden.

1. Sichern Sie eine Kopie der vorgesehenen Werte und reproduzieren Sie den Fehler mit demselben Produkt auf Staging. Vergleichen Sie eine erfolgreiche kleine Übermittlung mit der fehlgeschlagenen.
2. Prüfen Sie, ob die fehlenden Felder in den vom Browser gesendeten Nutzdaten enthalten waren. Falls nicht, untersuchen Sie Formular und JavaScript, bevor Sie Serverlimits erhöhen.
3. Wurden die Felder gesendet, prüfen Sie Content-Type, Antwort und passende PHP-Warnungen oder Anwendungsfehler der Anfrage. PHPs max_input_vars begrenzt automatisch eingelesene Formularvariablen, nicht Schlüssel, die Anwendungscode aus einem JSON-Body dekodiert. Testen Sie anhand der wirksamen Web-Konfiguration genau das Eingabe- oder Body-Limit, auf das die Befunde hindeuten.
4. Öffnen Sie das Produkt nach der Änderung erneut im selben Shop und derselben Sprache und danach in einer weiteren betroffenen Sprache. Bestätigen Sie, dass vorhandene Varianten und nicht betroffene Felder erhalten geblieben sind.

Werden Werte korrekt gespeichert und später zurückgesetzt, gleichen Sie den späteren Schreibvorgang mit Importen, geplanter Synchronisierung und Änderungen anderer Mitarbeiter ab. Ein höheres Parsing-Limit verhindert nicht, dass eine Integration zuvor erfolgreich gespeicherte Werte überschreibt.

PHP auf die genaue PrestaShop-Version abstimmen

Prüfen Sie Web- und CLI-PHP separat. Bestätigen Sie erforderliche Erweiterungen und jedes wichtige Modul, jede Abhängigkeit, jedes Theme und jeden Override, bevor Sie die Laufzeit ändern. Syntaxprüfung ist nützlich, kann aber keine Laufzeitkompatibilität beweisen.

Diese Anwendungskompatibilitätsbereiche besagen nicht, dass alte PHP-Zweige weiterhin Sicherheitsunterstützung erhalten. Konsultieren Sie die historische Matrix, die PrestaShop-8-Matrix und die PrestaShop-9-Matrix für Ihre genaue Version. Prüfen Sie die eigenen Anforderungen und Abhängigkeiten von 9.2, statt anzunehmen, ein älterer 9.x-Test decke sie ab.

Lesen Sie bei PHP-Fehlern die genaue Funktion und Version nach. Im Modus mit Typumwandlung ist die Übergabe von null an einen nicht nullfähigen skalaren Parameter vieler interner Funktionen seit PHP 8.1 veraltet. Strikte Typisierung und andere Argumentfehler verhalten sich anders. Siehe den umgesetzten PHP-RFC. Das Erzeugen dynamischer Eigenschaften wurde in PHP 8.2 mit Ausnahmen als veraltet eingestuft. Warnungen zu veralteten Funktionen führen nicht grundsätzlich in der nächsten Version zu fatalen Fehlern; aktualisieren Sie den Code nach dem Migrationszeitplan der jeweiligen Funktion.

Datenbankfehler und fehlgeschlagene Core-Updates untersuchen

Sichern Sie nach einem fehlgeschlagenen Update den Bericht und die Protokolle des Update Assistant. Bestätigen Sie genaue Ausgangs- und Zielversion, Vollständigkeit der Dateien, Abhängigkeiten, PHP-Laufzeit und Migrationsstand. Gehen Sie nicht davon aus, dass ein Austausch der Dateien das Datenbank-Upgrade abgeschlossen hat.

Untersuchen Sie bei „Unknown column“ die tatsächliche Tabellendefinition und die Migration, die sie hätte erzeugen sollen. Vergleichen Sie mit einer sauberen Installation derselben Zielversion und berücksichtigen Sie dabei Präfix, Module und Shop-Historie. Fügen Sie keine geratene ALTER-Anweisung ein und nehmen Sie nicht an, dass ein historisches Verzeichnis install-dev/upgrade/sql/ die aktuelle Migrationsquelle ist.

SHOW CREATE TABLE ps_product;
SHOW FULL PROCESSLIST;
SHOW ENGINE INNODB STATUS;

Das sind Diagnosebeispiele mit ps_; verwenden Sie Ihr tatsächliches Präfix und geeignete Datenbankberechtigungen. Identifizieren Sie die blockierende Transaktion, den Aufrufer und den Geschäftsvorgang, bevor Sie eine Abfrage abbrechen. Schemaänderungen und große Neuaufbauten können den Shop sperren oder belasten und benötigen ein geplantes Zeitfenster.

„Duplicate entry for key“ bedeutet, dass eine Eindeutigkeitsbedingung verletzt wurde. Ermitteln Sie den genannten Index und den tatsächlichen Wert. Gehen Sie weder davon aus, dass Artikelreferenzen eindeutig sind, noch dass ein erneuter Installationslauf eine teilweise abgeschlossene Migration repariert.

Sichern Sie bei Verdacht auf Beschädigung die Backups und untersuchen Sie die Fehlerprotokolle der Speicher-Engine. MyISAM-Reparaturbefehle sind keine allgemeinen InnoDB-Wiederherstellungsbefehle. Ein Tabellenneuaufbau mit ALTER TABLE ... ENGINE=InnoDB ist keine verlässliche Abhilfe bei physischer Beschädigung. Nutzen Sie ein engine-spezifisches Verfahren zur Wiederherstellung und zum Export/Wiederimport. Die MySQL-Anleitung zur InnoDB-Wiederherstellung beschreibt die Notfallsteuerung.

Wenn Code und Schema nach dem Update nicht sicher in Einklang gebracht werden können, stellen Sie unter kontrolliertem Zugang zusammenpassende Dateien und Datenbank aus dem Backup vor dem Update wieder her. Berücksichtigen Sie Bestellungen, Zahlungen und Bestandsänderungen seit diesem Backup, bevor Sie den Live-Zustand überschreiben.

Templates, Child-Themes und fehlende Assets prüfen

Wenn ein Template nicht geladen werden kann, prüfen Sie den angeforderten Modulpfad, das mitgelieferte Template des Moduls und eine eventuelle Theme-Kopie unter themes/your-theme/modules/. Template-Overrides im Theme können ein neueres Modul-Template verdecken. Unter Linux zählt die Groß-/Kleinschreibung von Dateien und Verzeichnissen.

Prüfen Sie bei Smarty-Kompilierungsfehlern das genannte Quelltemplate, korrekt gepaarte {if}- und {foreach}-Blöcke sowie mögliche kollidierende Trennzeichen. Nicht jedes JavaScript-Objektliteral benötigt einen Literalblock: Smarty 3 behandelt in den dokumentierten Fällen Trennzeichen, die von Leerraum umgeben sind. Verwenden Sie Maskierung oder {literal} nur bei Bedarf und beachten Sie, dass Template-Ausdrücke innerhalb eines Literalblocks nicht ausgewertet werden. Siehe Smarty-Dokumentation.

Prüfen Sie Kodierung und unbeabsichtigte Ausgabe, einschließlich einer BOM, ohne anzunehmen, dass jede BOM einen Compilerfehler verursacht. Untersuchen Sie bei Asset-Fehlern tatsächliche Netzwerk-URL, Status, Antworttyp und Konsolenmeldung. Prüfen Sie Theme-Konfiguration, registrierte Assets, CCC-Ausgabe, Versionskennzeichnung bei der Bereitstellung und den CDN-Ursprungspfad.

Ein Child-Theme benötigt sein Parent-Theme und eine kompatible Konfiguration. Vergleichen Sie überschriebene Templates mit der aktualisierten Parent- oder Modulversion. Auf Staging kann ein bekanntermaßen kompatibles Standard-Theme helfen, das Problem einzugrenzen. Ein Theme-Wechsel ist jedoch eine echte Konfigurationsänderung und sollte protokolliert und nach dem Test rückgängig gemacht werden.

Siehe Child-Themes für den Wartungsablauf.

Anmeldeschleifen, Token-Probleme und verlorene Warenkörbe lösen

Prüfen Sie in den Browserwerkzeugen unter Speicher oder Anwendung Cookie-Domain, Pfad, Secure, HttpOnly, SameSite und Größe. Untersuchen Sie Meldungen zu abgewiesenen Cookies und die tatsächliche Weiterleitungskette. Vergleichen Sie kanonischen Host, shop_url-Datensätze, SSL-Einstellungen und Proxy-Weiterleitungskonfiguration. Wechseln Sie während des Checkouts nicht zwischen www und ohne www oder zwischen HTTP und HTTPS.

1. Testen Sie ein sauberes Browserprofil oder ein privates Fenster, um gespeicherten Zustand einzugrenzen.
2. Prüfen Sie, dass Admin-Antworten und authentifizierte Inhalte öffentliches Caching umgehen.
3. Prüfen Sie den Cookie-Geltungsbereich und ob der Browser es bei der fehlgeschlagenen Anfrage sendet.
4. Bestätigen Sie, dass eine Bereitstellung nicht unbeabsichtigt die erwarteten Cookie-/Verschlüsselungsschlüssel ersetzt hat.
5. Prüfen Sie bei mehreren Anwendungsknoten kompatible Schlüssel und den Sitzungsspeicher jeder relevanten Komponente.
6. Testen Sie den vollständigen Anmelde- oder Zahlungsrückkehrablauf erneut, einschließlich websiteübergreifender POST- oder 3-D-Secure-Schritte.

Ändern Sie SameSite nicht auf Verdacht global auf None. Einige websiteübergreifende Abläufe benötigen eine andere Richtlinie, wobei moderne Browser für None auch Secure verlangen. Ermitteln Sie jedoch zuerst, welches Cookie und welche Anfrage Zustand verlieren. Der aktuelle Core begrenzt außerdem die gemeinsame Größe von Cookie-Name und -Wert auf 4096 Bytes. Speichern Sie darin keine großen Arrays oder Debug-Daten.

Ein Fehler wegen ungültigem Token kann durch abgelaufenen Zustand, ein altes Formular, einen geänderten Host, blockierte Cookies, Proxy-Verhalten oder andere Abweichungen in der Anfrage entstehen. Öffnen Sie die Seite über einen aktuellen Admin-Link erneut und untersuchen Sie die Anfrage. Eine Erhöhung von session.gc_maxlifetime ist keine allgemeingültige Lösung.

Cookies, die für den angeforderten Warenkorb- oder Authentifizierungsdienst unbedingt erforderlich sind, können hinsichtlich der Einwilligung anders behandelt werden als Analytics- oder Werbe-Cookies. Bewerten Sie den tatsächlichen Zweck und prüfen Sie, dass Ihre Einwilligungsintegration nicht notwendige Tags steuert. Siehe Sitzungen und Cookies sowie GDPR und Einwilligung.

E-Mail-Zustellung und Serverzustand getrennt prüfen

E-Mail

Senden Sie unter Erweiterte Einstellungen > E-Mail einen kontrollierten Test und prüfen Sie anschließend den konfigurierten SMTP-Endpunkt, Zugangsdaten, Verschlüsselung und Ereignisse beim Anbieter. Eine Zeile im E-Mail-Protokoll beweist keine Zustellung im Posteingang. Verfolgen Sie Annahme, Ablehnung, Rückläufer und Spam-Einstufung getrennt.

Prüfen Sie mit Ihrem E-Mail-Anbieter Authentifizierung und Ausrichtung der Absenderdomain über SPF, DKIM und DMARC. Gehen Sie nicht davon aus, dass ein bestimmter Port oder ein Wechsel von lokalem Mailversand zu SMTP die Zustellung garantiert. Wenn eine einzelne Bestell-E-Mail fehlschlägt, prüfen Sie vor dem erneuten Versand Template, Sprache, Empfänger, auslösendes Ereignis und Warteschlangen- oder Modulpfad. Siehe E-Mail-Zustellbarkeit.

Plötzliche Langsamkeit

Messen Sie die Serverantwortzeit getrennt von langsamen Browser-Assets. Prüfen Sie freie Bytes, freie Inodes, Arbeitsspeicher, Last, Datenbank-Wartezustände, PHP-Worker-Auslastung und geplante Jobs:

df -h
df -i
uptime
free -m

Es gibt keinen allgemeingültigen Belegungsprozentsatz, bei dem ein Shop ausfällt. Protokolle, temporäre Dateien, Datenbankschreibvorgänge und Cache-Neuaufbauten benötigen ausreichend tatsächlich freien Platz. Ein Speicherfehler kann außerdem verhindern, dass das Diagnoseprotokoll geschrieben wird.

Prüfen Sie, ob Debug-Modus oder Profiling aktiviert geblieben sind. Untersuchen Sie aufwendige Abfragen und Hooks unter kontrollierten Bedingungen per Profiling. Prüfen Sie überlappende Import- oder Cronjobs, Sperren, unbegrenzte Abfragen und wachsende Verbindungs-, Protokoll-, Warenkorb- oder Gastdaten. Wenden Sie vor der Bereinigung eine Aufbewahrungsrichtlinie an und bewahren Sie erforderliche Bestellungen und Aufzeichnungen auf.

Behandeln Sie ein Cache-Modul nicht als Abhilfe für jeden 500- oder 503-Fehler. Folgen Sie dem Performance-Leitfaden, sobald Anfrage und Serverengpass identifiziert sind.

Praxisbeispiel: Zahlung abgeschlossen, Checkout scheinbar fehlgeschlagen

Ein Kunde meldet eine Abbuchung, nachdem die Ladeanzeige im Checkout stoppt, doch die Mitarbeiter finden keine Bestellung. Stellen Sie zuerst fest, ob der Anbieter eine Autorisierung, eine eingezogene Zahlung oder einen fehlgeschlagenen Versuch ausweist. Ein Kunden-Screenshot und ein Checkout-Fehler belegen den endgültigen Zahlungsstatus nicht.

1. Halten Sie Warenkorbreferenz, Zahlungsreferenz, Konto und Test-/Live-Modus, Betrag, Währung und Uhrzeit fest. Suchen Sie nach allen aus diesem Warenkorb entstandenen Bestellungen, einschließlich verzögerter oder aufgeteilter Ergebnisse.
2. Untersuchen Sie die fehlgeschlagene Browseranfrage getrennt von der Zustellung der Anbieterbenachrichtigung und deren Verarbeitung durch die Anwendung. Eine durch Wartungsmodus oder Zugangsprüfung blockierte Benachrichtigung erfordert eine andere Korrektur als ein Handler, der sie empfängt und beim Anlegen der Bestellung scheitert.
3. Nutzen Sie nach Bestätigung des Anbieterstatus das von der Integration unterstützte Abgleich- oder Wiederholungsverfahren. Lassen Sie den Betreuer prüfen, ob ein erneuter Versuch Bestellungen, Zahlungen, E-Mails oder Bestandsbewegungen duplizieren kann.
4. Erproben Sie den fehlerhaften Ablauf auf Staging mit den Testwerkzeugen des Anbieters, auch für einen Kunden, der den Browser vor der Rückkehr schließt. Bestätigen Sie die entstandene Bestellung, die Transaktionsreferenz und den Zustand der nachgelagerten Auftragsabwicklung.

Fordern Sie den Kunden nicht zu einer erneuten Zahlung auf und markieren Sie keine Bestellung manuell als bezahlt, solange der ursprüngliche Versuch ungeklärt ist. Stimmen Sie sich mit den Verantwortlichen für Lager- oder ERP-Exporte ab, damit eine verzögerte Wiederherstellung denselben Kauf nicht zweimal zur Abwicklung freigibt. Eine browserseitige Korrektur allein belegt nicht, dass der serverseitige Zahlungsablauf wieder funktioniert.

Zugang wiederherstellen, gezielt zurücksichern und den Shop prüfen

Verwenden Sie zuerst den normalen Ablauf zum Zurücksetzen des Mitarbeiterpassworts. Wenn die Wiederherstellung per E-Mail nicht verfügbar ist, lassen Sie einen Entwickler den Hashing-Dienst der installierten Version in einem privaten CLI-Wiederherstellungsverfahren für den genauen Mitarbeiter verwenden. Modernes PrestaShop nutzt seinen Hashing-Dienst; das ältere 1.6 verwendet seinen älteren Mechanismus auf Cookie-Schlüssel-Basis. Lassen Sie kein nicht authentifiziertes öffentliches Passwort-Reset-Skript und kein festes Passwort im Web-Stammverzeichnis zurück.

Wenn der Admin-Zugang verloren ist, steuern Sie während der Reparatur den Traffic beim Hoster oder Proxy. Der Wartungsmodus befindet sich normalerweise unter Shop-Einstellungen > Allgemein > Wartung. Jede Notfalländerung der Konfiguration muss das tatsächliche Präfix und den richtigen Shop-Geltungsbereich verwenden und alte Werte sowie Whitelist-Einstellungen sichern. Eine pauschale Aktualisierung aller PS_SHOP_ENABLE-Datensätze kann andere Shops betreffen.

1. Wählen Sie zusammenpassende Dateien und Datenbank von einem bekannten Wiederherstellungspunkt. Sichern Sie den fehlerhaften Zustand für die Untersuchung.
2. Stoppen Sie öffentliche Schreibzugriffe und Jobs und stellen Sie anschließend wieder her oder wenden Sie die eng begrenzte Korrektur an.
3. Gleichen Sie Transaktionen nach dem Wiederherstellungspunkt ab, einschließlich der Aufzeichnungen des Zahlungsanbieters.
4. Bauen Sie nur die relevanten Caches mit korrekten Eigentumsrechten neu auf und stimmen Sie Web-OPcache und externe Caches ab.
5. Testen Sie das ursprüngliche Symptom, Admin-Zugang, Katalog, Warenkorb, Sandbox-Checkout, E-Mails und Hintergrundjobs.
6. Prüfen Sie einen sauberen und einen zweiten Browser. Bestätigen Sie, dass Debug-Ausgaben und temporäre Werkzeuge entfernt sind.
7. Dokumentieren Sie vor der vollständigen Wiederöffnung Ursache, geänderte Dateien/Einstellungen, Wiederherstellungspunkt und Testergebnisse.

Überwachen Sie nach der Wiederherstellung weiterhin Fehlerprotokolle, Verfügbarkeit, freien Speicherplatz und fehlgeschlagene Jobs. Testen Sie Backups durch Wiederherstellung auf Staging. Senden Sie für eine MPR-Supportanfrage genaue Versionen, Zeitstempel, Reproduktionsschritte, betroffenen Umfang, letzte Änderungen und geschwärzte Protokolle über Support kontaktieren. Fügen Sie bei Problemen mit dem Speichern oder mit AJAX die fehlgeschlagene Netzwerkantwort bei.

Getestete Korrektur ohne Überschreiben neuer Geschäftsdaten übernehmen

Führen Sie ein Änderungsprotokoll mit dem Paket oder den Dateien, Konfigurationswerten, Migrationen und Cache-Aktionen, die für die Korrektur nötig sind. Spielen Sie diese definierte Änderung ein, statt den gesamten Staging-Shop über den Live-Shop zu kopieren. Eine Staging-Datenbank aus der Zeit vor den heutigen Bestellungen ist kein aktueller Ersatz für die Live-Datenbank.

Vereinbaren Sie vor dem Live-Zeitfenster, was ein Rückgängigmachen auslösen würde und ob die Änderung Daten geschrieben hat, die älterer Code nicht lesen kann. Ein bloßer Dateiaustausch macht eine Migration oder eine externe API-Aktion möglicherweise nicht rückgängig. Halten Sie eingehende Integrationen und wartende Aufgaben unter Kontrolle und gleichen Sie zurückgehaltene Ereignisse ab, bevor die normale Verarbeitung wieder beginnt. Nutzen Sie den Leitfaden zu Sicherung und Wiederherstellung, wenn der gewählte Weg eine vollständige Wiederherstellung erfordert.

Fragen an Ihren Entwickler oder Ihre Agentur

• Welche Belege identifizieren die Ursache und welche Beobachtungen würden sie ausschließen? Bitten Sie um die fehlgeschlagene Anfrage und den passenden Fehler statt um eine Liste geänderter Einstellungen.
• Welche Teile der Live-Umgebung wurden nachgebildet und welche Unterschiede bleiben? Berücksichtigen Sie Web-PHP, Modulversionen, Theme-Kopien, Proxy-Regeln und die für den Fehler relevanten Integrationen.
• Was ist die kleinste klar definierte Änderung, wer betreut einen etwaigen Modul-Kompatibilitätspatch und wie bleibt dieser beim nächsten Update erhalten?
• Lässt sich die Änderung rückgängig machen, nachdem sie Daten geschrieben oder einen externen Dienst aufgerufen hat? Fragen Sie, wie Bestellungen und Zahlungen aus der Zeit des Vorfalls abgeglichen werden.
• Welche Abnahmeergebnisse erhalten Sie für die betroffenen Märkte, Kundengruppen und Mitarbeiterabläufe und wer prüft den Live-Betrieb nach der Wiederöffnung?

Bestimmen Sie eine Person, die Änderungen zwischen Hoster, Modulanbieter und Shopentwickler koordiniert. Führen Sie ein gemeinsames Vorfallsprotokoll, damit nicht ein Team ein altes Paket wiederherstellt, während ein anderes den Ersatz testet. Schließen Sie die Übergabe mit bestätigter Ursache, endgültiger Änderung und verbleibenden Folgearbeiten ab.

Häufige Fragen von Shopbetreibern

Was, wenn der Fehler auf Staging nicht auftritt?

Vergleichen Sie die Anfrage und relevante Umgebungsunterschiede, bevor Sie den Fehler für behoben erklären. Live-Traffic, Cache-Zustand, externe Zugangsdaten oder ein geplanter Job können zum Auslöser gehören. Vereinbaren Sie mit Ihrem Entwickler eine eng begrenzte Protokollierung im Live-Betrieb, wenn sich der Auslöser nicht sicher nachbilden lässt.

Was, wenn der Fehler nur gelegentlich auftritt?

Führen Sie ein Vorfallsprotokoll mit betroffenen Pfaden und Geschäftsvorgängen und erfassen Sie bei erneutem Auftreten die passenden Serverbefunde. Vereinbaren Sie mit Ihrem Entwickler einen gezielten Beobachtungszeitraum oder Auslöser. Wiederholte Einstellungsänderungen zwischen den Vorfällen erschweren die Eingrenzung einer sporadischen Ursache.

Warum ist nur ein Land oder eine Kundengruppe betroffen?

Reproduzieren Sie den Fehler mit derselben Sprache, Währung, Gruppe, Adresse, demselben Versanddienst und denselben Voraussetzungen für die Zahlungsarten. Vergleichen Sie diesen Kontext mit einem funktionierenden und ändern Sie jeweils nur eine relevante Auswahl. Länderspezifische Steuern, Einschränkungen oder Integrationsantworten können Kunden durch unterschiedliche Codepfade führen.

Stoppt der Wartungsmodus jede Änderung an Shopdaten?

Gehen Sie nicht davon aus, dass er Cron-Aufgaben, Worker, API-Clients oder Zahlungs-Callbacks stoppt. Ermitteln Sie die schreibenden Prozesse Ihres Shops und stimmen Sie vor einer Wiederherstellung deren Pausierung, Zwischenspeicherung oder späteren Abgleich ab. Fragen Sie den Betreuer der Zahlungsintegration, wie sich Benachrichtigungen in diesem Zeitfenster verhalten.

Kann ich einen Export der Browser-Netzwerkansicht an den Support senden?

Ein HAR-Export kann Cookies, Autorisierungsheader, Tokens, übermittelte Formulardaten und Kundendetails enthalten. Prüfen und schwärzen Sie ihn vor der Weitergabe über einen privaten Supportkanal. Erhalten Sie dabei die zur Diagnose nötige Anfragesequenz und Fehlermeldung. Übermitteln Sie Zugangsdaten separat über den vereinbarten sicheren Weg.

Was sollten Mitarbeiter betroffenen Kunden sagen?

Dokumentieren Sie den betroffenen Ablauf und den nächsten Schritt, den Mitarbeiter sicher ausführen können. Bezeichnen Sie eine Zahlung bis zum erfolgten Abgleich als ungeklärt und geben Sie dem Team eine zentrale Stelle für Kundenreferenzen und Nachverfolgung. Nennen Sie einen Wiederherstellungszeitpunkt erst, wenn ihn die für den Vorfall zuständige Person bestätigt hat.