Wenn WordPress einen kritischen Fehler, HTTP 500, eine weisse Seite oder ein anderes technisches Problem zeigt, reicht die sichtbare Fehlermeldung häufig nicht aus, um die tatsächliche Ursache zu erkennen.
WordPress und PHP können deshalb detailliertere Fehlerinformationen protokollieren. Diese Logs zeigen beispielsweise, welcher Fehlertyp aufgetreten ist, zu welchem Zeitpunkt der Fehler entstand und welche PHP-Datei beteiligt war.
WordPress besitzt dafür ein eigenes Debugging-System mit Einstellungen wie WP_DEBUG, WP_DEBUG_LOG und WP_DEBUG_DISPLAY. Zusätzlich können serverseitige PHP Error Logs wichtige Informationen enthalten.
Debugging bedeutet allerdings nicht, möglichst viele Fehlermeldungen öffentlich auf der Website anzuzeigen. Auf einer produktiven Website sollten technische Details möglichst protokolliert und anschließend gezielt ausgewertet werden.
Kurz erklärt: Aktiviere Debugging nur gezielt zur Fehlersuche. Auf einer produktiven Website sollten Fehlermeldungen normalerweise nicht öffentlich angezeigt werden. Verwende stattdessen ein Fehlerprotokoll, reproduziere den Fehler, notiere den Zeitpunkt und untersuche anschließend die dazu passenden Logeinträge.
Was bedeutet Debugging in WordPress? #
Debugging bezeichnet die systematische Suche nach Fehlern in einer Software oder Website.
Bei WordPress geht es beispielsweise darum herauszufinden, warum eine bestimmte Anfrage fehlschlägt, ein Plugin einen Fehler verursacht oder PHP die Verarbeitung einer Seite abbricht.
Statt lediglich verschiedene Einstellungen auszuprobieren, liefert Debugging technische Informationen über den tatsächlichen Ablauf.
Damit lässt sich eine Vermutung häufig in eine konkrete Diagnose verwandeln.
Wann ist WordPress Debugging sinnvoll? #
Debugging ist besonders hilfreich, wenn ein Problem reproduzierbar auftritt, die sichtbare Fehlermeldung aber keine ausreichende Erklärung liefert.
Das betrifft beispielsweise kritische WordPress-Fehler, HTTP-500-Fehler, Probleme nach einem Plugin- oder Theme-Update, Fehler nach einem PHP-Wechsel oder Funktionen, die plötzlich nicht mehr korrekt arbeiten.
Auch bei ungewöhnlichem Verhalten eines Plugins kann ein Log Hinweise liefern, selbst wenn die Website grundsätzlich weiterhin erreichbar ist.
Debugging ist nicht dasselbe wie Reparieren #
Ein Fehlerprotokoll behebt das Problem nicht automatisch.
Debugging hilft zunächst dabei, die Ursache zu identifizieren.
Wenn ein Log beispielsweise zeigt, dass ein fataler PHP-Fehler innerhalb eines bestimmten Plugins auftritt, muss anschließend geprüft werden, warum dieser Fehler entsteht und welche Lösung dafür geeignet ist.
Die Stärke des Debuggings liegt deshalb nicht in einer automatischen Reparatur, sondern in einer wesentlich präziseren Diagnose.
Vor Änderungen ein Backup erstellen #
Bevor du Konfigurationsdateien wie wp-config.php bearbeitest, sollte eine aktuelle Sicherung vorhanden sein.
Ein kleiner Syntaxfehler in einer PHP-Konfigurationsdatei kann dazu führen, dass WordPress nicht mehr korrekt geladen wird.
Bei komplexen oder geschäftskritischen Websites ist eine Staging-Umgebung für umfangreiche Debugging-Arbeiten grundsätzlich vorzuziehen.
Die Datei wp-config.php #
Die wichtigsten WordPress-Debugging-Einstellungen werden normalerweise in:
wp-config.php
definiert.
Diese Datei befindet sich üblicherweise im Hauptverzeichnis der WordPress-Installation beziehungsweise eine Ebene darüber, sofern die Installation entsprechend konfiguriert wurde.
Sie enthält zentrale Einstellungen der WordPress-Installation und sollte deshalb nur kontrolliert bearbeitet werden.
WP_DEBUG #
Die zentrale WordPress-Konstante für den Debug-Modus heißt:
WP_DEBUG
In einer normalen produktiven WordPress-Installation ist Debugging üblicherweise deaktiviert:
define( 'WP_DEBUG', false );
Für eine gezielte Diagnose kann es aktiviert werden:
define( 'WP_DEBUG', true );
Mit aktiviertem WP_DEBUG erhöht WordPress die PHP-Fehlerberichterstattung und erzeugt zusätzlich WordPress-spezifische Hinweise, beispielsweise zu veralteten Funktionen.
true und false nicht in Anführungszeichen setzen #
Bei den Debug-Konstanten sind true und false boolesche Werte.
Korrekt ist beispielsweise:
define( 'WP_DEBUG', false );
Nicht verwendet werden sollte:
define( 'WP_DEBUG', 'false' );
Die zweite Variante enthält eine Zeichenkette statt eines booleschen Werts und kann dadurch zu einem unerwarteten Ergebnis führen.
Wichtig: Bei WordPress-Konstanten sollte der Datentyp korrekt übernommen werden.
falseund'false'sind in PHP nicht dasselbe.
WP_DEBUG_LOG #
Mit:
WP_DEBUG_LOG
kann WordPress Debug-Meldungen in eine Datei schreiben.
Eine typische Konfiguration lautet:
define( 'WP_DEBUG_LOG', true );
Wenn WP_DEBUG_LOG auf true gesetzt und WP_DEBUG aktiviert ist, verwendet WordPress standardmäßig:
wp-content/debug.log
als Debug-Logdatei.
WP_DEBUG_LOG benötigt WP_DEBUG #
Ein wichtiger Zusammenhang wird häufig übersehen:
WP_DEBUG_LOG
arbeitet innerhalb des WordPress-Debug-Systems zusammen mit:
WP_DEBUG
Wenn WP_DEBUG nicht aktiviert ist, erzeugt das bloße Setzen von WP_DEBUG_LOG nicht das erwartete WordPress-Debug-Logging.
Eigener Pfad für WP_DEBUG_LOG #
WordPress kann für WP_DEBUG_LOG auch einen gültigen Dateipfad verwenden.
Das kann sinnvoll sein, wenn das Fehlerprotokoll nicht direkt innerhalb des öffentlich erreichbaren Website-Verzeichnisses gespeichert werden soll.
Welche Pfade in einer konkreten Hosting-Umgebung sinnvoll und beschreibbar sind, hängt von der Serverkonfiguration ab.
WP_DEBUG_DISPLAY #
Die Konstante:
WP_DEBUG_DISPLAY
steuert, ob Debug-Meldungen innerhalb der Website ausgegeben werden sollen.
Für eine produktive Website ist während einer Diagnose häufig folgende Kombination sinnvoller als eine öffentliche Fehlerausgabe:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Damit kann WordPress Fehler protokollieren, ohne sie absichtlich für Besucher auf der Website darzustellen.
Achtung: Detaillierte Fehlermeldungen können Dateipfade, technische Konfigurationen und andere interne Informationen enthalten. Sie sollten auf einer produktiven Website nicht dauerhaft öffentlich angezeigt werden.
display_errors zusätzlich berücksichtigen #
Die tatsächliche PHP-Fehlerausgabe kann zusätzlich durch die PHP-Konfiguration beeinflusst werden.
Für eine Diagnosekonfiguration kann deshalb ergänzend verwendet werden:
@ini_set( 'display_errors', 0 );
Eine mögliche Kombination lautet damit:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );Ob PHP-Einstellungen zur Laufzeit verändert werden dürfen, hängt allerdings von der Serverkonfiguration ab.
Wo gehört der Debug-Code in wp-config.php hin? #
Die Debug-Konstanten müssen definiert werden, bevor WordPress vollständig geladen wird.
In einer typischen wp-config.php befinden sie sich deshalb vor der bekannten Abschlusszeile beziehungsweise bevor wp-settings.php eingebunden wird.
Wenn bereits eine Definition wie:
define( 'WP_DEBUG', false );
vorhanden ist, solltest du nicht zusätzlich an einer anderen Stelle eine zweite widersprüchliche Definition anlegen.
Die debug.log finden #
Bei der Standardkonfiguration befindet sich die WordPress-Debugdatei unter:
wp-content/debug.log
Sie kann beispielsweise über den Dateimanager des Hostings oder einen geeigneten Dateiübertragungszugang eingesehen werden.
Die Datei muss nicht zwangsläufig bereits vorhanden sein. Sie wird benötigt beziehungsweise beschrieben, wenn entsprechende Meldungen protokolliert werden können.
Wenn keine debug.log erstellt wird #
Wenn trotz aktiviertem Debugging keine Datei erscheint, solltest du zunächst prüfen, ob tatsächlich ein protokollierbarer Fehler erzeugt wurde und ob die Debug-Konstanten korrekt gesetzt sind.
Zusätzlich können Dateirechte, der konfigurierte Log-Pfad und die Hosting- beziehungsweise PHP-Konfiguration eine Rolle spielen.
Ein fehlendes debug.log beweist deshalb nicht automatisch, dass WordPress fehlerfrei arbeitet.
Den Fehler gezielt reproduzieren #
Eine der effektivsten Methoden bei der Log-Analyse ist das kontrollierte Reproduzieren des Problems.
Wenn beispielsweise der Klick auf „Aktualisieren“ bei einer bestimmten Seite einen Fehler verursacht, öffne zunächst das Log beziehungsweise notiere dessen aktuellen Stand. Führe anschließend genau diese Aktion erneut aus.
Danach untersuchst du die neu hinzugekommenen Einträge.
Damit reduzierst du das Risiko, einen alten und längst nicht mehr relevanten Fehler mit dem aktuellen Problem zu verwechseln.
Zeitstempel sind entscheidend #
Auf einer länger betriebenen Website kann ein Fehlerprotokoll Einträge aus vielen unterschiedlichen Situationen enthalten.
Ein Fatal Error von gestern muss nichts mit dem Problem zu tun haben, das heute auftritt.
Notiere deshalb möglichst genau den Zeitpunkt, an dem du den Fehler reproduziert hast, und vergleiche diesen mit den Zeitstempeln im Log.
Praxis-Tipp: Reproduziere einen Fehler einmal kontrolliert und notiere die Uhrzeit. Dadurch lassen sich relevante Logeinträge wesentlich schneller von altem Protokollrauschen unterscheiden.
Wie liest man einen PHP-Fehler? #
Ein PHP-Fehler enthält häufig mehrere nützliche Bestandteile.
Besonders relevant sind Fehlertyp, Fehlermeldung, Dateipfad, Zeilennummer und Zeitstempel.
Ein vereinfachtes Beispiel könnte sinngemäß so aussehen:
PHP Fatal error: Uncaught Error ... in /wp-content/plugins/beispiel-plugin/datei.php on line 123
Damit weißt du bereits, dass PHP die Ausführung wegen eines fatalen Fehlers beendet hat und in welchem Codebereich der Fehler sichtbar wurde.
PHP Fatal error #
Ein:
PHP Fatal error
ist ein schwerwiegender Fehler, bei dem PHP die betreffende Ausführung nicht normal fortsetzen kann.
Solche Fehler können beispielsweise durch inkompatiblen Code, fehlende Funktionen oder Klassen, Speicherprobleme und andere schwerwiegende Programmfehler entstehen.
Ein Fatal Error ist deshalb bei einem HTTP-500-Fehler oder einer weissen Seite besonders relevant.
Uncaught Error und TypeError #
Meldungen wie:
Uncaught Error
oder:
TypeError
weisen auf Fehler während der PHP-Ausführung hin.
Ein TypeError kann beispielsweise entstehen, wenn Code einen Wert eines ungeeigneten Typs an eine Funktion übergibt.
Solche Fehler treten häufig bei Inkompatibilitäten oder fehlerhaftem Plugin-, Theme- oder individuellem Code auf.
Call to undefined function #
Eine Meldung wie:
Call to undefined function
bedeutet, dass PHP versucht hat, eine Funktion aufzurufen, die in diesem Ausführungskontext nicht verfügbar ist.
Mögliche Ursachen sind inkompatibler Code, eine fehlende Abhängigkeit oder eine nicht verfügbare PHP-Erweiterung.
Der Dateipfad und der Name der Funktion liefern wichtige Hinweise für die weitere Diagnose.
Class not found #
Eine Meldung wie:
Class ... not found
kann darauf hinweisen, dass erwarteter Programmcode nicht geladen wurde.
Das kann beispielsweise durch fehlende Dateien, Plugin-Abhängigkeiten, fehlerhafte Autoloading-Prozesse oder inkompatible Versionen entstehen.
Cannot redeclare #
Bei:
Cannot redeclare
wurde beispielsweise versucht, eine bereits vorhandene Funktion erneut zu deklarieren.
Das kann bei doppelt geladenem oder sich überschneidendem Code auftreten und ist deshalb auch bei Plugin- oder Theme-Konflikten interessant.
Allowed memory size exhausted #
Die Meldung:
Allowed memory size ... exhausted
zeigt, dass PHP während der Ausführung das erlaubte Speicherlimit erreicht hat.
Das bedeutet nicht automatisch, dass lediglich ein höheres Limit benötigt wird. Ein Plugin oder Prozess kann auch ungewöhnlich viel Speicher verbrauchen.
Die genaue Diagnose behandeln wir unter PHP Memory Limit in WordPress: Fehler erkennen und beheben.
Parse Error und Syntax Error #
Ein Syntaxfehler entsteht, wenn PHP-Code nicht korrekt aufgebaut ist.
Das kann beispielsweise nach einer manuellen Änderung an:
functions.php
oder:
wp-config.php
passieren.
Schon eine fehlende Klammer, ein falsches Zeichen oder ein fehlerhaftes Semikolon kann dazu führen, dass PHP die Datei nicht korrekt interpretieren kann.
Warning ist nicht dasselbe wie Fatal Error #
Ein:
PHP Warning
ist normalerweise weniger schwerwiegend als ein Fatal Error.
PHP kann die Ausführung je nach Situation trotz einer Warnung fortsetzen.
Warnings sollten trotzdem untersucht werden, insbesondere wenn sie häufig auftreten oder mit einer konkreten Fehlfunktion zusammenhängen.
Nicht jede Warning erklärt jedoch automatisch den Fehler, wegen dem du das Log geöffnet hast.
Notice richtig einordnen #
Notices weisen häufig auf problematischen oder unsauberen Code hin, ohne die Ausführung unmittelbar abzubrechen.
Bei aktiviertem WP_DEBUG können deshalb viele Meldungen sichtbar werden, obwohl die Website auf den ersten Blick funktioniert.
Die Menge der Meldungen darf nicht dazu verleiten, jeden Eintrag als gleich kritisch zu behandeln.
Deprecated-Meldungen #
WordPress und PHP können Hinweise zu veralteten Funktionen beziehungsweise Vorgehensweisen erzeugen.
Solche Meldungen enthalten häufig Begriffe wie:
Deprecated
Eine Deprecation bedeutet nicht zwangsläufig, dass die Funktion bereits nicht mehr funktioniert. Sie weist darauf hin, dass der betreffende Code veraltet ist und in zukünftigen Versionen problematisch werden kann.
Bei Plugins oder Themes sind viele neue Deprecated-Meldungen nach einem Versionswechsel deshalb ein Hinweis darauf, die betreffende Erweiterung auf Aktualität und Kompatibilität zu prüfen.
Die höchste Meldungszahl ist nicht automatisch das größte Problem #
Ein Plugin kann hunderte Notices erzeugen, während ein einzelner Fatal Error einer anderen Komponente die Website tatsächlich zum Absturz bringt.
Die Diagnose sollte deshalb nach Relevanz erfolgen und nicht lediglich danach, welche Meldung am häufigsten im Log erscheint.
Dateipfade richtig lesen #
Ein Dateipfad kann einen wichtigen Hinweis auf die beteiligte Komponente geben.
Ein Pfad innerhalb von:
wp-content/plugins/
führt zu einem Plugin.
Ein Pfad innerhalb von:
wp-content/themes/
führt zu einem Theme beziehungsweise Child-Theme.
Ein Pfad innerhalb von:
wp-admin/
oder:
wp-includes/
führt in den WordPress-Core.
Ein WordPress-Core-Pfad beweist keinen Core-Fehler #
Wenn eine Fehlermeldung eine Datei unter wp-includes nennt, bedeutet das nicht automatisch, dass WordPress selbst fehlerhaft ist.
Ein Plugin kann beispielsweise eine WordPress-Core-Funktion mit ungültigen Daten aufrufen. Der Fehler wird dann möglicherweise innerhalb der Core-Funktion sichtbar, obwohl die eigentliche Ursache außerhalb des WordPress-Cores liegt.
Der gesamte Fehlerkontext ist deshalb wichtiger als der letzte Dateipfad allein.
Stack Trace verstehen #
Bei schwerwiegenden Fehlern kann ein sogenannter Stack Trace protokolliert werden.
Er zeigt vereinfacht, welche Funktionen beziehungsweise Methoden aufgerufen wurden, bevor der Fehler entstanden ist.
Dadurch lässt sich nachvollziehen, wie PHP an die Stelle gelangt ist, an der die Ausführung abgebrochen wurde.
Für Entwickler und technischen Support kann ein Stack Trace deshalb wesentlich aussagekräftiger sein als nur die letzte Fehlerzeile.
Plugin- oder Theme-Konflikte mit Logs untersuchen #
Wenn ein Log wiederholt auf ein bestimmtes Plugin oder Theme verweist, ist diese Komponente ein sinnvoller Ausgangspunkt für die weitere Diagnose.
Sie sollte trotzdem kontrolliert getestet und nicht einfach gelöscht werden.
Unsere Vorgehensweise findest du unter Plugin- oder Theme-Konflikte in WordPress erkennen und beheben.
Fehler nach einem PHP-Wechsel #
Wenn unmittelbar nach dem Wechsel der PHP-Version neue Fatal Errors, TypeErrors oder Deprecated-Meldungen auftreten, sollte die Kompatibilität der beteiligten Komponenten geprüft werden.
Der Dateipfad im Error Log kann dabei helfen, ein veraltetes Plugin, Theme oder individuelles Snippet zu identifizieren.
Mehr dazu erklären wir unter PHP-Version für WordPress ändern und Kompatibilität prüfen.
WordPress debug.log und PHP Error Log sind nicht dasselbe #
Dieser Unterschied ist wichtig.
Die Datei:
wp-content/debug.log
entsteht durch das WordPress-Debug-Logging, wenn es entsprechend aktiviert wurde.
Die Hosting- beziehungsweise PHP-Umgebung kann zusätzlich eigene Error Logs führen.
Diese serverseitigen Logs können Fehler enthalten, die nicht oder nicht vollständig im WordPress-Debug-Log erscheinen.
Welches Log sollte zuerst geprüft werden? #
Wenn ein PHP- beziehungsweise Server-Error-Log über das Hosting verfügbar ist, ist dieses bei schweren PHP-Problemen häufig ein sehr guter Ausgangspunkt.
Es erfordert keine dauerhafte öffentliche Fehleranzeige und kann bereits den entscheidenden Fatal Error enthalten.
Wenn dort keine ausreichenden Informationen vorhanden sind, kann gezieltes WordPress-Debugging zusätzliche Details liefern.
HTTP 500 mit Logs diagnostizieren #
Bei einem HTTP-500-Fehler zeigt der Browser häufig nur eine allgemeine Serverfehlermeldung.
Der Error Log kann dagegen den zugrunde liegenden PHP-Fatal-Error, einen Speicherfehler oder andere serverseitige Probleme enthalten.
Die vollständige Vorgehensweise findest du unter Fehler 500 in WordPress beheben.
Kritischen WordPress-Fehler untersuchen #
WordPress kann bei bestimmten fatalen PHP-Fehlern eine Meldung über einen kritischen Fehler anzeigen und gegebenenfalls Recovery Mode anbieten.
Auch hier können Logs zusätzliche Informationen darüber liefern, welche Komponente den Fehler ausgelöst hat.
Die entsprechenden Wiederherstellungsschritte erklären wir unter WordPress zeigt eine weisse Seite oder einen kritischen Fehler: Was tun?.
AJAX-Fehler protokollieren #
Ein Vorteil von WP_DEBUG_LOG besteht darin, dass Fehler protokolliert werden können, die nicht auf einer normalen sichtbaren Seite erscheinen.
Das ist beispielsweise bei AJAX-Anfragen hilfreich.
Wenn ein WordPress-Editor, Formular oder Plugin eine AJAX-Anfrage verwendet und diese serverseitig fehlschlägt, kann ein Log Hinweise auf den PHP-Fehler liefern.
WP-Cron und Hintergrundprozesse #
Auch Fehler während geplanter WordPress-Aufgaben können schwierig zu erkennen sein, weil kein Besucher unmittelbar eine entsprechende Fehlermeldung sieht.
Logging ist deshalb auch bei WP-Cron und anderen Hintergrundprozessen hilfreich.
Wenn ein geplanter Prozess immer wieder fehlschlägt, sollten Zeitstempel und wiederkehrende Fehlermuster untersucht werden.
REST-API-Fehler #
Moderne WordPress-Funktionen und Plugins verwenden häufig die REST API.
Ein serverseitiger PHP-Fehler während einer REST-Anfrage erscheint möglicherweise nicht als normale Fehlermeldung innerhalb einer sichtbaren WordPress-Seite.
Auch hier können Logs wesentlich mehr Informationen liefern als die Benutzeroberfläche.
JavaScript-Fehler stehen nicht zwingend im PHP-Log #
WordPress-Debugging und PHP Error Logs konzentrieren sich auf serverseitige Vorgänge.
Wenn beispielsweise ein Menü, Slider oder Button im Browser nicht reagiert, kann die Ursache stattdessen in JavaScript liegen.
Solche Fehler werden häufig über die Entwicklerwerkzeuge des Browsers untersucht.
Ein leeres PHP-Error-Log beweist deshalb nicht, dass auf einer Website keinerlei technischer Fehler existiert.
CSS-Probleme stehen normalerweise ebenfalls nicht im PHP-Log #
Ein falsch dargestelltes Element kann durch CSS verursacht werden, obwohl PHP vollständig fehlerfrei arbeitet.
Wenn eine Website technisch funktioniert, aber beispielsweise Abstände, Farben oder Layout falsch dargestellt werden, sind die Browser-Entwicklerwerkzeuge häufig das geeignetere Diagnosewerkzeug.
Datenbankfehler #
Auch Datenbankprobleme können technische Fehler verursachen.
Bei aktiviertem WordPress-Debugging können zusätzliche Informationen zu Datenbankfehlern sichtbar beziehungsweise protokolliert werden.
Ein Fehler in einer SQL-Abfrage sollte allerdings nicht automatisch durch manuelle Änderungen an der Datenbank „repariert“ werden. Zunächst sollte festgestellt werden, welche Komponente die problematische Abfrage erzeugt.
Debugging kann die Website selbst beeinflussen #
Umfangreiches Logging erzeugt zusätzliche Dateioperationen.
Wenn eine Website pro Anfrage sehr viele Warnings oder Notices produziert, kann eine aktivierte Protokollierung eine große Menge an Daten schreiben.
Debugging sollte deshalb als Diagnosewerkzeug und nicht als dauerhaft eingeschalteter Normalzustand einer produktiven Website betrachtet werden.
Eine debug.log kann sehr groß werden #
Wenn derselbe Fehler bei jedem Seitenaufruf mehrfach protokolliert wird, kann:
wp-content/debug.log
innerhalb kurzer Zeit stark anwachsen.
Das beansprucht Speicherplatz und erschwert zusätzlich die Auswertung.
Nach einer Diagnose solltest du deshalb prüfen, ob das Debugging wieder deaktiviert wurde und ob eine nicht mehr benötigte Logdatei sicher entfernt werden kann.
Logs können sensible Informationen enthalten #
Fehlerprotokolle können interne Dateipfade, technische Konfigurationen, Abfrageinformationen und je nach fehlerhafter Anwendung weitere Daten enthalten.
Behandle Logs deshalb nicht wie öffentlich zugängliche Textdateien.
Wenn ein Log an Support oder einen Entwickler weitergegeben wird, sollte nur der für die Diagnose erforderliche Ausschnitt übermittelt und vorher geprüft werden, ob darin sensible Daten enthalten sind.
Achtung: Veröffentliche vollständige Debug-Logs nicht ungeprüft in öffentlichen Foren, Tickets oder sozialen Netzwerken. Kontrolliere zuerst, welche Informationen darin enthalten sind.
debug.log im öffentlich erreichbaren Verzeichnis #
Der Standardpfad:
wp-content/debug.log
liegt innerhalb der WordPress-Verzeichnisstruktur.
Abhängig von der Webserver-Konfiguration kann eine dort abgelegte Datei potenziell über HTTP erreichbar sein. WordPress weist deshalb selbst darauf hin, dass öffentlich erreichbare Fehlerprotokolle ein Sicherheitsrisiko darstellen können.
Auf produktiven Umgebungen sollte Logging daher kontrolliert eingesetzt und die Logdatei nach Abschluss der Diagnose nicht unnötig bestehen gelassen werden.
Debugging nach der Fehlersuche wieder deaktivieren #
Nach Abschluss der Diagnose sollte eine produktive Website wieder in eine normale Konfiguration versetzt werden.
Eine einfache WordPress-Konfiguration kann beispielsweise wieder:
define( 'WP_DEBUG', false );
verwenden.
Wenn zusätzliche Debug-Konstanten nur für die Diagnose ergänzt wurden, sollte geprüft werden, ob sie weiterhin benötigt werden.
Debug-Log nach der Diagnose behandeln #
Wenn die Logdatei nicht mehr benötigt wird, kann sie nach Sicherung eventuell relevanter Informationen entfernt werden.
Wird Debug-Logging später erneut aktiviert, kann WordPress beziehungsweise PHP wieder neue Meldungen protokollieren.
Das Entfernen einer alten Logdatei behebt allerdings keine Ursache. Es dient lediglich dazu, nicht mehr benötigte Diagnoseinformationen zu entfernen.
Alte Fehler nicht mit aktuellen Problemen verwechseln #
Eine vorhandene debug.log kann Meldungen enthalten, die Wochen oder Monate alt sind.
Wenn eine Website heute einen Fehler zeigt, sollte deshalb nicht automatisch der auffälligste alte Fatal Error als Ursache angenommen werden.
Der Vergleich mit dem aktuellen Zeitpunkt ist entscheidend.
Wiederkehrende Fehlermuster erkennen #
Wenn derselbe Fehler immer wieder zu bestimmten Zeiten auftritt, kann das auf einen geplanten Prozess hinweisen.
Beispielsweise können Cronjobs, Backups, Imports oder Sicherheits-Scans regelmäßig bestimmte Funktionen ausführen.
Ein zeitliches Muster im Log kann deshalb einen wichtigen Hinweis liefern, auch wenn die Website zwischen diesen Ereignissen normal funktioniert.
Logs vor und nach einer Änderung vergleichen #
Bei einer kontrollierten Diagnose solltest du möglichst nur eine relevante Variable gleichzeitig verändern.
Wenn beispielsweise ein Plugin deaktiviert wird, reproduziere anschließend den Fehler erneut und vergleiche die neuen Logeinträge.
Verschwindet der Fehler, ist das eine wesentlich stärkere Information als eine zufällige Änderung von fünf verschiedenen Einstellungen gleichzeitig.
Debugging bei einer langsamen WordPress-Website #
Ein Error Log ist kein vollständiges Performance-Analysewerkzeug.
Es kann jedoch Hinweise auf Prozesse liefern, die ständig Fehler oder Warnungen erzeugen und dadurch zusätzliche Last verursachen.
Für eine vollständige Performance-Diagnose müssen zusätzlich PHP-Verarbeitung, Datenbank, Plugins, Frontend-Ressourcen und Hosting-Ressourcen betrachtet werden.
Die Vorgehensweise erklären wir unter WordPress ist langsam: Ursachen finden und Ladezeit verbessern.
Query Monitor und ähnliche Diagnosewerkzeuge #
Für weitergehende Analysen existieren WordPress-Plugins, die zusätzliche technische Informationen darstellen können.
Ein bekanntes Werkzeug ist beispielsweise Query Monitor. Damit können unter anderem Datenbankabfragen, PHP-Fehler, Hooks, HTTP-API-Aufrufe und weitere Informationen während einer Anfrage untersucht werden.
Solche Werkzeuge richten sich vor allem an Entwickler und technisch erfahrene Benutzer.
Sie sollten nicht dauerhaft nur deshalb installiert und aktiviert bleiben, weil eine Website irgendwann einmal einen Fehler hatte.
SCRIPT_DEBUG ist nicht dasselbe wie WP_DEBUG #
WordPress kennt zusätzlich:
SCRIPT_DEBUG
Diese Konstante ist nicht mit WP_DEBUG gleichzusetzen.
Sie wird insbesondere bei der Entwicklung und Diagnose von WordPress-Core-JavaScript- beziehungsweise CSS-Dateien verwendet und ist für eine normale PHP-Fehlersuche in der Regel nicht erforderlich.
SAVEQUERIES nur gezielt verwenden #
Für Datenbankdiagnosen existiert außerdem:
SAVEQUERIES
Damit können Informationen zu Datenbankabfragen gesammelt werden.
Diese Funktion erzeugt zusätzlichen Speicher- und Performance-Aufwand und sollte deshalb nur gezielt zur Diagnose eingesetzt werden.
Für normale WordPress-Benutzer ist sie bei einer üblichen Fehlersuche normalerweise nicht der erste Schritt.
Debugging auf Staging und Produktion unterscheiden #
Auf einer Entwicklungs- oder Staging-Umgebung können ausführliche Diagnoseinformationen sinnvoll sein, weil dort keine normalen Besucher betroffen sind.
Auf einer produktiven Website muss dagegen stärker darauf geachtet werden, dass technische Informationen nicht öffentlich ausgegeben werden und das Logging nur so lange wie nötig aktiv bleibt.
Die gleiche Debug-Konfiguration ist deshalb nicht automatisch für jede Umgebung geeignet.
Was du beim Debugging besser nicht tun solltest #
Aktiviere nicht einfach die öffentliche Ausgabe sämtlicher PHP-Fehler auf einer produktiven Website und lasse diese Einstellung anschließend dauerhaft bestehen.
Ändere außerdem nicht gleichzeitig mehrere Plugins, das Theme, PHP und die WordPress-Konfiguration. Dadurch wird schwer nachvollziehbar, welche Änderung den Fehler tatsächlich beeinflusst hat.
Lösche nicht sofort eine Komponente nur deshalb, weil ihr Dateipfad in einem Log erscheint. Prüfe zunächst den Zusammenhang und reproduziere den Fehler kontrolliert.
Und sende vollständige Logdateien nicht ungeprüft an beliebige Dritte.
Grundregel: Fehler reproduzieren, Zeitpunkt notieren, relevante Logeinträge identifizieren und erst danach eine gezielte Änderung vornehmen. Anschließend denselben Fehler erneut testen. So wird aus Ausprobieren eine nachvollziehbare technische Diagnose.
Welche Informationen helfen dem CURIAWEB-Support? #
Wenn du CURIAWEB wegen eines WordPress-Fehlers kontaktierst, beschreibe zunächst, welche Aktion den Fehler auslöst und wann er zuletzt aufgetreten ist.
Ein relevanter Logausschnitt mit Zeitstempel ist wesentlich hilfreicher als eine vollständige Datei mit tausenden älteren Meldungen.
Wenn ein Fatal Error vorhanden ist, sollte die vollständige zugehörige Fehlermeldung einschließlich Dateipfad und gegebenenfalls Stack Trace übermittelt werden.
Teile außerdem mit, ob unmittelbar zuvor WordPress, ein Plugin, das Theme, PHP oder individueller Code verändert wurde.
Entferne beziehungsweise schwärze sensible Informationen, falls sie für die Diagnose nicht benötigt werden. Passwörter solltest du niemals unaufgefordert in einem Fehlerprotokoll oder Support-Ticket mitsenden.
Zusammenfassung #
WordPress Debugging und Fehlerprotokolle gehören zu den wichtigsten Werkzeugen für eine systematische technische Fehlersuche. Statt lediglich aufgrund einer sichtbaren Fehlermeldung zu raten, können Logs zeigen, welcher Fehler tatsächlich aufgetreten ist, wann er entstand und welcher Codebereich beteiligt war.
Die zentrale Einstellung WP_DEBUG aktiviert den WordPress-Debug-Modus. Mit WP_DEBUG_LOG können Meldungen protokolliert werden, während WP_DEBUG_DISPLAY steuert, ob diese Informationen auf der Website angezeigt werden.
Auf einer produktiven Website ist es normalerweise sinnvoller, Fehler kontrolliert zu protokollieren, statt technische Details öffentlich auszugeben. Die standardmäßige WordPress-Debugdatei wp-content/debug.log sollte außerdem als potenziell sensible Datei behandelt werden.
Bei der Auswertung sind Fehlertyp, Zeitstempel, Dateipfad und gegebenenfalls Stack Trace besonders wichtig. Ein Dateipfad liefert einen Hinweis, beweist aber nicht immer allein, welche Komponente die eigentliche Ursache ist.
Nach Abschluss der Diagnose sollte Debugging auf einer produktiven Website wieder passend deaktiviert und eine nicht mehr benötigte Logdatei entfernt beziehungsweise sicher behandelt werden.
Die wichtigste Methode bleibt dabei einfach: Fehler reproduzieren, Log prüfen, Ursache eingrenzen, eine gezielte Änderung durchführen und anschließend erneut testen.
