WordPress zeigt eine weiße Seite: erst den Fehler lesen, dann handeln

„Kritischer Fehler“ oder weiße Seite: dieselbe Panne

Eine weiße Seite ist meist ein fataler PHP-Fehler: eine Datei der Website hat etwas Unmögliches verlangt, und die Ausführung wurde abgebrochen, bevor irgendetwas angezeigt wurde. Seit WordPress 5.2 fängt WordPress diese Fehler ab: statt einer leeren Seite zeigt es „Es gab einen kritischen Fehler auf deiner Website.“ und schickt eine E-Mail an die administrative E-Mail-Adresse der Website.

Ganz weiß bleibt die Seite in einigen Fällen: bei einer älteren WordPress-Version, bei einem Fehler, der auftritt, bevor dieser Mechanismus geladen ist, wenn die Konstante WP_DISABLE_FATAL_ERROR_HANDLER auf true steht, oder wenn ein Cache-Plugin eine leere Seite ausliefert, die es während der Panne gespeichert hat. Die folgende Methode gilt für all diese Fälle.

Drei Schritte können warten, bis Sie den Fehler gelesen haben: WordPress neu installieren, Plugins löschen, ein altes Backup einspielen. Jeder davon kann Einstellungen oder neue Daten löschen, während die Fehlermeldung meist genau sagt, welche Komponente zu deaktivieren ist, ohne dass etwas verloren geht.

Die Abkürzung: der Wiederherstellungsmodus

Fängt WordPress den Fehler ab, schickt es an die administrative E-Mail-Adresse der Website eine Nachricht mit dem Betreff „[Name der Website] Deine Website hat ein technisches Problem“. Sie nennt das verantwortliche Plugin oder Theme und enthält einen Link, der das Dashboard im Wiederherstellungsmodus öffnet.

• In diesem Modus wird die fehlerhafte Komponente nur für Sie pausiert: Ihre Besucher sehen weiterhin den Fehler.
• Deaktivieren Sie unter Plugins oder Design > Themes die genannte Komponente und klicken Sie dann in der Leiste oben im Dashboard auf „Wiederherstellungsmodus verlassen“.
• Der Link gilt 24 Stunden, und WordPress schickt höchstens eine solche E-Mail pro Tag. Kommt die E-Mail nicht an, sehen Sie im Spam-Ordner nach und gehen Sie dann zur nächsten Methode über.

Den Fehler lesen: das Debug-Log

Verbinden Sie sich per SFTP oder über den Dateimanager Ihres Hosters mit der Website, öffnen Sie wp-config.php im Stammverzeichnis und ersetzen Sie die Zeile define( 'WP_DEBUG', false ); durch diese vier Zeilen:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Sie gehören über den Kommentar, der den bearbeitbaren Bereich der Datei abschließt (/* Das war’s, Schluss mit dem Bearbeiten! Viel Spaß. */ in einem auf Deutsch installierten WordPress). Laden Sie die fehlerhafte Seite neu und öffnen Sie dann wp-content/debug.log. WP_DEBUG_DISPLAY auf false hält die Meldungen in der Datei, fern von der Seite, die Ihre Besucher sehen.

Bleibt debug.log leer oder erscheint die Datei nicht, hat PHP den Fehler direkt protokolliert: suchen Sie eine Datei error_log im Stammverzeichnis der Website oder in wp-admin, oder den Bereich für Fehlerprotokolle im Control Panel Ihres Hosters.

Was die Meldung sagt, und der passende Handgriff

Ein fataler Fehler passt in eine Zeile: die Fehlerart, ihre Beschreibung, dann in, gefolgt vom vollständigen Dateipfad und der Zeilennummer. Der Pfad ist die nützlichste Angabe: wp-content/plugins/name/ bezeichnet ein Plugin, wp-content/themes/name/ ein Theme.

define( 'WP_MEMORY_LIMIT', '256M' );

Die verantwortliche Komponente ohne Dashboard deaktivieren

Per SFTP oder Dateimanager

Benennen Sie den Ordner des in der Meldung genannten Plugins um, zum Beispiel wp-content/plugins/plugin-name in plugin-name.off. WordPress findet das Plugin nicht mehr und lädt es nicht mehr; seine Einstellungen bleiben in der Datenbank gespeichert, und WordPress deaktiviert es beim nächsten Aufruf der Seite Plugins.

Bei einem Theme macht das Umbenennen seines Ordners in wp-content/themes das Dashboard wieder erreichbar, doch Besucher sehen eine leere Seite, solange kein Theme aktiv ist. Öffnen Sie sofort Design > Themes: WordPress stellt fest, dass das aktive Theme fehlerhaft ist, und aktiviert ein installiertes Standard-Theme.

Mit WP-CLI

wp plugin list --status=active
wp plugin deactivate plugin-name
wp theme list
wp theme activate twentytwentyfive

Der erste Befehl hält die Liste der aktiven Plugins fest, nützlich vor jeder Sammeldeaktivierung. Bricht WP-CLI selbst am Fehler ab, ergänzen Sie den Befehl um --skip-plugins --skip-themes: dann startet es, ohne Plugins und Theme zu laden. Die Plugins im Ordner wp-content/mu-plugins werden trotzdem geladen; kommt der Fehler von einem davon, benennen Sie seine Datei um.

Nennt die Meldung keine Komponente, deaktiviert wp plugin deactivate --all alle Plugins. Läuft die Website dann wieder, aktivieren Sie sie einzeln und laden die Website dazwischen jeweils neu: das zuletzt aktivierte Plugin vor der Rückkehr des Fehlers ist das gesuchte.

Wenn die Website wieder läuft

1. Setzen Sie wieder define( 'WP_DEBUG', false ); und entfernen Sie WP_DEBUG_LOG aus wp-config.php.
2. Löschen Sie wp-content/debug.log: in einem aus dem Web erreichbaren Ordner kann jeder die Datei lesen, und sie enthält Pfade des Servers.
3. Aktualisieren oder ersetzen Sie die verantwortliche Komponente, nachdem Sie ihr Änderungsprotokoll gelesen haben.
4. Leeren Sie den Cache des Cache-Plugins und den Cache des Hosters, falls er einen hat.
5. Für das nächste Mal: testen Sie Updates an einer Kopie der Website, bevor Sie sie live einspielen.