Meine WordPress-Website ist down: „There has been a critical error"

Was „There has been a critical error" wirklich bedeutet

Irgendwo in Ihrem Stack - fast immer ein Plugin oder das Theme - ist eine Zeile PHP hart genug fehlgeschlagen, dass WordPress nicht weiterlaufen konnte. Der Fatal-Error-Handler hat sie abgefangen und statt einer weißen Seite diese Meldung ausgegeben. Das ist der ganze Fehler. Ihre Dateien sind noch auf der Disk, Ihre Datenbank ist noch da, Ihr Content ist in Ordnung. Eine Extension ist abgestürzt und hat die gesamte Website mitgerissen.

Das Muster

Ein Plugin aktualisiert sich. Oder Ihr Hoster hebt die PHP-Version an. Oder jemand bearbeitet eine Datei über den Theme-Editor. Der allernächste Request antwortet mit „There has been a critical error on this website." Das Frontend ist down. wp-login.php ist auch down, Sie können das verdächtige Plugin also nicht deaktivieren - und die E-Mail, die Sie wieder hineinbringen könnte, geht an die Adresse, die gerade in Einstellungen → Allgemein steht.

Die ältere Variante desselben Crashs ist der White Screen of Death: der Fatal feuert, bevor WordPress irgendetwas rendern kann, also bekommt der Browser eine leere Seite. Gleiche Ursache, weniger Information. Beide kommen aus derselben Stelle, und beide werden unten behandelt.

Was WordPress als Nächstes tut - und wo es hängen bleibt

Seit WordPress 5.2 hat der Core eine echte Antwort. Wenn der Fatal feuert, erkennt ihn der Fatal-Error-Handler und mailt einen Recovery-Mode-Link an die Admin-Adresse der Website. Den Link anklicken, erneut einloggen, und Recovery Mode pausiert die kaputte Extension - die Website kommt mit deaktiviertem Plugin zurück, mit einer Notice, die sie benennt. Der Mechanismus ist solide. Die Zustellung ist der schwache Teil.

Der Link geht an die E-Mail, die in Einstellungen → Allgemein steht - oft eine Mailbox, die niemand liest
wp_mail() kann langsam sein, vom Spamfilter gefressen oder vom Hoster ganz abgeschaltet
Die Website bleibt down, während Sie auf eine Nachricht warten, die vielleicht nie ankommt
Jede Minute Warten ist eine weitere Minute Fehlerseite für Ihre Besucher

Ein eingeloggter Administrator geht direkt zur signierten Recovery-Mode-URL - ohne E-Mail-Umweg
Sie beweisen trotzdem, dass Sie es sind: Cores Re-Login-Gate bleibt bestehen
Das kaputte Plugin wird beim nächsten Request vom eigenen Handler des Cores pausiert
Aus einem weißen Bildschirm wird eine echte Fehlerseite statt einer leeren Antwort

Gleiches Ziel auf beiden Wegen. Das Drop-in entfernt nur den langsamsten, unzuverlässigsten Schritt aus der Mitte.

Was die Fatal-Error-Recovery-Drop-ins tun

Zwei Drop-ins werden bei der Aktivierung von WP Multitool in wp-content abgelegt und bleiben dort, bis Sie das Plugin deaktivieren. Es gibt keinen Schalter und nichts zu konfigurieren - eine Website kann ihre Crash-Wiederherstellung nicht verlieren, weil jemand eine Einstellung abschaltet.

Datei	Was er tut
`fatal-error-handler.php`	Überschreibt Cores Fatal-Error-Handler. Wenn ein eingeloggter Administrator auf einen Plugin- oder Theme-Fatal trifft, baut es Cores signierte Recovery-Mode-URL sofort und schickt Sie zum Login-Gate - und überspringt die E-Mail komplett
`php-error.php`	Rendert den Fehler selbst. Ein Fatal, der früher in einem leeren Body endete, erzeugt jetzt WordPress' echte „critical error"-Seite, damit Sie immer eine sichtbare Antwort bekommen

Nachdem Sie Ihr Passwort erneut eingegeben haben, läuft der nächste Crash über Cores eigenen Handler, der die fehlerhafte Extension pausiert. Diese Pause ist es, die die Website zurückbringt - mein Drop-in entfernt das Warten zwischen dem Crash und dem Recovery-Link. Die URL ist Cores signierte; nichts davon gelangt an Ihre Besucher.

Was es nicht tut - lesen Sie das, bevor Sie sich darauf verlassen

Ausgeloggte Besucher sehen so oder so dieselbe Fehlerseite. Für sie ist die Website down, bis die kaputte Extension pausiert ist. Fremden einen Recovery-Link zu geben hieße, ihnen Ihr Admin-Panel zu geben, also bekommt nur ein eingeloggter Admin überhaupt einen.
Nur Plugin- und Theme-Fatals. Ein Crash innerhalb des WordPress-Cores, eines Drop-ins oder einer kaputten wp-config.php kann von Recovery Mode nicht pausiert werden - Sie bekommen die schlichte Fehlerseite.
Kein Multisite. Auf einer Netzwerk-Installation tritt das Drop-in beiseite und der Core behandelt den Crash auf dem Standardweg.
Es ist kein Backup. Ein kaputtes Plugin zu pausieren stellt nichts wieder her - wenn der Crash Daten beschädigt hat, brauchen Sie Ihr Hoster-Backup oder ein echtes.
Es verhindert den Crash nicht. Der schlechte Code läuft weiter und schlägt weiter fehl. Sie kommen schneller wieder hinein, mit bereits benanntem Übeltäter.
Eine tote Datenbank oder ein Hoster-Ausfall liegt unter dieser Schicht. WordPress stirbt, bevor der Handler lädt, also gibt es nichts abzufangen.

wp-config.php selbst kaputt?

Falsche Datenbank-Zugangsdaten oder ein schlechter Edit tötet WordPress, bevor irgendein Handler lädt. Für diesen Fall liefert Config Manager (Pro) einen WP-CLI-Rettungsbefehl, der ein wp-config-Backup wiederherstellt, ohne WordPress überhaupt zu booten - er funktioniert bei komplett unerreichbarer Datenbank.

Wieder drin? Jetzt sehen, was wirklich kaputtging

Recovery Mode nennt die Extension, die es pausiert hat. Der Fehler, der die Website getötet hat, steht in debug.log - falls Sie WP_DEBUG_LOG an haben - und eine vielbesuchte Website kann hunderte nahezu identischer Zeilen pro Request schreiben, also sitzt die Fatal-Zeile unter einem Haufen Wiederholungen.

Debug Log Guard (Pro) liest das Log, ohne es zu laden. Es gruppiert die Wiederholungen in eine Tabelle - Nachricht, Zähler, Quell-Plugin oder Theme, zuerst und zuletzt gesehen - und streamt den Tail, damit sich ein mehrere Gigabyte großes Log in Sekunden öffnet, statt Ihren Editor abstürzen zu lassen. Die Zeile, die die Website zu Fall brachte, schwimmt nach oben, ihrer Quelle bereits zugeordnet.

Wieder drin und wollen den Beweis, was kaputtging? Debug Log Guard verwandelt das Log in eine gruppierte Tabelle mit benanntem Übeltäter.

Pro ab $79/Jahr →

FAQ: WordPress-Website down

Warum sagt meine WordPress-Website „There has been a critical error on this website"?

Ein PHP-Fatal - fast immer in einem Plugin oder dem Theme - hat den Request gestoppt. WordPress hat ihn in einem Shutdown-Handler abgefangen und statt einer weißen Seite diese Meldung ausgegeben. Ihre Dateien und Datenbank sind intakt; eine Extension ist abgestürzt und hat die Website mitgerissen.

Wie komme ich zurück in wp-admin, wenn die Website down ist?

WordPress mailt einen Recovery-Mode-Link an die Admin-Adresse der Website - anklicken, erneut einloggen, und das kaputte Plugin wird pausiert. Mit den Drop-ins von WP Multitool wird ein eingeloggter Administrator beim Fatal direkt auf diese signierte Recovery-Mode-URL geschickt, es gibt also keine E-Mail, auf die man warten muss.

Die WordPress-E-Mail zum Recovery Mode ist nie angekommen - was jetzt?

Spam prüfen, dann prüfen, welche Adresse in Einstellungen → Allgemein steht - es ist oft eine Mailbox, die niemand liest, und manche Hoster verlangsamen oder blockieren wp_mail() ganz. Das Fatal-Error-Recovery-Drop-in baut die signierte URL sofort für einen eingeloggten Admin, statt sie zu mailen, der Ablauf kann also nicht an E-Mail hängen bleiben.

Ist meine Website für immer weg? Wurde ich gehackt?

Fast nie. Ein kritischer Fehler nach einem Update, einem PHP-Versionswechsel oder einer Dateiänderung ist eine schlechte Extension, kein Hack und kein Datenverlust. Recovery Mode pausiert den Übeltäter und die Website kommt zurück; Ihr Content, Ihre Dateien und Ihre Datenbank sind unberührt.

Behebt das Recovery-Drop-in den Fehler?

Nein - es bringt Sie schneller in Recovery Mode, und die kaputte Extension wird von Cores eigenem Handler pausiert. Das abgestürzte Plugin braucht trotzdem ein Update, einen Ersatz oder einen Bugreport an seinen Autor. Das Drop-in verschafft Ihnen Zugang und einen Namen, keinen Patch.

Funktioniert Fatal-Error-Recovery auf Multisite?

Nein. Auf einer Netzwerk-Installation tritt das Drop-in beiseite und WordPress behandelt den Crash auf dem Standardweg - die Recovery-E-Mail an die Admin-Adresse. Single-Site-Installationen bekommen die direkte Weiterleitung.

Was ist mit einem weißen Bildschirm ganz ohne Fehlermeldung?

Das ist der White Screen of Death - ein Fatal, der feuert, bevor WordPress seine Fehlerseite rendern kann. WP Multitools Drop-in php-error.php stellt sicher, dass der Crash trotzdem die echte „critical error"-Seite erzeugt, damit Sie immer etwas sehen statt einer leeren Antwort.