WordPress „kritischer Fehler“: Ursache finden und beheben

Du hast ein Plugin aktualisiert, die PHP-Version beim Hoster umgestellt oder ein neues Theme ausprobiert, und plötzlich zeigt Deine Website nur noch „Es gab einen kritischen Fehler auf dieser Website“. Oder sie bleibt komplett weiß. Oft ist auch der Admin-Bereich nicht mehr erreichbar, sodass Du das Problem nicht einfach dort zurückdrehen kannst.

Keine Sorge: Deine Beiträge, Seiten und Medien sind dabei nicht verloren. Hinter der Meldung steckt fast immer ein PHP-Fehler in einem Plugin oder Theme, und den findest und behebst Du mit dem Ablauf in dieser Anleitung. Er funktioniert auch ohne Zugang zum Dashboard, sowohl beim klassischen Webhoster als auch bei WordPress im Docker-Container. Getestet habe ich den Weg über WP-CLI mit WordPress 7.1.4 und WP-CLI 2.12 in Docker, mit einem absichtlich kaputten Plugin.

Schritt 1: die Mail zum Wiederherstellungsmodus suchen

Seit WordPress 5.2 fängt WordPress schwere Fehler ab und schickt eine E-Mail an die Admin-Adresse der Website. Der Betreff lautet sinngemäß „Deine Website hat ein technisches Problem“. In der Mail steht, welches Plugin oder Theme den Fehler ausgelöst hat, und sie enthält einen Link zum Wiederherstellungsmodus.

Schau also zuerst in das Postfach der Admin-Adresse und in den Spam-Ordner. Ein Klick auf den Link meldet Dich in einem besonderen Modus an, in dem das fehlerhafte Plugin pausiert ist. Unter Plugins deaktivierst Du es dann dauerhaft oder installierst eine ältere Version. Danach meldest Du Dich über den Knopf Wiederherstellungsmodus verlassen oben in der Werkzeugleiste ab, und die Website läuft wieder.

Kommt keine Mail, etwa weil Deine Installation keine E-Mails verschicken kann, oder ist der Link abgelaufen, geht es mit dem Debug-Log weiter.

Schritt 2: das Debug-Log einschalten

Die Fehlermeldung „kritischer Fehler“ verrät absichtlich nichts, damit Besucher keine technischen Details sehen. Die eigentliche Ursache schreibt WordPress in eine Logdatei, sobald Du das Debugging einschaltest. Dafür bearbeitest Du die Datei wp-config.php im Hauptordner Deiner WordPress-Installation, per FTP, über den Dateimanager Deines Hosters oder auf dem Server per SSH.

Such die Zeile define( 'WP_DEBUG', false );. Ersetze sie durch diese vier Zeilen und achte darauf, dass sie vor dem Kommentar mit „stop editing“ stehen, der in deutschen Installationen „Schluss mit dem Bearbeiten“ heißt:

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

WP_DEBUG schaltet die Fehlerberichte ein, WP_DEBUG_LOG schreibt sie in die Datei wp-content/debug.log. Die beiden letzten Zeilen sind genauso wichtig: Sie verhindern, dass die Fehler auf der Website erscheinen, wo sie jeder Besucher lesen könnte, samt Pfaden auf Deinem Server.

Wenn Du WP-CLI zur Verfügung hast, setzt Du die drei Konstanten auch ohne Editor:

wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_LOG true --raw
wp config set WP_DEBUG_DISPLAY false --raw

Ruf danach Deine Website einmal im Browser auf, damit der Fehler erneut auftritt und im Log landet.

Schritt 3: das Log lesen

Öffne die Datei wp-content/debug.log. Auf dem Server per SSH zeigst Du die letzten Einträge mit:

tail -n 30 wp-content/debug.log

Wichtig ist der Eintrag mit PHP Fatal error. Bei meinem Test mit einem kaputten Plugin sah er so aus:

PHP Fatal error:  Uncaught Error: Call to undefined function nicht_vorhanden() in /var/www/html/wp-content/plugins/kaputt/kaputt.php:3

Der Pfad am Ende sagt Dir, wo der Fehler sitzt, und das genügt in den meisten Fällen:

• Steht dort wp-content/plugins/<name>/, ist das Plugin <name> schuld.
• Steht dort wp-content/themes/<name>/, ist es das Theme.
• Steht dort Allowed memory size of … bytes exhausted, reicht der Arbeitsspeicher für PHP nicht. Dazu gleich mehr.
• Taucht eine Meldung wie Call to undefined function oder ein Syntaxfehler auf, nachdem Du die PHP-Version gewechselt hast, ist ein Plugin oder Theme nicht mit der neuen PHP-Version kompatibel.

Zeilen mit PHP Warning, PHP Notice oder PHP Deprecated kannst Du für dieses Problem ignorieren. Sie stehen in fast jedem Log und legen die Website nicht lahm.

Schritt 4: das schuldige Plugin deaktivieren

Ohne Admin-Zugang deaktivierst Du ein Plugin am einfachsten, indem Du seinen Ordner umbenennst. Öffne per FTP oder Dateimanager wp-content/plugins/ und benenne den Ordner des Plugins aus dem Log um, etwa von kaputt in kaputt.aus. WordPress findet das Plugin dann nicht mehr und deaktiviert es beim nächsten Aufruf. Lade die Website neu. Läuft sie, kannst Du Dich wieder anmelden.

Mit WP-CLI geht es eleganter. Der Trick sind die Optionen --skip-plugins und --skip-themes, denn WP-CLI lädt sonst selbst das kaputte Plugin und bricht mit demselben Fehler ab. Mit den Optionen startet es ohne Plugins und Theme:

wp plugin list --status=active --skip-plugins --skip-themes
wp plugin deactivate kaputt --skip-plugins --skip-themes

Der erste Befehl zeigt alle aktiven Plugins, der zweite deaktiviert das Plugin mit dem Ordnernamen kaputt. Ersetze den Namen durch den aus dem Log. Weißt Du nicht, welches Plugin schuld ist, deaktivierst Du alle auf einmal und aktivierst sie danach einzeln wieder, bis der Fehler zurückkommt:

wp plugin deactivate --all --skip-plugins --skip-themes

Genau diesen Ablauf habe ich getestet: Ohne die beiden Optionen brach wp plugin list mit dem Fatal Error ab, mit ihnen lief der Befehl, und nach dem Deaktivieren war die Website wieder erreichbar.

WordPress im Docker-Container

Läuft WordPress in Docker, etwa unter Coolify oder mit Docker Compose, gibt es zwei Wege. Entweder Du öffnest eine Shell im Container und arbeitest dort mit den Dateien:

docker exec -it wordpress bash

Ersetze wordpress durch den Namen Deines Containers, den Dir docker ps anzeigt. Im offiziellen WordPress-Image landest Du direkt im Ordner /var/www/html. Oder Du bearbeitest die Dateien direkt im Volume auf dem Host. Wo die Volumes bei Coolify liegen, steht in Wo sind die WordPress-Docker-Volumes in Coolify?.

Wenn das Theme schuld ist

Zeigt das Log auf einen Ordner unter wp-content/themes/, wechselst Du auf ein Standardtheme. Mit WP-CLI geht das so:

wp theme activate twentytwentyfive --skip-plugins --skip-themes

Ohne WP-CLI benennst Du den Ordner des aktiven Themes um. WordPress fällt dann auf ein installiertes Standardtheme zurück, sofern eines vorhanden ist. Lösch die Standardthemes deshalb nie ganz, eines sollte immer als Reserve installiert bleiben.

Wenn der Speicher nicht reicht

Steht im Log Allowed memory size of 134217728 bytes exhausted, sind PHP die 128 MB Arbeitsspeicher ausgegangen. Das passiert bei großen Seitenbaukästen, Shop-Plugins oder Importen. Erhöhe das Limit für WordPress mit einer zusätzlichen Zeile in der wp-config.php, ebenfalls vor dem „stop editing“-Kommentar:

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

Das wirkt nur bis zu dem Wert, den der Server selbst für PHP erlaubt. Liegt dessen memory_limit niedriger, musst Du es in der PHP-Konfiguration anheben, beim Hoster meist in dessen Verwaltungsoberfläche. Wie das unter Docker funktioniert, zeigt PHP.ini in WordPress unter Coolify (Docker + MariaDB) richtig anpassen.

Nach der Reparatur: Debug wieder aus

Läuft die Website wieder, schalte das Debugging ab. WordPress rät ausdrücklich davon ab, WP_DEBUG auf einer Live-Website dauerhaft eingeschaltet zu lassen. Setz in der wp-config.php wieder define( 'WP_DEBUG', false );, entferne die übrigen Zeilen und lösche die Datei wp-content/debug.log. Sie kann Pfade und Details enthalten, die nicht öffentlich sein sollen, und liegt in einem Ordner, der je nach Server aus dem Web abrufbar ist.

Danach kümmerst Du Dich um das eigentliche Plugin: Schau auf seiner Seite bei wordpress.org, ob es ein neueres Update mit einer Korrektur gibt, installiere notfalls die vorherige Version, oder ersetze es durch ein gepflegtes Plugin mit derselben Funktion.

So passiert es nicht wieder

Die meisten kritischen Fehler entstehen bei Updates. Drei Gewohnheiten nehmen ihnen den Schrecken:

• Backup vor jedem Update. Sichere Datenbank und wp-content, bevor Du Plugins oder WordPress selbst aktualisierst. Mit WP-CLI exportierst Du die Datenbank per wp db export.
• Updates einzeln einspielen. Aktualisiere nicht zehn Plugins auf einmal, sondern eines nach dem anderen, und lade danach kurz die Website. Dann weißt Du sofort, welches den Fehler ausgelöst hat.
• PHP-Wechsel vorher testen. Stell die PHP-Version zuerst auf einer Staging-Kopie um, wenn Dein Hoster das anbietet. Die meisten Hoster haben dafür einen Knopf.

Prüf außerdem, dass Deine Installation E-Mails verschicken kann, damit Dich die Mail zum Wiederherstellungsmodus beim nächsten Mal auch erreicht. Dann ist ein kritischer Fehler eine Sache von fünf Minuten.