WordPress Debug-Modus aktivieren: loggen statt anzeigen

Der WordPress Debug-Modus ist der eingebaute Weg, um während der Entwicklung oder Fehlersuche zu sehen, was im Hintergrund schiefläuft. PHP ist die Programmiersprache, auf der WordPress läuft, und genau ihre Meldungen fängt der Debug-Modus ab. Ist er aktiv, macht WordPress alle PHP-Meldungen sichtbar oder protokollierbar: Fatal Errors, Warnings, Notices und Deprecated-Hinweise auf veraltete Funktionen. Statt zu raten, welches Plugin oder Theme ein Problem verursacht, bekommen Sie den genauen Dateinamen und die Zeilennummer geliefert.

Im Alltag brauchen Sie diese Meldungen nicht, deshalb ist der Debug-Modus im Standard ausgeschaltet: Die Konstante WP_DEBUG steht ab Werk auf false. Erst wenn Sie sie auf true setzen, beginnt WordPress zu berichten. Wer nach dem englischen Begriff sucht, meint dasselbe: den WordPress Debug Mode. Alle offiziellen Details liefert die offizielle WordPress-Debugging-Dokumentation.

Der Standardweg führt über die wp-config.php im Hauptverzeichnis Ihrer Installation. Diese Datei erreichen Sie per FTP oder über den Dateimanager in Ihrem Hosting-Panel. Sie brauchen kein Plugin, drei bis vier Zeilen genügen. So aktivieren Sie den Debug-Modus in WordPress sicher:

// WP_DEBUG-Modus aktivieren
define( 'WP_DEBUG', true );

// Fehler in wp-content/debug.log schreiben
define( 'WP_DEBUG_LOG', true );

// Fehleranzeige auf der Seite deaktivieren
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Jede Zeile beginnt mit define(), der Funktion, mit der WordPress solche Konstanten setzt. Achtung: Nur define('WP_DEBUG', true); allein ist die Falle. Dann landen alle Fehler sichtbar auf Ihrer Seite. Warum das gefährlich ist, sehen Sie gleich.

WordPress kennt mehrere Debug-Konstanten. Jede steuert einen anderen Teil der Fehlersuche. Die folgende Tabelle zeigt, was sie tun und ob sie auf einer Live-Seite etwas zu suchen haben:

Am wichtigsten ist das Zusammenspiel der beiden Log-Konstanten, also das WordPress Debug Log über WP_DEBUG_LOG und die Anzeige über WP_DEBUG_DISPLAY. WP_DEBUG_LOG schreibt Fehler still in wp-content/debug.log, WP_DEBUG_DISPLAY zeigt sie im Browser. Für sicheres Debuggen wird das erste an- und das zweite ausgeschaltet. Alle Konstanten samt Werten stehen in der wp-config.php-Konstanten-Referenz.

Hier ist der Punkt, an dem die meisten Anleitungen zu kurz greifen. Die Konstante WP_DEBUG_DISPLAY steht per Default auf true. Wer also nur define('WP_DEBUG', true); setzt und sonst nichts ändert, lässt WordPress die Fehler offen anzeigen, mitten auf der Live-Seite. Jeder Besucher, der die betroffene Seite aufruft, liest die vollständige Fehlermeldung mit.

Und da wird es zum echten Problem, aus reiner Entwickler-Hygiene-Sicht. Eine offene PHP-Fehlermeldung verrät erstaunlich viel: absolute Serverpfade wie /var/www/..., die Namen der beteiligten Plugins und Themes samt Versionsnummern und oft auch das Tabellenpräfix Ihrer Datenbank. Das ist genau die Art von Information, die jemand sammelt, bevor er eine bekannte Schwachstelle gezielt ausnutzt. Ich bin PHP-Entwickler, kein Security-Analyst, aber diese Zeilen schließe ich aus Prinzip.

Die Lösung steht schon in der sicheren Konfiguration von oben: WP_DEBUG_DISPLAY auf false. Zur Sicherheit kommt @ini_set('display_errors', 0); dazu, das ist der Gürtel zum Hosenträger und unterdrückt die Anzeige auch dann, wenn eine Server-Einstellung sich querstellt. Die Gegenüberstellung macht den Unterschied deutlich:

❌ Gefährlich auf einer Live-Seite (zeigt Fehler offen im Frontend):

// WP_DEBUG_DISPLAY ist per Default true, Fehler erscheinen sichtbar auf der Seite
define( 'WP_DEBUG', true );

✅ Sicher (loggen statt anzeigen):

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Wenn eine Fehlermeldung auf ein tieferes Problem deutet oder Ihre Seite bereits Schaden genommen hat, können Sie Ihre Website professionell reparieren lassen.

Die protokollierten Fehler landen standardmäßig in der Datei wp-content/debug.log. Dort sammelt WordPress jede Meldung mit Zeitstempel, Dateipfad und Zeilennummer, ordentlich untereinander. Das eigentliche Entschlüsseln der Einträge ist ein Thema für sich: Wie Sie diese Zeilen lesen und häufige Fehlermeldungen deuten, zeigt der Artikel WordPress Error-Logs finden und verstehen.

Der Debug-Modus liefert damit das Rohmaterial; die eigentliche Diagnose ist der nächste Schritt. Je nachdem, was im Log steht, geht es gezielt weiter:

• Meldet WordPress „Es gab einen kritischen Fehler auf deiner Website", hilft der Ratgeber kritischen Fehler in WordPress beheben.
• Bleibt die Seite komplett leer, führt Sie der Ratgeber weiße Seite (White Screen) beheben weiter.
• Steht im Log ein Datenbankproblem, ist der Ratgeber Fehler beim Aufbau der Datenbankverbindung die richtige Anlaufstelle.

Sobald der Fehler gefunden ist, gehört der Debug-Modus wieder aus. Setzen Sie dazu WP_DEBUG in der wp-config.php zurück auf false:

// Debug-Modus deaktivieren
define( 'WP_DEBUG', false );

Danach löschen oder leeren Sie die Datei wp-content/debug.log. Sie hat ihren Zweck erfüllt und würde sonst weiter mitschreiben und dabei nach und nach sensible Pfad- und Fehlerdetails ansammeln, die auf einer Live-Seite nichts zu suchen haben. Das Deaktivieren erfolgt genauso wie das Aktivieren: direkt in der wp-config.php, ganz ohne Plugin. Hinterlassen Sie die Produktion sauber.