- Patryk Marek
- News
- 0 Likes
- 127 Ansichten
- 0 Kommentare
Notieren Sie die genaue Adresse, die Uhrzeit mit Zeitzone und die Aktion, nach der der Fehler aufgetreten ist. Diese drei Informationen ermöglichen es, dasselbe Ereignis in den Logs zu suchen. Allein die Nummer 500 oder 522 weist noch nicht auf das Modul hin, das geändert werden muss.
Dieser Leitfaden hilft dabei, eine Meldung für die Diagnose vorzubereiten. Er beschreibt nicht die Reparatur eines konkreten Shops und stellt beispielhafte Ursachen nicht als feststehendes Ergebnis dar.
Was sollte während einer Störung notiert werden?
- Adresse und Aktion: z. B. das Öffnen eines Produkts, das Speichern einer Einstellung im Panel oder der Wechsel vom Warenkorb zur Lieferung. Notieren Sie in einer öffentlichen Meldung keine Tokens aus der Panel-Adresse.
- Zeit: Datum, Uhrzeit und Zeitzone, z. B.
2026-09-26 14:32 Europe/Warsaw. Wenn das Problem wiederkehrt, notieren Sie zwei oder drei konkrete Vorkommnisse. - Antwort: HTTP-Code, sichtbare Meldung sowie die Anfrage-ID, falls die Fehlerseite diese angibt. Ergänzen Sie den Screenshot um den Meldungstext.
- Umfang: eine Adresse oder der ganze Shop, Frontend oder Panel, eingeloggter Benutzer oder Gast, ein Netzwerk oder auch ein zweites.
- Letzte Änderung: Aktualisierung, Modulinstallation, Import, Änderung der Hosting-Einstellung. Geben Sie das Datum an; allein die Reihenfolge der Ereignisse beweist noch keine Ursache.
Fehler 500 und Fehler 522 erfordern unterschiedliche Ansatzpunkte
| Antwort | Womit beginnen | Was noch nicht bekannt ist |
|---|---|---|
| HTTP 500 | Vergleichen Sie Zeit und Pfad mit dem Anwendungslog sowie dem Serverlog, der die Anfrage verarbeitet. | Der Code identifiziert nicht selbstständig das Modul, die Abfrage oder die PHP-Einstellung. Derselbe Status kann von verschiedenen Störungen zurückgegeben werden. |
| Cloudflare 522 | Prüfen Sie die Verbindung zwischen Cloudflare und dem Ursprungsserver. Notieren Sie die Ray ID, falls sie sichtbar ist, und geben Sie die Zeit an das Hosting weiter. | Der Code allein bestätigt keinen PrestaShop-Fehler. Die Ursache kann u. a. die Nichtverfügbarkeit oder Überlastung des Servers oder das Blockieren von Verbindungen sein. |
| Leere Seite ohne gespeicherten Status | Prüfen Sie die Antwort des Hauptdokuments in den Browser-Tools; bewahren Sie Adresse und Zeit auf. | Es ist noch nicht bekannt, ob das Problem die Serverantwort, ein Skript im Browser oder eine für die Anzeige der Seite benötigte Ressource betrifft. |
Beschreibung von 522 und Empfehlungen für die Verbindung mit dem Ursprungsserver: Cloudflare-Dokumentation. Allgemeine Bedeutung des Status 500: HTTP Semantics, RFC 9110.
Wie bereitet man einen einfachen Reproduktionsversuch vor?
Beispiel für eine Demonstrationsmeldung: „Um 14:32 öffne ich als Gast die Produktkarte. Das Dokument hat den Status 500. Die Startseite funktioniert im selben Browser. Um 14:35 funktioniert dasselbe Produkt aus einem zweiten Netzwerk.“ Eine solche Notiz diagnostiziert nicht die Ursache, weist aber auf konkrete Anfragen zum Vergleich hin.
Ändern Sie bei jeder Wiederholung eine Bedingung und notieren Sie das Ergebnis. Wenn Sie gleichzeitig den Cache leeren, PHP ändern und mehrere Module deaktivieren, wird es schwierig festzustellen, welche Änderung das Verhalten des Shops beeinflusst hat.
Welche Logs sollten der diagnostizierenden Person übergeben werden?
Bitten Sie um die Prüfung eines kurzen Zeitraums rund um das Ereignis: des Anwendungslogs, der PHP-Fehler und des WWW-Server-Logs sowie bei einer Zwischenschicht auch deren Ereignisse. Der Speicherort der Logs hängt von der Shop-Version und der Hosting-Konfiguration ab. Statt einen Pfad anzunehmen, geben Sie dem Administrator die genaue Zeit, die Adresse sowie die Anfragemethode an, falls Sie diese kennen.
Log-Auszüge können E-Mail-Adressen, Sitzungskennungen und Bestelldaten enthalten. Übermitteln Sie den benötigten Ausschnitt über einen abgestimmten Kanal und entfernen Sie Geheimnisse. Eine vollständige HAR-Datei kann ebenfalls solche Informationen enthalten; veröffentlichen Sie sie nicht als gewöhnlichen Anhang im Forum.
Wie vergleicht man Schichten, ohne den Schutz des gesamten Shops zu ändern?
Den Vergleich der Antworten über das CDN und direkt vom Server sollte ein Administrator vorbereiten, der die Konfiguration der Domain, TLS und den Zugriff auf den Origin kennt. Der Unterschied zwischen den Antworten ist ein Hinweis für weitere Tests und kein automatischer Beweis für die Schuld von WAF oder PrestaShop.
Verwenden Sie den Debug-Modus auf einer Arbeitskopie oder mit kontrolliertem Zugriff. Das globale Deaktivieren des Schutzes oder das Anzeigen detaillierter Ausnahmen für alle Besucher ist nicht erforderlich, um eine nützliche Meldung zu erstellen.
Fertige Meldevorlage zum Herunterladen
Formular zur Beschreibung der Störung herunterladen — TXT. Füllen Sie die Felder aus und kennzeichnen Sie fehlende Informationen mit „nicht geprüft“. Das Formular erfordert keine Passwörter oder API-Schlüssel.
Was sollte nach der Korrektur geprüft werden?
Wiederholen Sie die notierten Schritte unter denselben Bedingungen und prüfen Sie das Ergebnis der Aktion sowie neue Einträge in den Logs. Bei einem sporadischen Problem bestätigt ein einmaliges korrektes Öffnen der Seite nur diesen einen Versuch. Vereinbaren Sie mit dem Ausführenden den Beobachtungszeitraum, den Testumfang sowie das Signal für eine erneute Meldung.
Wenn das Problem bei einer Versionsänderung aufgetreten ist, nutzen Sie auch die Checkliste zur Vorbereitung einer PrestaShop-Aktualisierung. Ein separater Leitfaden erklärt die Rolle von HTTP-Sicherheitsheadern.
Kommentare (0)