WordPress-Debugging & Monitoring

All die bereits hier im Blog erwähnten WordPress-Features, -Updates und -Plugins haben mit all den anderen verfügbaren Erweiterungen einer WordPress-Seite eines gemeinsam: Sie können auf die verschiedenste Art und Weise zu Problemen führen. Sei es die Inkompatibilität eines Plugins mit der eingesetzten WordPress-Version, seien es Probleme durch die gleichzeitige Nutzung verschiedener Plugins oder unsauber durchgeführte manuelle Anpassungen von Themes – die Szenarien, Fehler und Probleme zu verursachen, sind vielfältig. Umso wichtiger ist es, möglichst aktuelle Backups vorzuhalten, mit denen der letzte funktionierende Status wiederhergestellt werden kann, wenn etwa die Installation eines Plugins oder Updates fehlschlägt.
Doch so beruhigend es auch ist, um diese Möglichkeit zu wissen, wird in vielen Fällen gewünscht zu erfahren, was das Problem eigentlich verursacht hat. Um dies herauszufinden, ist eine Logdatei enorm hilfreich. Wie diese erstellt und das Debug-Logging aktiviert werden kann, wollen wir nun aufzeigen; dies ist sowohl mit als auch ohne weitere Plugins möglich.
Eine Möglichkeit, das WP-Logging zu aktivieren, besteht in der Anpassung der Konfigurationsdatei wp-config.php. Dort ist in der Regel bereits die Zeile

define( ‚WP_DEBUG‘, false );

eingetragen. In dieser Zeile wird zunächst „false“ durch „true“ ersetzt (komplett ohne Anführungszeichen, da es sich hierbei um Boolesche Werte, nicht um Strings handelt!). Damit wird allerdings lediglich dafür gesorgt, dass eventuell auftretende Fehler ausgegeben werden – d.h., diese erscheinen mitunter direkt auf der Website. Da dies in der Regel selbst auf Development-Umgebungen nicht gewünscht ist, wird dies mit folgernder Zeile unterbunden:

define( ‚WP_DEBUG_DISPLAY‘, false );

Nun werden Fehler ausgegeben, deren Anzeige aber unterdrückt, was uns freilich absolut nicht weiter hilft. Deshalb lassen wir die Fehlermeldungen in eine Logdatei schreiben, und zwar über die dritte hierfür relevante Zeile

define( ‚WP_DEBUG_LOG‘, true );

Ist dies alles wie in nachfolgendem Screenshot in die wp-config.php geschrieben, diese gespeichert und gegebenenfalls wieder auf den Server übertragen worden, beginnt WordPress, Fehler und Warnungen in die Datei debug.log zu schreiben, die automatisch im Verzeichnis wp-content angelegt wird.
WP_DEBUG
Diese Datei ist nun via (Web-)FTP zugänglich und kann mit jedem Texteditor betrachtet und durchsucht werden. Sehr komfortabel ist dies allerdings nicht, und zwar aus einem Grund, der auch einen grossen Nachteil des Debug-Logs ist: WordpRess protokolliert hierin absolut jede Warnung und jeden Fehler, sodass in kürzester Zeit – auch bei einer einwandfrei funktionierenden Website – eine enorm grosse und entsprechend unübersichtliche Logdatei entstehen kann. Dies ist zudem einer der Hauptgründe, warum diese Art des Debuggings nur temporär und idealerweise auch nur auf Development-Umgebungen praktiziert werden sollte. Der WordPress-Codex warnt unmissverständlich:

„It is not recommended to use WP_DEBUG or the other debug tools on live sites; they are meant for local testing and staging installs.“

Dennoch bedeutet dies nicht, dass man sich die Auswertung der Logdateien nicht vereinfachen kann. Hierfür stehen diverse Plugins bereit, die die Logs auslesen und für die bessere Darstelklung aufbereiten. Eines davon ist „WP Log Viewer
WP Log Viewer Logo

Sind über oben genannte Einstellungen die Debug-Optionen aktiviert und die debug.log-Datei erstellt, wertet dieses Plugin jene Datei aus und präsentiert die Ergebnisse im Dashboard unter Tools > Log Viewer:

WP Log Viewer

WP Log Viewer

Durch die unterschiedlichen Anzeige- und Sortierungsmodi, die Suche und die Filterung nach verschiedenen Fehlermeldungen wird auch eine umfangreiche Logdatei deutlich übersichtlicher und einfach zu handhaben. Das Plugin zeigt zudem in der Kopfzeile des Dashboards den Debug Log-Status an: Ist mit der ersten der oben genannten Zeilen debug_log aktiviert (true), wird dies mit einem grünen „enabled“, gefolgt von der Anzahl der Fehler, signalisiert. Ist debug_log deaktiviert (false), das Plugin dennochaktiv, wird dies über ein rotes „disabled“ verdeutlicht.
Weitere Informationen zu solchem Debugging in WordPress finden sich im WordPress-Codex.

Geht es aber weniger um Debugging beim Auftreten konkreter Probleme, sondern soll stattdessen eine funktionierende WordPress-Installation auf sämtliche Veränderungen hin protokolliert werden, spielen andere Plugins ihre Stärke aus. Ein wirklich mächtiger Vertreter hierfür ist WP Security Audit Log, das oft genutzt, gut bewertet und vor allem auch häufig aktualisiert wird. In der Version mit vollem Umfang ist es allerdings auch nicht gerade günstig, doch bereits die Basisfunktionen lassen sich ertragreich nutzen. Besonders in einem Multisite-Setting oder auch Seiten mit mehreren Administratoren, Editoren und Benutzern macht ein solches Plugin ersichtlich, welche Änderung wann und von wem vorgenommen wurde. Dies kann zudem eine sinnvolle Ergänzung zum Debugging bei bestimmten Fehlern ergeben, wenn damit nachvollzogen werden kann, welche Änderungen zur Zeit eines bestimmten Fehlers vorgenommen wurden. Ist das Plugin erst installiert und aktiviert, fügt es sich auf oberster Ebene ins Dashboard ein:
WP Security Audit Log

Die ausgegebenen Meldungen von Datum über Username und IP bis Message verstehen sich von selbst, Type differenziert in die Stufen Notification (gelb), Warning (orange) uns Critical (rot). Die Codes stehen für spezifische Aktionen und Fehler; diese können per Click für die entsprechende Aktion deaktiviert werden. Zudem lässt sich präzise steuern, welche Aktionen überhaupt Meldungen mit entsprechenden Codes auslösen:
WP Security Audit Log

WP Security Audit Log

WP Security Audit Log

Wurden Veränderungen am Content vorgenommen, wird dies ebenfalls in der entsprechenden Spalte ‚Message‘ vermerkt und zudem zu einem direkten Vergleich verlinkt:

WP Security Audit Log

WP Security Audit Log

Selbst in der kostenfrei nutzbaren Version des Plugins lassen sich ausserdem eine ganze Reihe weiterer Einstellungen vornehmen. So ist es beispielsweise möglich, bestimmte User, bestimmte Rollen oder auch einzelne IP-Adressen explizit vom Monitoring auszuschliessen. Andere Features hingegen lassen sich (mitunter auch einzeln) hinzubuchen, etwa E-Mail-Notifications, Reports, eine erweiterte Suche et cetera.

Treten in Entwicklungs- oder Maintenancephasen Probleme auf, lassen sich diese über das bereits implementierte, aber standardmässig nicht aktivierte Debugging von WordPress in der Regel schnell ausmachen. Gerade in grösseren Umgebungen und komplexeren Strukturen ist die Ergänzung um ein (User-/Change-)Monitoring oftmals enorm hilfreich beim Eingrenzen der potentiell Fehler verursachenden Szenarien. Diese beiden Arten der Protokollierung ergänzen einander auch dadurch, dass eine davon kontinuierlich zur Protokollierung eingesetzt werden kann, während die andere, eben das gezielte Debugging, nur temporär aktiviert werden sollte.

Haben Sie weitere Fragen oder Anregungen zum Thema Debugging und Monitoring mit WordPress oder auch anderen CMS? Benötigen Sie weitere Informationen? Zögern Sie nicht, Kontakt mit uns aufzunehmen!

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.