Für eine sichere Fehlerdiagnose setzen Sie in der wp-config.php genau drei Zeilen: define('WP_DEBUG', true);, define('WP_DEBUG_LOG', true); und define('WP_DEBUG_DISPLAY', false);. Diese Kombination schreibt alle Fehler in die Datei /wp-content/debug.log, zeigt sie aber keinem Besucher an. Wichtig: WP_DEBUG_DISPLAY darf auf produktiven Websites niemals auf true stehen, denn das legt technische Details offen.
Kurz gesagt:
- Laden Sie vor Änderungen eine Sicherung der wp-config.php herunter, ersetzen Sie vorhandene Konstanten statt sie doppelt anzulegen und setzen Sie neue Zeilen vor den Bearbeitungshinweis.
- Seit WordPress 5.1 können Sie WP_DEBUG_LOG auf einen eigenen Pfad außerhalb des öffentlich erreichbaren Websiteverzeichnisses setzen; ohne Schreibrechte bleibt das Protokoll leer.
- Query Monitor zeigt Datenbankabfragen, Hooks und Serveranfragen im Administrationsbereich; auf Livewebsites sollten Sie solche Erweiterungen nur kurz und mit begrenztem Zugriff einsetzen.
- Seit WordPress 5.2 reagiert der Wiederherstellungsmodus auf fatale Fehler, sendet der Administration eine E-Mail und deaktiviert das auslösende Plugin oder Theme vorübergehend.
- Bei Aufrufen über Hintergrundprozesse oder Schnittstellen erscheinen Fehler oft nur im Protokoll; entfernen Sie vor der Weitergabe der Datei an Dritte alle Zugangsdaten.
Inhaltsverzeichnis
- Wp-config.php richtig bearbeiten, ohne neue Fehler zu erzeugen
- Debug-Modus über das Hosting-Dashboard einschalten
- Query Monitor, WP Debugging und weitere Analyse-Werkzeuge
- Debug.log lesen und Recovery Mode richtig nutzen
- Sichere Konfiguration für Produktion und Staging
- Wie wir bei Debugging, Wartung und Sicherheit unterstützen
- FAQ
- Quellen
Wp-config.php richtig bearbeiten, ohne neue Fehler zu erzeugen
Bevor Sie etwas ändern, sichern Sie die Datei. Ein einfacher Download der aktuellen wp-config.php reicht, und für die Bearbeitung eignet sich ein Editor, der UTF-8 ohne BOM speichert, etwa Visual Studio Code oder Sublime Text.
Gehen Sie dann so vor:
- Öffnen Sie die
wp-config.phpim Stammverzeichnis Ihrer Installation. - Suchen Sie die Zeile
/* That's all, stop editing! */. - Fügen Sie die drei Konstanten direkt davor ein.
- Prüfen Sie, ob
WP_DEBUGbereits weiter oben definiert ist, und überschreiben Sie diese Zeile, statt eine zweite hinzuzufügen. - Speichern Sie die Datei und laden Sie eine Seite neu, um zu testen.
Mehrfachdefinitionen derselben Konstante führen zu einem PHP-Fehler, weil define() einen Wert nur einmal setzen kann. Die offizielle Debugging-Dokumentation empfiehlt deshalb, vorhandene Zeilen zu bearbeiten statt zu duplizieren. Seit WordPress 5.1 kann WP_DEBUG_LOG auch einen eigenen Dateipfad erhalten, etwa define('WP_DEBUG_LOG', '/var/log/wp-debug.log');, um das Log außerhalb des Webroots zu speichern.
Zum Schluss lohnt ein Blick auf die Dateirechte: Der Webserver-Benutzer muss Schreibzugriff auf das Verzeichnis haben, in dem die Logdatei entstehen soll, sonst bleibt sie leer, ohne dass eine Fehlermeldung erscheint.
Profi-Tipp: Testen Sie die neue Konfiguration immer erst auf einer Staging-Kopie, bevor Sie sie live schalten.
Debug-Modus über das Hosting-Dashboard einschalten
Viele Managed-WordPress-Hoster bieten einen Schalter fürs Debugging direkt im Kundenbereich an, ohne dass Sie die wp-config.php selbst anfassen müssen. Der Ablauf ähnelt sich bei den meisten Anbietern:
- Website im Dashboard auswählen und den Menüpunkt für Entwicklertools oder Debugging öffnen.
- Debug-Modus aktivieren und Optionen wie Logging oder Anzeige getrennt konfigurieren.
- Einstellungen speichern und die Änderung mit einem Seitenaufruf bestätigen.
Der Unterschied zur manuellen Methode: Der Hoster passt die Konstanten automatisiert an, oft über eine eigene Konfigurationsschicht statt direkt in Ihrer Datei. Prüfen Sie danach trotzdem Besitzverhältnisse und Schreibrechte der erzeugten Logdatei. Fehlt ein solcher Schalter, bleibt der Weg über FTP oder SSH mit direktem Zugriff auf die wp-config.php. Viele Staging-Umgebungen setzen zudem automatisch WP_ENVIRONMENT_TYPE auf staging, wodurch WordPress in Entwicklungsumgebungen eigenständig großzügigere Debug-Einstellungen zulässt.
Query Monitor, WP Debugging und weitere Analyse-Werkzeuge
Reines Logging reicht oft nicht, wenn Sie wissen wollen, welche Datenbankabfrage oder welcher Hook einen Fehler auslöst. Dafür gibt es spezialisierte Plugins:
- Query Monitor zeigt Datenbankabfragen, aktive Hooks, HTTP-Requests und PHP-Fehler direkt in der Admin-Leiste an, ideal für Performance-Analysen.
- WP Debugging setzt die nötigen Konstanten automatisiert und entfernt sie beim Deaktivieren wieder, praktisch für schnelle Tests ohne manuelle Config-Änderung.
- Debug Bar und die Erweiterung Debug Bar Console liefern zusätzliche Admin-Informationen und erlauben das direkte Ausführen von PHP-Schnipseln zur Fehlersuche.
Query Monitor ist ein sehr verbreitetes Plugin im WordPress-Ökosystem und gehört damit zu den verbreitetsten Debugging-Werkzeugen im WordPress-Ökosystem. Auf produktiven Websites sollten solche Plugins nur kurzzeitig und idealerweise mit eingeschränktem Benutzerzugriff laufen, denn sie zeigen teils sensible Systeminformationen und können die Ladezeit spürbar erhöhen.
Debug.log lesen und Recovery Mode richtig nutzen
Sobald Logging aktiv ist, landen neue Einträge laufend unter /wp-content/debug.log. Für die Auswertung hilft diese Vorgehensweise:
- Datei per FTP, SSH oder Hosting-Dateimanager öffnen und nach Zeitstempel sortieren.
- Einträge nach Typ unterscheiden: Fatal error stoppt die Ausführung, Warning deutet auf einen funktionsfähigen, aber fehlerhaften Code hin, Notice betrifft meist unsaubere, aber unkritische Stellen.
- Bei AJAX-, REST- oder Cron-Anfragen besonders aufmerksam sein, denn Fehler erscheinen dort oft nicht im Browser, sondern ausschließlich im Log.
- Vor jeder Weitergabe an Dritte sensible Inhalte wie Zugangsdaten aus der Logdatei entfernen.
Bei einem fatalen Fehler greift seit WordPress 5.2 zusätzlich der Recovery Mode: Das System sendet eine E-Mail an die Administration und deaktiviert das auslösende Plugin oder Theme vorübergehend, sodass die Website erreichbar bleibt. Die Funktion wp_is_recovery_mode() lässt sich im eigenen Code prüfen, um Recovery-Situationen gezielt abzufangen. Recovery Mode ersetzt dabei kein tiefes Logging, liefert aber oft die schnellere erste Reaktion auf einen White Screen, wie wir ihn auch in unserem Beitrag zum WordPress White Screen beschreiben.
Sichere Konfiguration für Produktion und Staging
Auf einer Live-Website gilt eine einfache Regel: Logging an, Anzeige aus. WP_DEBUG_DISPLAY bleibt auf false, während WP_DEBUG_LOG Fehler weiterhin protokolliert. Die Logdatei selbst gehört idealerweise außerhalb des Webroots oder zumindest durch eine .htaccess-Regel und restriktive Dateiberechtigungen abgesichert, üblich sind hier Rechte wie 600, damit nur der Besitzer lesen kann.
Mit WP_ENVIRONMENT_TYPE trennen Sie Umgebungen sauber: lokal, Staging und Produktion erhalten jeweils eigene Debug-Regeln, ohne dass Sie bei jedem Deployment manuell nachjustieren müssen. Ein bewährter Workflow sieht so aus: Backup erstellen, auf einer Staging-Umgebung debuggen, den Fehler reproduzieren, den Fix einspielen und das Debugging danach wieder deaktivieren.
Profi-Tipp: Dokumentieren Sie jede aktivierte Debug-Einstellung, damit niemand im Team vergisst, sie nach dem Fix wieder abzuschalten.
Wer technische Hintergründe zu PHP-Fehlermeldungen vertiefen möchte, findet in unserem Beitrag PHP in WordPress verständlich erklärt weitere Einordnung. Zeigen Logs zusätzlich Performance-Probleme, etwa durch langsame Datenbankabfragen, lohnt ein Blick in den Beitrag zu den drei Performance-Hebeln für KMU unseres Partners.
Wie wir bei Debugging, Wartung und Sicherheit unterstützen
Fehlerdiagnose kostet Zeit, die in vielen Unternehmen schlicht fehlt. Genau dafür bieten wir konkrete Unterstützung an, abgestimmt auf die jeweilige Dringlichkeit:
- WordPress Wartung: laufende Betreuung mit regelmäßigen Checks, bevor ein Fehler überhaupt sichtbar wird.
- WordPress Problemlösung: gezielte Fehlerbehebung bei akuten Problemen wie White Screens oder Plugin-Konflikten.
- Sicherheitspakete: zusätzlicher Schutz, falls Logs auf Schwachstellen hinweisen.
Für Unternehmen, die Fehlerbehebung dauerhaft auslagern möchten, ist ein Wartungsvertrag meist die wirtschaftlichste Lösung, weil Monitoring und Reaktion dann fester Bestandteil der Betreuung sind. Bei einem akuten Problem erreichen Sie unser Team direkt über die Seite zur WordPress Problemlösung und erhalten eine Einschätzung zum nächsten Schritt.
FAQ
Wie aktiviert man den Debug-Modus in WordPress?
Sie fügen in der wp-config.php die Zeilen define('WP_DEBUG', true);, define('WP_DEBUG_LOG', true); und define('WP_DEBUG_DISPLAY', false); direkt vor dem Hinweis zum Stoppen der Bearbeitung ein. Diese Kombination protokolliert Fehler, zeigt sie aber nicht öffentlich an, wie die offizielle WordPress-Dokumentation beschreibt.
Wofür wird der Debug-Modus in WordPress genutzt?
Der Debug-Modus hilft, die Ursache von Fehlern wie einem White Screen, Plugin-Konflikten oder Problemen nach einem Update zu finden. Er macht PHP-Warnungen, Notices und fatale Fehler sichtbar, die sonst unbemerkt bleiben.
Wo finde ich die WordPress-Logdatei?
Standardmäßig liegt sie unter /wp-content/debug.log, sobald WP_DEBUG_LOG aktiviert ist. Seit WordPress 5.1 lässt sich stattdessen auch ein eigener Dateipfad außerhalb des Webroots angeben.
Wie unterscheidet sich Recovery Mode vom klassischen Debugging?
Recovery Mode greift automatisch bei fatalen Fehlern, sendet eine E-Mail an die Administration und deaktiviert das auslösende Plugin oder Theme vorübergehend, wie in der WordPress-Referenz zum Fatal Error Handler beschrieben. Klassisches Debugging über debug.log liefert dagegen die tieferen technischen Details zur eigentlichen Ursache.
Welche Tools helfen zusätzlich zum manuellen Debugging?
Plugins wie Query Monitor zeigen Datenbankabfragen, Hooks und HTTP-Requests direkt im Admin-Bereich, während WP Debugging die nötigen Konstanten automatisiert setzt und wieder entfernt. Beide ersetzen kein Logging, ergänzen es aber sinnvoll bei komplexeren Fehlern.
