WordPress Debugging und Wartung oder: Keine Panik vor dem White Screen of Death und HTTP 500

Deine WordPress-Seite besteht nur aus einem weißen Bildschirm, dem HTTP-Fehlercode 500 oder lädt irsinnig langsam? White Screen of Death (WSoD), die 500´er und Ladezeiten scheinen zu den größten Herausforderungen im Umgang mit WordPress zu gehören und sie hinterlassen regelmäßig lange Gesichter. Zwar gehören Ladezeit, PHP- und HTTP-Fehler nicht unbedingt zusammen, sie erfordern aber in der Regel das gleiche Vorgehen: Nämlich die Analyse, was da im Hintergrund so passiert.
Die Suche nach der Ursache ist oft relativ simpel. Es sagt einem oft nur niemand. Der beliebteste Tipp bei WordPress lautet oft:

“Deaktiviere mal alle Plugins und aktiviere sie nacheinander wieder.”

Anonymer Ratgeber, Mai 2018

Das ist alles andere als effizient, ja nicht einmal effektiv: Du erfährst nach 27 Minuten und zwei Tassen Kaffe, dass das Plugin “Foobar” für den Fehler verantwortlich ist, weil das den WSOD auslöst. Aber dann weißt du immer noch nicht, was der Fehler eigentlich ist. Danke für nichts.

Tatsächlich gibt es nur drei Dinge, die dir helfen können, dir selber zu helfen, wenn WordPress dich mal wieder im Stich lässt. Und diese drei Werkzeuge zur Fehlersuche und Diagnose langsamer WordPress-Installation stelle ich jetzt einmal vor:

1. Die Entwickler-Konsole deines Browsers

Dieses Werkzeug bringt mittlerweile jeder moderne Browser mit und das sollte auch die erste Anlaufstelle für dich sein. Welche Entwicklerkonsole du verwendest, ist deinem Geschmack überlassen, in der Funktionalität unterscheiden sie sich kaum. Du öffnest die Entwicklerkonsole auf vielfältige Weise über

  • das Kontextmenü (Rechte Maustaste -> Element untersuchen) oder
  • über mit der Funktionstaste F12 oder
  • mit dem Shortcut CTRL+SHIFT+I (Windows) / CMD+OPT+I (OS X)

Das Vorgehen ist tatsächlich bei jedem Browser gleich, abgesehen von Opera, bei dem du die Shortcuts erst manuell anlegen musst.

2. Der Query Monitor – warum ist dein WordPress so langsam?

Der Query Monitor ist ein wirklich nützliches Plugin für WordPress. Eines der wenigen. Du fragst dich, warum deine Seite so lange lädt und die Entwicklerkonsole gibt nicht vielmehr her als ein TTFB (Time To First Byte) von 60 Sekunden?

Die Entwicklerkonsole sagt dir nur, wie lange der Browser auf den Inhalt wartet. Hier kann maximal identifiziert werden, dass die reine Wartezeit (TTFB) 60 Sekunden beträgt und der Inhalt in 10 Sekunden heruntergeladen wird (die ganzen anderen Nerd-Kennzahlen jetzt mal außen vor gelassen). Letzteres liegt ziemlich wahrscheinlich an der Internetleitung von dir oder dem Hoster. Aber TTFB? Das ist im Grunde die Zeit, die der Server benötigt um die Ausgabe einmal zusammenzuschustern und zu deinem Browser zu schicken. Also das ganze PHP-Gedöns einmal “interpretieren” und ein paar Datenbankabfragen durchführen. Je umfangreicher deine WordPress-Seite ist (sprich Plugin-Vielfalt), desto mehr gibt es hier zu tun. Und was da im Hintergrund genau passiert, sagt dir der Query Monitor.

Nach der Installation siehst du in der Admin-Toolbar erstmal ein paar oberflächliche Zahlen: Ladezeit, Größe und Anzahl der Queries. Wirklich spannend wird es, wenn du mal auf diese Zahlen klickst. Dann öffnet sich eine “Entwickler-Konsole”, die deiner WordPress-Seite mal gehörig unter die Haube schaut. Du siehst Datenbankabfragen, Scripte, Funktionen und alle möglichen Diagnostiken – einfach alles. Du kannst nun relativ zügig erkennen, ob manche Abfragen einfach nur doppelte durchgeführt wurden oder die Datenbank grundsätzlich zu langsam ist.

3. Der Debug-Modus

Das beste zum Schluss – der Debug-Modus verrät dir wirklich alles und ist eigentlich der Premium-Weg der Problemlösung.

Du wirst nur selten erleben, dass WordPress bzw. dein Server dich wirklich gar nicht mit einer Fehlermeldung erhellen will. Der berüchtigte White Screen of Death und der gefürchtete HTTP-Fehler 500 sind im Grunde nur der Standardeinstellungen geschuldet. Du kannst dann entweder ein Ticket bei deinem Hoster öffnen und im nächsten Jahr mit einer Antwort rechnen oder versuchen, selber an die Fehlermeldung zu gelangen und das Problem selber zu analysieren: Der geheime Trick lautet nämlich, einfach mal das Internet nach der Fehlermeldung zu durchsuchen. In 99,99% der Fälle bist du bei weitem nicht der erste mit diesem banalen Problem..

Die wahre Herausforderung ist allerdings, dass die Ausgabe von Fehlermeldungen eben standardmäßig unterdrückt  wird. Aus Gründen der Sicherheit und Bedienbarkeit ist das grundsätzlich vielleicht nicht verkehrt, aber wenn du doch mal wissen willst, woher der berühmte White Screen of Death wirklich kommt, gehst du folgendermaßen vor:

A: Du aktivierst die Fehlerausgabe von WordPress

Dazu öffnest du die Datei wp-config.php und setzt folgenden Parameter direkt an den Anfang, aber hinter das <?php:

Der 1. Parameter ist für das debuggen essentiell – die darauffolgenden kannst du in der Regel ignorieren, sie können bei der tieferen Fehlersuche aber ganz nützlich sein, weshalb ich sie auch auskommentiert habe – vergiss aber nicht, dass es sie gibt.

Wie z.B. der 2. Parameter: Setzt du WP_DEBUG_LOG auf true, wird WordPress Fehlermeldungen in die Date /wp-content/debug.log schreiben. Für die nachträgliche Analyse ist das sehr praktisch. Weiter geht es mit SCRIPT_DEBUG. Mit true aktiviert, sorgt dieser Schalter dafür, dass WordPress die “echten” CSS- und JS-Dateien liest, anstatt der minifizierten. Das wird dich nur in Spezialfällen betreffen, solltest du aber kennen. Der nächst Spezialist in der Riege ist SAVEQUERIES – hiermit wird dir WordPress die Datenbank-Anfragen ausgeben.

Denke daran, dass die Parameter im weiteren Verlauf der Config-Datei nicht wieder vorkommen und deine Einstellung so aufheben und vor allen, dass du die Parameter in einem Live-System wieder auf false zurücksetzen solltest.

B: Du aktivierst die Fehlerausgabe deines Servers

Eigentlich sollte dir Nummero A bereits weiterhelfen, denn damit wird auch die Fehlerausgabe von PHP aktiviert. Sollte deine Seite trotzdem weiß bleiben und dich nicht mit zusätzlichen Fehlernachrichten beglücken, musst du etwas tiefer in die Trickkiste greifen.
Ergänze, ebenfalls direkt hinter dem <?php der Datei wp-config.php die folgenden Zeilen:

Die beiden letzten Zeilen aktivieren, ähnlich wie oben, dass PHP Fehlermeldungen in eine Datei schreibt. Da die Log-Datei bei der ad hoc Fehlersuche nicht zwingend hilfreich ist, sind diese beiden Zeilen auskommentiert.

Wenn du den Pfad zu deiner Installation nicht kennst, bekommst du sie mit folgendem PHP-Befehl heraus. Wenn du diese Information nicht mehr benötigst, entferne sie aber sofort aus deinem Script. Security through obscurity – das Document Root geht niemanden außer dich etwas an!

Achtung: Auf manchen Seiten wird dir empfohlen, den Zeilen ein @ vorzustellen. Das ist ziemlich kontraproduktiv – denn das @ am Anfang der Zeile unterbindet Fehlermeldungen und weshalb bist du hier? Genau…

Das ist aber noch nicht alles – die Trickkiste ist noch tiefer. Doch obacht! Das folgende ist Premium-Klasse-Debuggung. Handle with care. Die essentiellen Parameter befinden sich in der ersten Zeile. Die noch tiefergreifenden und wirklich nur in absoluten Sonderfällen benötigten Einstellungen sind darunter aufgeführt.

Öffne die Datei .htaccess und ergänze die folgenden Zeilen – auch hier gilt, achte darauf, dass die Parameter nicht an anderer Stelle ungewollt überschrieben werden:

Warum A und warum B? Es ist möglich, dass die Server-Konfiguration es aus Sicherheitsgründen nicht zulässt, dass diese sogenannten PHP-Direktiven (aka Parameter) an beliebigen Stellen (aka .htaccess, in der PHP-Datei, …) konfiguriert wird. Deshalb.
Und was ist mit C – der php.ini-Datei? Gute Frage, werter Leser, die bei dir ein gewisses Grundwissen erkennen lässt. Chapeau. In dem Fall gehe ich sehr stark davon aus, dass du Zugriff auf eben diese Datei hast. Und wer Zugriff auf diese Datei hat, mit diesem Vorwissen, ist ziemlich sicher und hoffentlich mit der notwendigen Erfahrung ausgestattet. Andernfalls: Ruf deinen SysOp an. 😉 Fühle dich trotzdem herzlich dazu eingeladen, diesen Beitrag mit etwas zuästzlichem Fachwissen in den Kommentaren zu bereichern.

C: Den Debug-Modus bei deinem Hoster aktivieren

Bei der Einstellung des Debug-Modus gibt es eine Hierarchie. Die Debug-Einstellung in der PHP-Datei (wp-config.php) ist hierbei die oberste Ebene, darunter folgt die Einstellung in der .htaccess-Datei und auf unterster Ebene lässt sich diese Funktion in der Einstellung des Servers bzw. PHP-Interpreters direkt einstellen (z.B. php.ini). Damit unbedarfte Laien wie wir an dieser Datei nicht wahllos rumfingern, ist bleibt uns diese Möglichkeit entweder komplett verwehrt oder ist nur über das Interface bei deinem Hoster einstellbar. Dort kann der Hoster auch festlegen, dass diese Einstellung (in Fachkreisen gerne auch Direktive genannt) in den Ebenen darüber gar nicht anpassen werden darf – Schritt A und B bleiben also unwirksam. Das ist der Zeitpunkt, wenn du in den Einstellungen bei deinem Hoster nach dieser Einstellung suchst – oder den Hoster darum bittest, den Debug-Modus für dich zu aktivieren.

Bei HostEurope kannst du das z.B. sehr leicht selber tun:

Host Europe Debug Modus aktivieren

Host Europe Debug Modus aktivieren

 

Freibier – Nachwort – Lies  mich!

Das ist jetzt wirklich wichtig: Wie immer, und oben bereits erwähnt, gilt auch hier: Security through obscurity.

Wenn du den Debug-Modus auf dem Live-System nicht mehr benötigst, deaktiviere ihn. Basta.

Auf Live-Systemen hat der Debug-Modus nur in Ausnahmefällen etwas verloren. Und Fehler sollten zur Ausnahme zählen. Und auch, wenn du hier nur ein wenig an den PHP-Dateien rumschraubst, wobei eigentlich nicht viel kaputt gehen kann:

Denke an die obligatorische Sicherungskopie.

Und jetzt viel Spass beim debuggen

Ach ja – wenn all das da oben nicht funktioniert, dann kannst du tatsächlich auch mal den Holzhammer rausholen: Plugins aktivieren und deaktivieren. In der Regel helfen dir die hier geschilderten Schritte aber, genau diesen mühsamen Schritt zu übergehen.

Start the Discussion!

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

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.