WordPress: Weißer Bildschirm – Alles probiert, was tun?

Es ist der mit Abstand häufigste WordPress-Fehler. Plötzlich ist der WordPress-Bildschirm weiß. Nichts geht mehr. So auch bei mir. Als ich alle Lösungsansätze, die Google für den „White Screen of Death“ parat hat, ausprobiert hatte und immer noch keinen Schritt weiter war, stolperte ich über die Lösung.

[toc] Der weiße WordPress-Bildschirm ist ein Mysterium. Viele Ursachen hat er, viele mögliche Lösungen ebenfalls. Hier will ich Euch meine Geschichte erzählen, aber auch, wie man normalerweise bei diesem Fehler vorgeht. Wer es eilig hat, der scrollt bitte direkt zum Punkt „Die Lösung“. Für alle anderen:

Aus dem Nichts: Der Weiße-Bildschirm

Ein ganz normaler Tag: Ich wollte weiter an meiner Webseite (dieser Webseite) arbeiten und plötzlich war er da: Der weiße Bildschirm. Freilich, er war mir schon früher begegnet, und so war ich auch nicht übermäßig in Panik versetzt. Dennoch fragte ich mich: Was war die Ursache? In meinem Fall funktionierte das Frontend weitestgehend problemlos. Nur beim Schreiben von Kommentaren bekam jeder Nutzer den weißen Bildschirm zu sehen. Anders sah es im Backend aus. Fast jede Änderung rief den „White Screen of Death“ hervor. Das Merkwürdige: Alle Änderungen wurden trotzdem durchgeführt, auch wenn ich nicht weitergeleitet wurde. Allerdings hatte ich auch keinen Zugriff auf die Mediathek mehr und konnte von anderen Geräten nicht mehr auf das Backend zugreifen – nur mein Desktop-Rechner schaffte das noch. Mit anderen Worten: Etwas musste getan werden.

Die Ursachen

Es gibt ein relativ gebräuchliches Prozedere bei diesem Problem. In den meisten Fällen hilft es, deswegen werde ich es hier schildern – auch wenn meine Lösung nicht dabei war. Im Wesentlichen entspricht das der Vorgehensweise, die auch WordPress selbst empfiehlt.

Ursache 1: Böse Plugins

Die mit Abstand häufigste Ursache sind Plugins. Die ersten Fragen, die man sich deswegen stellen muss, sind:

1. Habe ich kürzlich ein Plugin installiert?
2. Habe ich kürzlich ein Plugin geupdated?
3. Habe ich kürzlich am Code eines aktiven Plugins gearbeitet?

Leider traf bei mir gleich alles zu, weswegen ich mich dagegen entschied, einzelne Plugins anzuschalten, um diesen Fehler auszutesten. Denn mit der schnellen Methode kann das Problem direkt eingegrenzt werden. Dazu benötigt man FTP-Zugriff auf den WordPress-Ordner der Domain, die den weißen Bildschirm hervorruft. Nun benennt man den WordPress-Plugin-Ordner (wp-content/plugins) um. Dazu reicht es, einen Buchstaben zu ändern. Die Folge: Alle Plugins werden gleichzeitig deaktiviert, da WordPress nicht mehr auf sie zugreifen kann. Gesagt, getan. Allerdings bei mir ohne Ergebnis. Habt Ihr damit Erfolg, aktiviert wieder alle Plugins (Ordner wieder zurück benennen) und deaktiviert die Plugins einzeln (ebenfalls umbenennen oder im WordPress-Backend deaktivieren), um den Übeltäter auszumachen.

 

Ursache 2: Ein böses WordPress-Theme

Schuld ist nicht selten ein WordPress-Theme. Wenn kürzlich auf ein Theme gewechselt wurde, ist die Ursache klar. Sonst sind die entscheidenden Fragen:

1. Habe ich das Theme kürzlich aktualisiert?
2. Habe ich kürzlich am Code des aktiven Themes gearbeitet?

Wiederum traf beides auf mich zu. Glücklicherweise gibt es auch hier einen schnellen Test, der diese Ursache bestätigen oder widerlegen kann. Wenn der Zugriff auf das Backend noch möglich ist, kann einfach unter „Design“ das Theme geändert werden. Alternativ kann wiederum der Ordner-Name des Themes geändert werden. WordPress korrigiert das, in dem auf ein Standard-Theme gewechselt wird. Auch mit diesem Test konnte ich die Ursache nicht finden.

 

Ursache 3: Die böse wp-config.php

Die wp-config.php ist – zusammen mit der functions.php – eure wichtigste WordPress-Datei. Kleine Änderungen können hier große Probleme mit sich bringen. Für den „White Screen of Death“ ist ein unangebrachtes Leerzeichen in der Config schon genug Grund, auf den Plan zu treten. Die entscheidenden Fragen sind:

1. Habe ich kürzlich die wp-config.php bearbeitet?
2. Habe ich ein Plugin, welches die wp-config.php modifizieren kann?

Ich hatte die wp-config.php kürzlich bearbeitet. Ich nahm sie unter die Lupe, aber konnte nichts erkennen. Ich erstellte eine neue Config, kopierte die Zugangsdaten hinein und lud sie hoch. Ohne Ergebnis. An diesem Punkt begann ich mich aufzuregen. Die gute Neuigkeit für Euch: 90 Prozent sollten bis hier hin die Lösung oder zumindest die Ursache gefunden haben. Der Rest liest bitte weiter.

 

Weiter Lösungsversuche

Es kommt vor, dass ein WordPress-Caching-Programm dieses Problem verursacht – auch, wenn das Plugin bereits deaktiviert ist. Um das auszuschließen, solltet Ihr den Cache eurer Seite manuell löschen. Das funktioniert ebenfalls per FTP unter wp-content (einfach den gesamten Ordner „cache“ löschen). Wenn euch das, wie mich, nicht weiterbringt, ist eine Taktik-Änderung nötig: Debugging.

Um Euch den Fehler auf der Seite direkt anzeigen zu lassen, müsst Ihr das WordPress-Debug-System aktivieren. Dazu öffnet Ihr die wp-config.php und ändert

define('WP_DEBUG', false);

in

define('WP_DEBUG', true);

Das führt dazu, dass eventuelle Fehler beim Laden der Seite direkt im Browser angezeigt werden. Für alle Nutzer. Wenn Ihr also viele Besucher auf der Seite habt, solltet Ihr diesen Vorgang eher zu einer Zeit ausprobieren, wenn nicht so viele Leute auf Eurer Seite sind. Mit etwas mehr Aufwand ist auch das Erstellen einer Log-File für die Fehler, statt dem direkten Anzeigen möglich. Mehr Informationen gibt es auf wordpress.org. Bei mir wurden eine ganze Reihe von Fehlern angezeigt. Einer davon:

Warning: Cannot modify header information – headers already sent by (output started at /home/www/wordpress/wp-config.php:1) in /home/www/wordpress/wp-includes/pluggable.php on line 1207

Dieser Fehler besagt, dass der Auslöser in der ersten Zeile der wp-config.php zu finden ist (nicht in der Datei pluggable.php). Aber diese Datei hatte ich doch schon geprüft? Ich war nicht wirklich weiter. Trotzdem war es der erste Hinweis in die richtige Richtung. Ich schaltete das Debug-System wieder aus. Das Problem blieb aber: Ich konnte von meinem Laptop nicht auf das Backend zugreifen, weder über /wp-admin noch über /wp-login. Ich war kurz davor, WordPress neu zu installieren und viel Arbeit in den Sand zu setzen. Ich rief also die WordPress-Installationsseite auf (wp-admin/install.php), teils, weil ich sehen wollte, ob ich darauf zugreifen kann, teils, um den ersten Schritt Richtung Neuinstallation zu machen. Ich bekam keinen „White Screen of Death“, sondern nur eine Meldung, dass WordPress bereits installiert sei und ich für eine Neuinstallation die Datenbank löschen solle. Dann wurde ich weitergeleitet auf die WordPress-Loginseite, meine WordPress-Loginseite. Dieselbe Seite, die ich bisher nicht betreten konnte. Allerdings mit einem anderen Error:

Ich las die Dokumentation, die aber keine Lösung für mein Problem bereithielt. Trotzdem brachte mich dieser Fehler auf die richtige Spur.

Die Lösung

Nach einer mehr oder langen Google-Recherche über den neuen Fehler fand ich das Problem. Es war tatsächlich die wp-config.php. nach dem Bearbeiten mit dem Windows-Texteditor speicherte ich die Datei, bevor ich sie auf den Server hochlud. Als Codierung wählte der Editor „UTF-8“. Eigentlich kein Problem, in diesem Fall aber schon. Durch das Speichern der UTF-8-codierten-Datei lokal auf dem PC, wurde ein BOM (Byte Order Mark) zu der Datei hinzugefügt. Dadurch entstand das Leerzeichen. Die einfache Lösung: Die Datei mit einer ANSI-Codierung speichern.

Ich änderte die Codierung, lud die Datei hoch und – tada – es funktionierte wieder. Ganz normal. Dieser Fehler, der mich Stunden gekostet hatte, war innerhalb von 2 Minuten erledigt.

Ich hoffe, diese Erkenntnis hilft anderen dabei, dieses WordPress-Problem schneller zu lösen als ich. Ein Hinweis in der offiziellen WordPress-Dokumentation wäre sicherlich zu begrüßen.