Debugging: WP_DEBUG, Logs, Query Monitor

Eine Website macht Probleme – und die erste Reaktion ist oft Raten: ein Plugin deaktivieren, den Cache leeren, das Theme wechseln. Manchmal hilft das, meist kostet es Zeit und verändert nebenbei Dinge, die vorher in Ordnung waren. Professionelle Fehlersuche geht anders: erst Informationen sammeln, dann eine Vermutung bilden, dann gezielt prüfen. WordPress bringt dafür alles mit, was nötig ist. Diese Lektion zeigt die Werkzeuge und eine Reihenfolge, die Sie bei fast jedem Problem zum Ziel führt.

1. Die Debug-Konstanten

Wichtig ist die Unterscheidung zwischen Protokollieren und Anzeigen. Auf einer Live-Website dürfen Fehler niemals sichtbar sein: Sie verraten Serverpfade, Versionsnummern und manchmal Datenbankdetails – wertvolle Informationen für Angreifer. Sie gehören ins Protokoll, das nur Sie lesen. Probieren Sie die Kombinationen aus:

1<?php
2define( 'WP_DEBUG', true );
3define( 'WP_DEBUG_LOG', true );
4define( 'WP_DEBUG_DISPLAY', false );
5@ini_set( 'display_errors', 0 );
6define( 'SCRIPT_DEBUG', false );

Das Protokoll liegt standardmäßig in wp-content/debug.log. Weil diese Datei über das Internet erreichbar sein kann, verschieben viele Betreiber sie mit der Konstante WP_DEBUG_LOG an einen Pfad außerhalb des öffentlichen Ordners. Nach der Fehlersuche wird das Protokoll gelöscht und der Debug-Modus wieder ausgeschaltet – sonst wächst die Datei unbemerkt auf Gigabyte an.

2. Protokolle lesen

Eine Protokollzeile beantwortet drei Fragen: Wie schwer ist der Fehler, wo tritt er auf und was genau ist passiert. Fatale Fehler brechen die Ausführung ab, Warnungen und Hinweise nicht. Entscheidend ist der Dateipfad: Steht dort ein Plugin- oder Theme-Ordner, ist die Ursache meist dort zu suchen – auch wenn die Meldung auf eine Datei des Kerns zeigt, denn WordPress selbst ist selten schuld. Klicken Sie die Zeilen an:

3. Query Monitor

Das kostenlose Plugin Query Monitor ist das wichtigste Werkzeug zur Fehlersuche in WordPress. Es blendet in der Adminleiste eine Übersicht ein, die den aktuellen Seitenaufruf durchleuchtet: alle Datenbankabfragen mit Laufzeit und Herkunft, alle geladenen Skripte und Stile, ausgelöste Hooks, HTTP-Anfragen an fremde Server, PHP-Fehler und die Frage, welche Vorlage gerade verwendet wird. Klicken Sie sich durch die Bereiche:

4. Eine feste Reihenfolge

5. Werkzeuge auf der Kommandozeile

Wer Zugriff per SSH hat, arbeitet mit WP-CLI oft schneller. Der Befehl wp plugin list zeigt alle Plugins mit Status und verfügbaren Updates, wp option get liest Einstellungen, wp db query führt Abfragen aus, und wp cron event list zeigt geplante Aufgaben. Besonders nützlich bei einem weißen Bildschirm: Die Kommandozeile funktioniert meist noch, wenn die Website nicht mehr lädt, und wp plugin deactivate --all bringt eine Website in Sekunden wieder zum Laufen. Auch das Protokoll lässt sich dort live beobachten, etwa mit dem Befehl tail -f auf die Protokolldatei, während man den Fehler im Browser auslöst.

6. Häufige Fragen

Ich habe den Debug-Modus eingeschaltet, aber es wird kein Protokoll geschrieben. Häufige Ursachen: Ein Caching- oder Sicherheits-Plugin setzt die Konstanten erneut, wp-config.php wurde nach der Zeile mit „Das war’s, Schluss mit dem Bearbeiten“ ergänzt, oder der Ordner wp-content ist nicht beschreibbar. Prüfen Sie mit einer kurzen Ausgabe, welchen Wert WP_DEBUG tatsächlich hat.

Der Fehler tritt nur bei einem bestimmten Kunden auf. Dann liegt es meist an Rolle, Browser, Sprache oder Cache. Legen Sie ein Testkonto mit derselben Rolle an und stellen Sie den Fehler damit nach. Auch Browser-Erweiterungen wie Werbeblocker können Skripte blockieren.

Darf ich Query Monitor auf einer Live-Website installieren? Ja. Die Ausgabe sehen nur angemeldete Personen mit der Berechtigung view_query_monitor, standardmäßig Administratoren. Trotzdem sollte es nicht dauerhaft aktiv bleiben, da es jeden Aufruf etwas verlangsamt.

7. Übung zum Selbermachen

Bauen Sie in einer Testumgebung absichtlich einen Fehler ein: Rufen Sie in einem kleinen Plugin eine Funktion auf, die es nicht gibt. Schalten Sie WP_DEBUG mit Protokoll ein, laden Sie die Seite und lesen Sie die Zeile im debug.log. Ergänzen Sie dann eine Zeile, die auf einen nicht vorhandenen Array-Schlüssel zugreift, und vergleichen Sie, wie sich Warnung und fataler Fehler unterscheiden. Installieren Sie danach Query Monitor und finden Sie heraus, welche Vorlage Ihre Startseite verwendet und wie viele Datenbankabfragen sie auslöst.

Stand: September 2026, WordPress 7.1, PHP 8.3. Kursmaterial der Klarwerk Akademie. WordPress entwickelt sich schnell – maßgeblich ist die aktuelle Dokumentation auf developer.wordpress.org.