„Es gab einen kritischen Fehler auf deiner Website“ — der Reihe nach

Ein Satz, eine weiße Seite, sonst nichts: „Es gab einen kritischen Fehler auf deiner Website."

Die Meldung ist absichtlich nichtssagend — die echte Fehlermeldung würde Pfade und Versionsnummern verraten, und die gehören nicht auf eine öffentliche Seite. Sie existiert trotzdem. Man muss sie nur abholen.

Zuerst: ins Postfach schauen#

Seit WordPress 5.2 verschickt der Fehlerschutz eine E-Mail an die Administratoradresse, sobald er zuschlägt. Darin steht in aller Regel schon die Antwort: welches Plugin, welche Datei, welche Zeile.

Die Mail enthält außerdem einen Link in den Wiederherstellungsmodus. Der meldet dich an und deaktiviert das schuldige Plugin vorübergehend, damit du überhaupt wieder ins Backend kommst.

Wenn keine Mail da ist, liegt es meist an einem der drei: falsche Adresse hinterlegt, der Server verschickt keine Mails, oder sie steht im Spam. Dann geht es anders weiter.

Die Fehlermeldung sichtbar machen#

In der wp-config.php, oberhalb der Zeile mit That's all, stop editing:

``php define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false ); ``

Die Kombination ist mit Absicht so gewählt: schreiben ja, anzeigen nein. Der Fehler landet in wp-content/debug.log, und deine Besucher sehen weiterhin nichts. Eine Seite, die im Klartext Dateipfade ausgibt, ist ein Geschenk an jeden, der sie sich ansieht.

Seite einmal aufrufen, dann debug.log herunterladen. Die letzte Zeile ist deine.

Hinterher wieder ausschalten. Ein debug.log, das monatelang mitläuft, wird groß und ist über den Browser abrufbar, wenn niemand das Verzeichnis schützt.

Die Meldung lesen#

Drei Typen decken fast alles ab:

Allowed memory size of ... exhausted — der PHP-Speicher reicht nicht. In wp-config.php:

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

Greift das nicht, setzt der Hoster ein hartes Limit; dann hilft nur der Support. Und: Speicherhunger ist selten die Ursache, meistens ein Symptom — irgendein Plugin verarbeitet zu viel auf einmal.

syntax error, unexpected ... — jemand hat eine PHP-Datei bearbeitet. Der Pfad in der Meldung sagt dir, wer. Wenn das die functions.php deines Themes ist und du gerade etwas eingefügt hast: Das war es.

Uncaught Error: Call to undefined function oder Class not found — meistens eine PHP-Version, die nicht passt, oder ein Plugin, das ein anderes voraussetzt. Der Weg dorthin steht in WordPress PHP-Version aktualisieren.

Ohne Zugang zum Backend#

Wenn du nicht einmal mehr an die Anmeldung kommst, geht alles über FTP oder den Dateimanager des Hosters.

Plugins stilllegen: Ordner wp-content/plugins in plugins-aus umbenennen. WordPress findet keine Plugins mehr und deaktiviert alle. Kommt die Seite zurück, war es eines davon. Dann den Ordner zurückbenennen und die Plugins einzeln wieder einschalten — der letzte vor dem erneuten Ausfall ist der Täter.

Theme stilllegen: Ordner des aktiven Themes umbenennen. WordPress fällt auf ein Standard-Theme zurück, sofern eines installiert ist.

Die Reihenfolge ist nicht beliebig: Plugins zuerst, weil sie häufiger schuld sind und der Schritt weniger sichtbar ist.

Wenn nichts davon greift#

Dann steht die Ursache meistens nicht in PHP, sondern daneben:

• Datenbank nicht erreichbar — dafür gibt es eine eigene Meldung und einen eigenen Weg, siehe Fehler beim Aufbau einer Datenbankverbindung.
• .htaccess kaputt — nach einem Plugin-Wechsel oder von Hand editiert. Der Sollzustand steht in Die Standard-.htaccess von WordPress.
• Dateien verändert, ohne dass du es warst. Wenn der Fehler ohne jede Änderung deinerseits auftauchte, ist das ein Grund nachzusehen: Gehackte Website erkennen und, wenn sich der Verdacht erhärtet, WordPress gehackt — was tun.

Danach#

Der Fehler ist weg, die Ursache oft nicht. Zwei Dinge, die den nächsten Ausfall unwahrscheinlicher machen: eine Staging-Umgebung, in der Aktualisierungen zuerst laufen, und ein Backup, das jemand schon einmal zurückgespielt hat. Ein Backup, das nie getestet wurde, ist eine Vermutung.