Warnungen bei Fehler 500, 404 und Checkout in PrestaShop (DataFirefly Site Alerts)

DataFirefly Site Alerts sendet eine E-Mail an die Adressen Ihrer Wahl, wenn Ihr PrestaShop 8 oder 9 Shop einen Fehler 500 liefert, sich 404-Fehler häufen oder einem Kunden im Checkout kein Versanddienst oder keine Zahlungsart angeboten wird. Diese Dokumentation behandelt die Installation, die Einstellungen, den Inhalt jeder Warnung und die Fehlerbehebung.

Installation

1. Öffnen Sie im Backoffice Module > Modul-Manager, klicken Sie auf Modul hochladen und laden Sie die Datei dfsitealerts-1.0.0.zip hoch.
2. Das Modul legt seine Tabelle und einen Tab Erweiterte Einstellungen > Fehler- und Checkout-Alarme an. Der Button Konfigurieren des Moduls führt direkt dorthin.
3. Bei der Installation wird die E-Mail-Adresse des Shops als Empfänger verwendet, und alle vier Erkennungen sind aktiv.
4. Klicken Sie auf Test-E-Mail senden, um zu prüfen, ob die Warnungen ankommen.

Das Modul ist mit PrestaShop 8.0 bis 9.x und Multistore kompatibel. Es verwendet keine Composer-Abhängigkeit. Die E-Mails laufen über die Konfiguration unter Erweiterte Einstellungen > E-Mail: Sind E-Mails dort deaktiviert, wird oben auf der Modulseite ein Hinweis angezeigt.

Dashboard

Oben auf der Seite wird die Anzahl der in den letzten 24 Stunden erkannten unterschiedlichen Probleme nach Typ angezeigt: Fehler 500, Fehler 404, Kein Versanddienst, Keine Zahlungsart, Website nicht erreichbar. Dieselbe URL oder derselbe Fehler zählt nur einmal. Darunter stehen die aktuellen Empfänger, die Cron-URL und die Buttons Test-E-Mail senden, Geplante Aufgabe jetzt ausführen und Protokoll leeren.

Empfänger

• E-Mail-Adressen: eine Adresse pro Zeile (Kommas und Semikolons werden ebenfalls akzeptiert). Jede Adresse erhält ihre eigene E-Mail. Eine ungültige Adresse wird beim Speichern abgelehnt.
• Sprache der Warnungen: Sprache der E-Mails, unabhängig von der Sprache der Besucher. Standardmäßig die Standardsprache des Shops.

Was eine Warnung auslöst

Jede Erkennung lässt sich einzeln aktivieren oder deaktivieren.

Serverfehler (500)

Das Modul erfasst am Ende einer Frontoffice-Anfrage PHP Fatal Errors, nicht abgefangene Exceptions und jede Seite, die mit einem 5xx-Status antwortet. Der Wartungsmodus (503) wird ignoriert. Die E-Mail enthält:

• die Fehlermeldung und den Stack-Trace, ohne den Serverpfad;
• den PHP-Fehlertyp, die Datei und die Zeile als relativen Pfad;
• die URL, die Herkunftsseite, die HTTP-Methode, den Controller und den User-Agent;
• den Spitzen-Speicherverbrauch und die Versionen von PrestaShop und PHP.

Wenn PrestaShop eine PrestaShopException abfängt und seine Fehlerseite anzeigt, ist keine PHP-Meldung verfügbar: Das Modul übernimmt dann den letzten Eintrag der Datei var/logs/JJJJMMTT_exception.log des Tages. Identische Fehler werden gruppiert, wobei variable Zahlen (IDs, Speichergrößen) für die Gruppierung ignoriert werden.

Nicht gefundene Seiten (404)

404-Fehler werden nach URL-Pfad gruppiert. Parameter, die eine Seite identifizieren (controller, id_product…), bleiben erhalten, Tracking-Parameter (utm_*, gclid, fbclid, msclkid…) werden ignoriert. Eine Warnung wird gemäß den Einstellungen des folgenden Abschnitts versendet.

Checkout ohne Versanddienst

Die Erkennung greift, wenn ein Kunde den Versandschritt mit einer Lieferadresse und einem nicht leeren, nicht virtuellen Warenkorb erreicht und kein Versanddienst angeboten wird. Die Probleme werden nach Land und Bundesland gruppiert. Die E-Mail enthält:

• die Warenkorb- und Kunden-ID, das Land, das Bundesland, die Postleitzahl und die Zone;
• das Gewicht und die Summe des Warenkorbs, die Artikelliste und die Kundengruppe;
• Aktive Versanddienste für diese Zone und Gruppe, jeweils mit dem Grund für das Fehlen: außerhalb seiner Gewichtsbereiche, außerhalb seiner Preisbereiche, Paketgröße zu groß, durch Artikelbeschränkungen oder die Paketaufteilung ausgeschlossen, oder für diesen Warenkorb nicht zurückgegeben (Versandmodul oder Versandkosten nicht verfügbar);
• Auf bestimmte Versanddienste beschränkte Artikel: die Artikel im Warenkorb, in deren Tab Versand Versanddienste ausgewählt sind.

Ist der Zone und der Gruppe des Kunden kein aktiver Versanddienst zugeordnet, weist die Warnung direkt darauf hin.

Checkout ohne Zahlungsart

Die Erkennung greift, wenn ein Kunde den Zahlungsschritt mit einem zu bezahlenden Warenkorb erreicht und kein Zahlungsmodul eine Option anbietet. Ein kostenloser Warenkorb (Summe 0) ist nicht betroffen. Die Probleme werden nach Land, Währung, Versanddienst und Gruppe gruppiert. Die E-Mail enthält das Land, die Währung, den gewählten Versanddienst, die Summe, die Kundengruppe und anschließend:

• Aktive Zahlungsmodule: alle installierten und aktivierten Zahlungsmodule;
• Für dieses Land, diese Währung, diese Gruppe und diesen Versanddienst zugelassene Zahlungsmodule: die Module, die die Einschränkungen unter Zahlung > Voreinstellungen für diesen Kunden zulassen.

Ist die zweite Liste leer, liegt die Ursache in den Einschränkungen. Enthält sie Module, sind diese zugelassen, haben aber keine Option zurückgegeben: Die Ursache liegt dann in ihrer eigenen Konfiguration (Mindestbetrag, nicht verbundenes Konto, Testmodus).

404-Einstellungen

• Warnschwelle: Eine Warnung wird versendet, wenn dieselbe URL seit ihrer letzten Warnung diese Anzahl an Besuchen erreicht. Standardmäßig 5, 1 für eine Warnung schon beim ersten Besuch.
• Sofortige Warnung bei defekten internen Links: Gehört die Herkunftsseite zu Ihrem Shop, wird die Warnung unabhängig von der Schwelle schon beim ersten Besuch versendet.
• Bots ignorieren: Suchmaschinen, SEO-Bots, Skripte und leere User-Agents.
• Statische Dateien ignorieren: Bilder, CSS, JS, Schriftarten und Videos.
• Zu ignorierende URLs: ein Pfad pro Zeile, * steht für beliebige Zeichen. Die Standardliste ignoriert gängige Scans: /wp-*, /wordpress/*, /xmlrpc.php, */.env, */.git/*, /cgi-bin/*, *phpmyadmin*, /.well-known/*, /apple-touch-icon*.

Versandlimits und tägliche Zusammenfassung

• Abstand zwischen zwei Warnungen zum selben Problem: standardmäßig 60 Minuten. Die in diesem Zeitraum aufgetretenen Vorkommen werden gezählt und in der nächsten Warnung in der Zeile „Vorkommen seit der letzten Warnung“ angegeben.
• Maximale Warnungen pro Stunde: standardmäßig 20, 0 für keine Begrenzung. Probleme oberhalb des Limits bleiben gespeichert und erscheinen in der Zusammenfassung.
• Tägliche Zusammenfassung: eine E-Mail pro Tag zur gewählten Uhrzeit (standardmäßig 8:00), die jedes seit der vorherigen Zusammenfassung gespeicherte Problem auflistet, einschließlich derer unterhalb der Warnschwelle. Sie wird nicht versendet, wenn nichts passiert ist.
• Protokoll aufbewahren für: standardmäßig 30 Tage, von 1 bis 365.

Geplante Aufgabe

Die Warnungen zu 500, 404 und Checkout werden in Echtzeit versendet. Die geplante Aufgabe versendet die tägliche Zusammenfassung zur geplanten Uhrzeit, verarbeitet Warnungen erneut, die nicht in der Datenbank gespeichert werden konnten, bereinigt das Protokoll und startet die Verfügbarkeitsprüfung. Eine Ausführung alle 15 Minuten ist geeignet.

Cron per URL

*/15 * * * * curl -fsS "https://ihr-shop.de/module/dfsitealerts/cron?token=…" > /dev/null

Die genaue URL mit ihrem Token wird auf der Modulseite mit einem Button Kopieren angezeigt. Sie antwortet in JSON und funktioniert auch im Wartungsmodus. Ein ungültiges Token liefert einen Fehler 403.

Cron über die Kommandozeile

*/15 * * * * php /pfad/zu/prestashop/modules/dfsitealerts/cron.php > /dev/null

Der Befehl verarbeitet im Multistore alle aktiven Shops.

Ohne Cron

Nach einem normalen Besuch im Shop startet das Modul die Wartung höchstens einmal alle 15 Minuten. Die Zusammenfassung wird daher nach dem ersten Besuch nach der geplanten Uhrzeit versendet. Die Verfügbarkeitsprüfung läuft in diesem Modus nicht.

Verfügbarkeitsprüfung

Manche Fehler 500 treten vor dem Start von PrestaShop auf (Absturz von PHP-FPM, defekte Konfigurationsdatei): Kein Modul kann sie dann erfassen. Die Verfügbarkeitsprüfung ruft bei jedem Cron-Durchlauf vom Server aus die unter Zu testende URLs aufgeführten URLs auf (höchstens 10, die Startseite, wenn die Liste leer ist). Eine 5xx-Antwort oder eine fehlgeschlagene Verbindung löst die Warnung Verfügbarkeitsprüfung fehlgeschlagen aus, mit dem HTTP-Code, der Antwortzeit und dem Verbindungsfehler. Ein 503 wird ignoriert, wenn sich der Shop im Wartungsmodus befindet.

Fügen Sie für eine bessere Abdeckung eine Kategorieseite und eine Produktseite hinzu. Für einen vollständigen Serverausfall, der auch den Cron verhindert, verwenden Sie zusätzlich einen externen Dienst zur Verfügbarkeitsüberwachung.

Warnungsprotokoll

Die Liste unten auf der Seite zeigt jedes gespeicherte Problem: Typ, Ort (URL, oder Land / Währung / Versanddienst beim Checkout), Meldung oder Herkunftsseite, Anzahl der Vorkommen, erste und letzte Erkennung, Datum der letzten Warnung. Sie lässt sich nach Typ filtern und als CSV exportieren. Der Button Anzeigen öffnet eine Detailansicht mit demselben Inhalt wie die E-Mail und den Rohdaten in JSON. Das Löschen eines Eintrags setzt seinen Zähler auf null zurück.

Daten und Datenschutz

• Die Checkout-Warnungen enthalten die Warenkorb- und Kunden-ID, das Land, das Bundesland, die Postleitzahl, das Gewicht und den Inhalt des Warenkorbs. Sie enthalten weder Namen noch Postanschrift, E-Mail-Adresse oder Telefonnummer.
• Der Serverpfad wird aus den Fehlermeldungen und Stack-Traces entfernt.
• Das Protokoll wird nach der gewählten Aufbewahrungsdauer bereinigt.
• Wenn die Datenbank das Schreiben verweigert, wird die Warnung in einer Datei in var/logs gespeichert (höchstens 2 MB) und beim nächsten Wartungsdurchlauf erneut verarbeitet.

Bekannte Einschränkungen

• Nur das Frontoffice wird überwacht. Fehler im Backoffice lösen keine Warnung aus.
• Ein vollständiger Ausfall des Servers oder von PHP verhindert jeden E-Mail-Versand: Verwenden Sie einen externen Dienst zur Verfügbarkeitsüberwachung.
• Die Checkout-Erkennungen basieren auf dem nativen Bestellprozess von PrestaShop. Mit einem One-Page-Checkout-Modul eines Drittanbieters hängt die Versanddienst-Warnung vom Aufruf des Hooks displayBeforeCarrier ab, und die Zahlungs-Warnung wird erst ausgewertet, wenn ein Versanddienst gewählt wurde.
• Der Versand nach der Seitenausgabe erfordert PHP-FPM oder LiteSpeed. Bei einem anderen PHP-Ausführungsmodus wird die E-Mail vor dem Ende der Anfrage versendet.

Fehlerbehebung

Die Test-E-Mail kommt nicht an

Prüfen Sie Erweiterte Einstellungen > E-Mail und senden Sie von dieser Seite aus eine Test-E-Mail. Sehen Sie auch im Spam-Ordner nach: Fügen Sie die Absenderadresse des Shops zu Ihren Kontakten hinzu.

Ich erhalte zu viele 404-Warnungen

Erhöhen Sie die Warnschwelle, fügen Sie die betroffenen Pfade unter Zu ignorierende URLs hinzu oder legen Sie die fehlenden 301-Weiterleitungen an: Eine weitergeleitete URL liefert keine 404 mehr.

Keine Checkout-Warnung, obwohl sich ein Kunde beschwert hat

Prüfen Sie, ob beide Checkout-Erkennungen aktiv sind und ob der Kunde den betreffenden Schritt tatsächlich mit einer Adresse erreicht hat. Bei einem One-Page-Checkout-Modul eines Drittanbieters lesen Sie den Abschnitt Bekannte Einschränkungen.

„Die Cron-Aufgabe wurde noch nie ausgeführt.“ wird weiterhin angezeigt

Rufen Sie die Cron-URL in einem Browser auf: Sie muss mit {"ok":true,…} antworten. Die Antwort invalid token bedeutet, dass die URL unvollständig kopiert wurde.