Debug-Log WordPress: PHP-Fehler in einer eigenen Datei

Das Debug-Log WordPress ist eine Neuheit des Plugins CSDN seit Version 1.0.15. Es erfasst die PHP-Fehler der Website in einer eigenen Datei, ohne wp-config.php zu berühren. Du schaltest es im Backend ein, und es schaltet sich von selbst aus.

Wo du es findest

Geh zu Einstellungen > Cisilino Site Defense Network (Punkt 1 im Bild) und öffne den Reiter Debug-Log (Punkt 2). Es gibt drei Abschnitte:

• Punkt 3: „Debug-Log der Website“, mit Status und Einschalten.
• Punkt 4: „Gesammelte Dateien“.
• Punkt 5: „Letzte Einträge“.

Wozu das Debug-Log WordPress dient

Es ist nützlich, wenn die Website eine leere Seite oder einen kritischen Fehler zeigt, wenn nach einem Update etwas kaputtgeht, oder wenn dein Hosting dich wp-config.php nicht ändern oder die Server-Logs nicht lesen lässt. Die Konstanten WP_DEBUG und WP_DEBUG_LOG werden vor dem Laden der Plugins definiert, ein Plugin kann sie also nicht einschalten. Dieses Log nutzt einen eigenen PHP-Fehlerhandler, der beim Laden des Plugins eingehängt wird.

Dieses Log kommt dazu, es ersetzt nichts. Die Fehler kommen weiter dort an, wo sie vorher ankamen, also in debug.log und im Server-Log. Es sendet nichts an das Panel.

Wie man es benutzt

1. Öffne den Reiter Debug-Log.
2. Wähl Bleibt an für: 1 Stunde, 24 Stunden (Standard) oder 7 Tage.
3. Wähl Maximale Dateigröße.
4. Klick auf Debug-Log einschalten. Du liest „Debug-Log eingeschaltet. Es schaltet sich von selbst bei Ablauf der gewählten Zeit aus; die Dateien bleiben.“.
5. Reproduzier das Problem auf der Website.
6. Geh zurück zum Reiter. Lies „Letzte Einträge“ oder lad die Datei aus dem Abschnitt „Gesammelte Dateien“ herunter.
7. Wenn du fertig bist, klick auf Debug-Log ausschalten, oder warte den Ablauf ab. Du siehst „Debug-Log ausgeschaltet. Die gesammelten Dateien stehen weiter unten.“.

Der „Status:“ sagt dir, ob das Log „an, schaltet sich am tt.mm.jjjj hh:mm aus“, „aus (abgelaufen am …)“ oder „aus“ ist. Bei eingeschaltetem Log kannst du die Größe mit Größe speichern ändern.

Gesammelte Dateien

Die Tabelle listet Name, Größe und die Schaltflächen Herunterladen und Löschen. Darunter findest du Alle Dateien löschen. Vor dem Löschen fragt das Plugin: „Diese Datei löschen? Der Vorgang lässt sich nicht widerrufen.“. Für Alle Dateien löschen lautet der Text „Alle Dateien des Debug-Logs löschen? Der Vorgang lässt sich nicht widerrufen.“. Gibt es nichts, liest du „Keine Datei: das Log war nie an oder hat noch nichts erfasst.“.

Letzte Einträge

Der Kasten zeigt die 200 neuesten Einträge, vom neuesten beginnend. Das Menü Alle Stufen erlaubt dir, nach Fatal error, Parse error, Recoverable error, Warning, Notice oder Deprecated zu filtern. Klick dann auf Filtern. Für alles andere lad die Dateien herunter. Findet der Filter nichts, liest du „Kein Eintrag mit diesem Filter.“.

Ein Eintrag hat diese Form:

[2026-10-29 10:15:03 UTC] Warning: Nachricht in /pfad/datei.php:12 | GET /seite

• Die Uhrzeit ist in UTC, anders als die Uhrzeit der Website, die du im Aktivitätsprotokoll siehst.
• Nach dem senkrechten Strich findest du Methode und Pfad der Anfrage, ohne Query-String. Von der Kommandozeile oder einem Cron aus siehst du „cli/cron“.
• Eine mehrzeilige Meldung, wie ein Stack-Trace, bleibt ein einziger Eintrag mit eingerückten Folgezeilen.
• Die Zeilen „Info: Debug-Log aktiviert (Benutzer N)“ und „Info: Debug-Log deaktiviert (Benutzer N)“ haben keine Stufe: Bei einem Filter erscheinen sie nicht.

Standardwerte und Grenzen

• Dauer des Debug-Log WordPress: 1 Stunde, 24 Stunden oder 7 Tage. Ein anderer Wert wird zu 24 Stunden.
• Größe pro Datei: 1, 5, 10, 25 oder 50 MB. Standard ist 5 MB. Die gewählte Größe wird gespeichert, wenn du auf Debug-Log einschalten oder Größe speichern klickst. Achtung: Debug-Log ausschalten bringt die Größe zurück auf 5 MB, weil dieses Modul kein Größenmenü enthält.
• Gesamtobergrenze: 200 MB, .log– und .zip-Dateien zusammengerechnet.
• Jede Nachricht wird auf 4000 Zeichen gekürzt.
• Es erfasst nur PHP-Fehler: keine langsamen Abfragen, JavaScript-Fehler oder HTTP-Anfragen.

Beispiele

• Kritischer Fehler nach einem Plugin-Update: Schalte für 1 Stunde ein, lad die Seite neu, filtere „Fatal error“. Der Eintrag zeigt Datei und Zeile, zum Beispiel /…/plugins/xyz/datei.php:210 | GET /shop/.
• Vereinzelte Warnungen: 24 Stunden, Filter Warning oder Deprecated. Wurde die Datei rotiert, lad das Zip herunter.
• Langsame Website ohne klaren Grund: 7 Tage mit 25-MB-Dateien, dann such nach wiederkehrenden Notice und Warning.

Halt das Debug-Log WordPress nur so lange an, wie nötig: Meist reicht 1 Stunde.

Achtung: Die Dateien des Debug-Logs enthalten Serverpfade und Datenfragmente. Teile sie nicht öffentlich. Sie bleiben auf der Festplatte, auch nach dem Ausschalten und nach der Deinstallation des Plugins, die die Optionen, aber nicht die Dateien löscht. Entferne sie selbst, wenn du fertig bist. Die Gesamtobergrenze liegt bei 200 MB.

Achtung: Auf nginx-Servern kann das Einschalten abgelehnt werden, solange der Server den Ordner csdn-debug-* nicht blockiert. Die Meldung lautet: „Debug-Log nicht eingeschaltet: Die Dateien seines Ordners sind vom Internet aus erreichbar (wahrscheinlich ein Server ohne .htaccess-Unterstützung, wie nginx). Die Logs können Pfade und Daten enthalten: Blockiere den Zugriff auf den Ordner csdn-debug-* in der Serverkonfiguration und versuch es erneut.“. Verwaltest du den Server nicht selbst, frag die zuständige Person.

Achtung: Das Log sieht keine mit @ unterdrückten Fehler und keine, die vor dem Laden des Plugins entstehen. Zum Beispiel sieht es keine Fehler von wp-config.php. Das Debug-Log WordPress des Plugins ersetzt die Server-Logs nicht.

Was im Hintergrund passiert

Das Debug-Log WordPress speichert die Dateien in einem Ordner wp-content/uploads/csdn-debug-, gefolgt von 16 zufälligen Zeichen. Darin liegen eine index.php, eine .htaccess, die den Zugriff verweigert, und die aktuell genutzte Datei csdn-debug.log. Beim Einschalten schreibt das Plugin eine Testdatei und versucht, sie per HTTP zu lesen. Antwortet sie, verweigert es das Einschalten des Logs.

Übersteigt die aktuell genutzte Datei die gewählte Größe, wird sie geschlossen, in .zip komprimiert, und eine neue startet. Kein Eintrag geht verloren. Die ursprüngliche .log-Datei wird erst gelöscht, nachdem das Zip geprüft wurde. Scheitert die Komprimierung, bleibt die .log-Datei. Die „Letzten Einträge“ werden nur aus der aktuell genutzten Datei gelesen, nach einer Rotation stehen die alten also in den Zip-Dateien.

Vor dem Rotieren prüft das Plugin die Obergrenze von 200 MB. Ist sie erreicht, stoppt das Log, um nichts zu überschreiben. Es erscheint der gelbe Hinweis: „Das Log wurde angehalten, weil die Dateien die Platzgrenze (200 MB) erreicht haben: Um Daten nicht zu überschreiben, schreibt es nicht mehr. Lad Dateien herunter oder lösch sie, dann schalt es erneut ein.“. Um weiterzumachen, lösch die Dateien und schalt es erneut ein.

Beim Ablauf schaltet sich das Log von selbst aus, aber die Dateien bleiben. Das Plugin kürzt oder löscht sie nie: Das tust nur du, mit Löschen oder Alle Dateien löschen. Bei fatalen Fehlern wird der Eintrag am Ende der Anfrage geschrieben.

Wenn das Debug-Log WordPress nicht funktioniert

• „Debug-Log nicht eingeschaltet: der Upload-Ordner ist nicht beschreibbar.“: Prüf die Rechte des Ordners wp-content/uploads.
• Das Log schreibt nicht: Schlägt das Schreiben fehl, meldet das Plugin es mit einem Eintrag „Debug-Log der Website: …“ in den „Letzten Versuchen“ des Reiters Aktivitätsprotokoll.
• Das Log steht wegen der Obergrenze: Lad herunter, was du brauchst, lösch die Dateien und schalt es erneut ein.

Die allgemeine Anleitung zum Handbuch erklärt, wo dieser Reiter einzuordnen ist. Um die Konstanten von WordPress besser zu verstehen, sieh dir die offizielle Anleitung zum Debuggen von WordPress an: Sie erklärt WP_DEBUG und WP_DEBUG_LOG, die dieses Plugin nicht ersetzen kann.

Vorheriges Kapitel: Aktivitätsprotokoll. Nächstes Kapitel: Fehlerbehebung und häufige Fragen.