WordPress-Debug-Modus: WP_DEBUG, WP_DEBUG_LOG und WP_DEBUG_DISPLAY

WordPress 6 Min. Lesezeit

Der Debug-Modus von WordPress wird durch drei Konstanten in der Datei „wp-config.php“ gesteuert. „WP_DEBUG“ ist der Hauptschalter; „WP_DEBUG_LOG“ schreibt die Fehler in eine Datei, während „WP_DEBUG_DISPLAY“ sie auf der Seite anzeigt. Solange „WP_DEBUG“ deaktiviert ist, haben die beiden anderen keine Wirkung.

Ein wichtiger Grundwert sorgt für die meisten Überraschungen: Der Wert von „WP_DEBUG_DISPLAY“ ist standardmäßig auf „true“ gesetzt. Wenn Sie lediglich die Konstante „WP_DEBUG“ aktivieren, werden die PHP-Warnmeldungen – einschließlich der Serverpfade – auch für Besucher sichtbar angezeigt. Auf einer live geschalteten Website ist folgende Einstellung sicher: „WP_DEBUG“ aktiviert, „WP_DEBUG_DISPLAY“ deaktiviert und „WP_DEBUG_LOG“ schreibt in eine Datei, die über das Web nicht zugänglich ist.

Infografik: Der Hauptschalter WP_DEBUG sowie die möglichen Werte für WP_DEBUG_DISPLAY und WP_DEBUG_LOG

Was bewirkt die jeweilige Konstante?

WP_DEBUG. Ist der Wert „true“, meldet PHP alle Warnungen, Hinweise und Veraltungshinweise, und WordPress meldet die Verwendung veralteter Funktionen ebenfalls als Fehler. Ist der Wert „false“ (dies ist der Standardwert), werden nur schwerwiegende Fehler protokolliert.

WP_DEBUG_DISPLAY. Ist der Wert „true“ oder nicht angegeben, wird der Fehler im HTML-Code der Seite angezeigt. Ist der Wert „false“, wird er nicht angezeigt. Bei REST-API-, AJAX- und XML-RPC-Anfragen deaktiviert WordPress die Anzeige stets, damit die Fehlermeldung die JSON-Antwort nicht beeinträchtigt; wenn Sie den Fehler auf der Seite sehen, in der REST-Antwort jedoch nicht, ist dies also beabsichtigt.

WP_DEBUG_LOG. Ist der Wert „true“, werden Fehler in die Datei „wp-content/debug.log“ geschrieben. Diese Datei kann auch über die Website heruntergeladen werden; jeder, der die Adresse herausfindet, kann sie öffnen, und sie enthält vollständige Serverpfade sowie gelegentlich auch Datenbankdetails. Wenn Sie anstelle von „true“ einen absoluten Pfad angeben, schreibt WordPress dorthin, sodass Sie das Protokoll außerhalb des Ordners „public_html“ ablegen können. Ist der Wert „false“, nimmt WordPress keine Änderungen an der Protokollierung vor, und die Fehler werden in das eigene PHP-Protokoll des WordPress-Hostings geschrieben.

SCRIPT_DEBUG. Hier geht es nicht um PHP-Fehler: WordPress lädt die unkomprimierten Versionen seiner eigenen JavaScript- und CSS-Dateien, sodass der Fehler auf eine Zeile verweist, die in der Browserkonsole lesbar ist. Auf die eigenen, komprimierten Dateien der Plugins hat dies in der Regel keine Auswirkungen.

Wo liegen die Fehler beim cPanel-Hosting von aWh?

Bei cPanel-Hosting-Paketen protokolliert PHP standardmäßig in die Datei „logs/php.error.log“ im Home-Verzeichnis, sodass Sie schwerwiegende Fehler auch dann finden können, wenn der Fehlerbehebungsmodus von WordPress deaktiviert ist. Im Stammverzeichnis der Website kann zudem eine „error_log“-Datei erstellt werden. Beide Dateien können Sie im Dateimanager oder im Terminal öffnen:

tail -n 20 ~/logs/php.error.log

Sollte das Protokoll keine Einträge enthalten oder sollten Sie auch die Warnmeldungen einsehen möchten, aktivieren Sie bitte den Debug-Modus. In unserem Blogbeitrag erfahren Sie ausführlich, wie Sie die Protokolleinträge interpretieren können.

Aktivieren des Debugging-Modus

Im WP Toolkit

Öffnen Sie in der cPanel-WordPress-Verwaltungsoberfläche die Registerkarte Ihrer Website und aktivieren Sie im Bereich „Tools“ den Schalter „Fehlerbehebung“. Schalten Sie ihn anschließend wieder aus, wenn Sie fertig sind.

Mit WP-CLI

Speichern Sie zunächst die Datei „wp-config.php“, da ein Tippfehler die gesamte Website lahmlegen kann:

cd ~/public_html
cp -p wp-config.php ~/wp-config.php.bak-$(date +%F)
wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_DISPLAY false --raw
wp config set WP_DEBUG_LOG /home/felhasznalonev/logs/wp-debug.log

Der Schalter „--raw“ gibt den logischen Wert ohne Anführungszeichen ein; lassen Sie ihn bei der Pfadangabe weg, da diese in Anführungszeichen stehen muss. Geben Sie anstelle von „felhasznalonev“ Ihren cPanel-Benutzernamen ein (dieser wird vom Befehl „whoami“ ausgegeben). Das WP-CLI fügt die neuen Konstanten an der entsprechenden Stelle ein und passt die Zeile „WP_DEBUG“ an, falls diese bereits in der Datei vorhanden ist (was bei Websites der Fall ist, die mit dem WP Toolkit installiert wurden). Die Grundlagen des WP-CLI werden im Artikel zur Verwendung des WP-CLI beschrieben.

Manuell im Dateimanager

Öffnen Sie die Datei „wp-config.php“ zur Bearbeitung, suchen Sie die vorhandene Zeile „WP_DEBUG“ und ersetzen Sie diese durch die folgenden drei Zeilen:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', '/home/felhasznalonev/logs/wp-debug.log' );

Die Zeilen müssen oberhalb des Kommentars „/* That's all, stop editing! Happy publishing. */“ stehen. Alles, was unterhalb der Zeile „require_once ABSPATH . 'wp-settings.php';“ am Ende der Datei steht, wird zu spät ausgeführt und ist wirkungslos. Geben Sie eine Konstante bitte nur einmal an: Wenn sie zweimal in der Datei vorkommt, gibt PHP eine Warnung aus, und die erste Angabe ist gültig.

Überprüfung

wp eval 'var_dump( WP_DEBUG, WP_DEBUG_LOG, WP_DEBUG_DISPLAY, ini_get( "error_log" ) );'

Die Antwort finden Sie auf unserer Test-Website:

bool(true)
string(38) "/home/felhasznalonev/logs/wp-debug.log"
bool(false)
string(38) "/home/felhasznalonev/logs/wp-debug.log"

Die letzte Zeile belegt, dass WordPress die Einstellung tatsächlich übernommen hat. Laden Sie anschließend die fehlerhafte Seite und sehen Sie sich das Protokoll an:

tail -n 20 ~/logs/wp-debug.log

Bitte überprüfen Sie abschließend, ob auf der Seite nichts angezeigt wird:

curl -s https://pelda.hu/ | grep -icE "Warning:|Notice:|Deprecated:|Fatal error:"

Die richtige Antwort lautet „0“. Ist der Wert höher, wird die Fehleranzeige später wieder aktiviert – meist durch ein Plugin. Sie können dies wie folgt überprüfen: grep -rn "display_errors" ~/public_html/wp-content/plugins/.

Wenn das Protokoll leer bleibt

  1. Die Konstanten befinden sich an der falschen Stelle. Vergleichen Sie die Zeilennummern: grep -n "wp-settings\|WP_DEBUG" wp-config.php. Die Zeilen mit WP_DEBUG müssen eine niedrigere Zeilennummer aufweisen.
  2. Der Pfad enthält einen Tippfehler. Auch ein falsch geschriebener Pfad ist ein gültiger Text; WordPress legt ihn fest, PHP kann jedoch stillschweigend nicht dorthin schreiben. Bitte überprüfen Sie, ob der Ordner vorhanden ist.
  3. Die Einstellung wird von etwas überschrieben. Wenn ini_get( "error_log" ) nicht Ihren Pfad zurückgibt, wird die Einstellung durch ein Plugin oder ein „Must-Use“-Plugin (wp-content/mu-plugins) geändert.
  4. Der Vorgang wurde vor der Ausführung von PHP abgebrochen. Wenn die Seite leer ist und einen 500er-Fehler anzeigt und in keinem der Protokolle Einträge zu finden sind, hat die Anfrage die PHP-Fehlerbehandlung nicht erreicht. In diesem Fall empfiehlt es sich, in der cPanel-Gruppe „Indikatoren“ die Seite „Fehler“ sowie die CloudLinux-Ressourcenbeschränkungen zu überprüfen.

Lassen Sie das Gerät nicht unnötig eingeschaltet

WordPress und PHP schreiben das Log nicht. Eine PHP-Erweiterung, die bei jedem Laden der Seite denselben Verfallsvermerk ausgibt, erzeugt innerhalb weniger Tage eine Datei im Gigabyte-Bereich, die sowohl Speicherplatz als auch die Anzahl der Dateien (Inodes) beansprucht. Nach der Erkennung des Fehlers:

  • Deaktivieren Sie die Konstante „WP_DEBUG“ (wp config set WP_DEBUG false --raw) oder den Schalter „Fehlerbehebung“ im WP Toolkit;
  • Löschen Sie den Inhalt des Protokolls nicht, sondern leeren Sie ihn: > ~/logs/wp-debug.log. Wenn Sie ihn nicht mehr benötigen, löschen Sie die Datei;
  • Sollte das Protokoll mit derselben Warnmeldung überfüllt sein, muss das Plugin oder die Vorlage repariert oder ausgetauscht werden; das Ausblenden der Meldungen beseitigt lediglich das Symptom.

Der Fehlerbehebungsmodus zeigt ausschließlich PHP-Fehler an: langsame Datenbankabfragen oder das Erreichen der Speichergrenze werden nicht angezeigt. Wenn Ihre Website langsam ist, helfen Ihnen der Artikel zur Beschleunigung von WordPress und der Artikel zur Speichergrenze weiter; die Fehlerbehebung bei einem weißen Bildschirm wird in einem separaten Artikel beschrieben.

Zurück: WordPress-Artikel (43)