WordPress: „Es gab einen kritischen Fehler auf dieser Website“ – was tun?
WordPress meldet einen kritischen Fehler? So nutzen Sie den Wiederherstellungsmodus, lesen das Fehlerprotokoll und finden die Ursache ohne Risiko.
- Veröffentlicht
- Autor
- Mario Gvozden
- Lesezeit
- 7 Minuten
- Leistung
- Fehler beheben
Statt Ihrer Website erscheint ein weißer Bildschirm mit einem Satz: „Es gab einen kritischen Fehler auf dieser Website.“ Manchmal betrifft das nur das Backend, manchmal die ganze Seite. Die Meldung klingt dramatisch, hat aber eine nüchterne Bedeutung: PHP ist auf einen schwerwiegenden Fehler gestoßen und hat die Ausführung abgebrochen. WordPress fängt diesen Abbruch ab und zeigt statt einer technischen Fehlermeldung diesen Hinweis an.
Die gute Nachricht: Die Ursache steht fast immer in einem Protokoll, und Ihre Daten sind in aller Regel unversehrt. Die schlechte: Ohne Protokoll stochert man im Dunkeln.
Woher die Meldung kommt
Seit Version 5.2 hat WordPress einen eingebauten Schutz gegen fatale PHP-Fehler. Tritt ein solcher Fehler auf, passiert zweierlei:
- Besucher sehen die Meldung über den kritischen Fehler statt einer kaputten Seite.
- WordPress schickt eine E-Mail an die Administrator-Adresse der Website. Darin steht, welches Plugin oder Theme den Fehler ausgelöst hat, und ein Link zum sogenannten Wiederherstellungsmodus.
Typische Auslöser sind Plugin- oder Theme-Updates, eine neue PHP-Version beim Hoster, ein ausgeschöpftes Speicherlimit oder eine Änderung in der functions.php.
Schritt 1: Postfach prüfen
Suchen Sie im Postfach der Administrator-Adresse (auch im Spam-Ordner) nach einer Nachricht von WordPress mit dem Hinweis auf ein technisches Problem. Die Mail nennt in der Regel die Komponente, in der der Fehler aufgetreten ist, und die Datei samt Zeilennummer.
Über den Link in der Mail melden Sie sich im Wiederherstellungsmodus an. In diesem Modus pausiert WordPress das fehlerhafte Plugin oder Theme nur für Ihre Sitzung. Sie können es dann deaktivieren, auf eine ältere Version zurücksetzen oder ersetzen. Für die Besucher bleibt der Fehler bestehen, bis Sie das Problem tatsächlich gelöst haben.
Kommt keine Mail an, ist häufig der Mailversand der Website nicht richtig eingerichtet, oder die hinterlegte Administrator-Adresse ist ein Postfach, das niemand liest. Dann geht es mit dem Protokoll weiter.
Für die Zukunft lässt sich die Empfängeradresse der Wiederherstellungs-Mail unabhängig von der Administrator-Adresse festlegen, und zwar in der wp-config.php (mehr zu dieser Datei im nächsten Schritt):
define( 'RECOVERY_MODE_EMAIL', 'technik@ihre-firma.de' );
So landet die Nachricht bei der Person, die im Ernstfall tatsächlich handelt, und nicht im Sammelpostfach.
Schritt 2: Fehlerprotokoll aktivieren
In der Datei wp-config.php im Hauptverzeichnis Ihrer Installation lässt sich der Debug-Modus einschalten. Fügen Sie die folgenden Zeilen oberhalb von /* That's all, stop editing! */ ein bzw. ändern Sie vorhandene Einträge:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
Damit werden Fehler in die Datei wp-content/debug.log geschrieben, aber nicht im Browser angezeigt. Das ist wichtig: Fehlermeldungen auf einer öffentlichen Seite verraten Pfade und Details Ihrer Installation.
Rufen Sie danach die fehlerhafte Seite noch einmal auf und öffnen Sie debug.log per FTP oder über den Dateimanager Ihres Hosters. Gesucht ist ein Eintrag mit PHP Fatal error, zum Beispiel:
PHP Fatal error: Uncaught Error: Call to undefined function wc_get_product()
in /wp-content/plugins/mein-plugin/includes/export.php:42
Der Pfad zeigt, wo der Fehler entstanden ist. Hier ruft ein Plugin eine WooCommerce-Funktion auf, die nicht verfügbar ist, etwa weil WooCommerce deaktiviert wurde oder später geladen wird.
Schalten Sie den Debug-Modus nach der Fehlersuche wieder ab und löschen Sie debug.log. Die Datei kann sensible Informationen enthalten und liegt in einem Verzeichnis, das je nach Server-Konfiguration öffentlich abrufbar ist.
Schritt 3: Typische Ursachen erkennen
Plugin oder Theme nach einem Update
Steht im Pfad wp-content/plugins/<name>/, ist das Plugin der Auslöser – oder zumindest der Ort, an dem der Fehler sichtbar wird. Nicht immer ist es selbst schuld: Oft verträgt es sich nicht mit einem anderen Plugin oder einer älteren PHP-Version. Wie Sie Konflikte gezielt eingrenzen, beschreiben wir im Beitrag WordPress-Plugin-Konflikte finden.
PHP-Version
Hat der Hoster die PHP-Version angehoben, fallen ältere Plugins mit Meldungen wie Uncaught TypeError oder Call to undefined function auf, weil Funktionen entfernt oder strenger geworden sind. In vielen Hosting-Oberflächen lässt sich die PHP-Version vorübergehend zurückstellen. Das ist eine Notlösung, keine Dauerlösung.
Speicherlimit
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted
Dann reicht der Arbeitsspeicher für PHP nicht. Sie können das Limit in der wp-config.php erhöhen:
define( 'WP_MEMORY_LIMIT', '256M' );
Ob das wirkt, hängt vom Hoster ab, denn das Server-Limit kann niedriger sein. Steigt der Speicherverbrauch plötzlich stark an, ist ein erhöhtes Limit nur ein Pflaster. Die eigentliche Frage lautet dann, welches Plugin so viel verbraucht.
Fehler in der functions.php
Wurde kurz vorher Code in die functions.php des Themes eingefügt, etwa ein Schnipsel aus einem Tutorial, ist das der erste Verdächtige. Ein fehlendes Semikolon oder eine doppelt deklarierte Funktion reicht.
Schritt 4: Wenn Sie nicht mehr ins Backend kommen
Ohne Wiederherstellungsmodus und ohne Backend-Zugang hilft der Dateizugriff:
- Per FTP oder Dateimanager in
wp-content/plugins/wechseln. - Den Ordner des verdächtigen Plugins umbenennen, zum Beispiel von
mein-plugininmein-plugin.off. WordPress deaktiviert es dann automatisch. - Ist unklar, welches Plugin betroffen ist, den gesamten Ordner
pluginsumbenennen. Damit sind alle Plugins deaktiviert. Danach den ursprünglichen Namen wiederherstellen und die Plugins im Backend einzeln reaktivieren.
Mit WP-CLI geht das schneller, sofern Ihr Hoster SSH anbietet:
wp plugin list --status=active
wp plugin deactivate mein-plugin
# Bei einem Fehler, der schon beim Laden auftritt:
wp plugin deactivate mein-plugin --skip-plugins
Für Themes funktioniert das Umbenennen ebenso. WordPress fällt dann auf ein installiertes Standard-Theme zurück, falls eines vorhanden ist.
Drei Fehlannahmen
„Ich installiere WordPress neu.“ Eine Neuinstallation des WordPress-Kerns ersetzt die Dateien in wp-admin und wp-includes. Liegt der Fehler in einem Plugin, im Theme oder in der Server-Konfiguration, ändert sie nichts. Sie kostet nur Zeit und birgt das Risiko, eigene Anpassungen zu überschreiben.
„Ich spiele einfach das Backup von gestern ein.“ Das kann die Seite schnell wiederherstellen. Bei Shops und Websites mit Formularen gehen aber alle Bestellungen und Eingaben seit dem Backup verloren. Und wenn die Ursache ein automatisches Update war, tritt der Fehler beim nächsten Update erneut auf.
„Das Plugin, das in der Mail steht, ist schuld.“ Es ist der Ort, an dem der Fehler sichtbar wurde. Die eigentliche Ursache kann ein anderes Plugin sein, das eine Funktion verändert oder eine Bibliothek in einer anderen Version lädt. Den Hinweis ernst nehmen, aber das Protokoll lesen.
Warum Sie das nicht auf der Live-Seite tun sollten
Das alles ist auf einer Live-Seite möglich, aber riskant. Umbenannte Plugin-Ordner können Einstellungen zurücksetzen, ein deaktiviertes Shop-Plugin nimmt Bestellungen offline, und jeder Versuch ist für Ihre Besucher sichtbar. Wenn die Seite ohnehin schon nicht erreichbar ist, mag das zweitrangig wirken. Für die eigentliche Ursachenforschung ist eine Staging-Kopie trotzdem der richtige Ort.
Die meisten Hoster bieten Staging mit einem Klick an. Dort können Sie Updates wiederholen, Plugins wechseln und PHP-Versionen testen, ohne dass Kunden etwas davon merken. Erst wenn die Ursache gefunden und behoben ist, wird die Korrektur auf die Live-Seite übertragen. Warum wir grundsätzlich so arbeiten, erklärt der Beitrag Warum wir nie auf Ihrer Produktion arbeiten.
Kurz-Checkliste
- Postfach der Administrator-Adresse auf die WordPress-Mail geprüft
- Wiederherstellungsmodus genutzt, falls verfügbar
-
WP_DEBUG_LOGaktiviert,WP_DEBUG_DISPLAYaus -
PHP Fatal errorindebug.loggefunden und Pfad notiert - Zuletzt geänderte Plugins, Themes und PHP-Version abgeglichen
- Ursache auf einer Staging-Kopie nachgestellt und behoben
- Debug-Modus wieder ausgeschaltet,
debug.loggelöscht - Vollständiges Backup vor dem nächsten Update eingeplant
Häufige Fragen
Sind meine Daten nach einem kritischen Fehler in WordPress verloren?
In aller Regel nicht. Die Meldung bedeutet, dass PHP auf einen schwerwiegenden Fehler gestoßen ist und die Ausführung abgebrochen hat; Inhalte und Datenbank bleiben davon normalerweise unberührt. Die Ursache steht fast immer im Fehlerprotokoll.
Was ist der Wiederherstellungsmodus in WordPress?
Seit Version 5.2 schickt WordPress bei einem fatalen Fehler eine E-Mail an die Administrator-Adresse, mit einem Link zu diesem Modus. Darin pausiert WordPress das fehlerhafte Plugin oder Theme nur für Ihre Sitzung, sodass Sie es deaktivieren, zurücksetzen oder ersetzen können. Für Besucher bleibt der Fehler bestehen, bis das Problem tatsächlich gelöst ist.
Hilft es, WordPress neu zu installieren?
Meist nicht. Eine Neuinstallation ersetzt nur die Dateien in wp-admin und wp-includes; liegt der Fehler in einem Plugin, im Theme oder in der Server-Konfiguration, ändert sie nichts. Sie kostet Zeit und kann eigene Anpassungen überschreiben.
Wenn Sie es nicht selbst machen möchten: Einen kritischen Fehler nach einem Plugin-Update beheben wir als eine Aufgabe auf Ihrem Board. Voraussetzung ist eine Staging-Kopie, in die Sie unsere Adresse als Administrator-Benutzer einladen; Zugangsdaten per E-Mail brauchen wir nicht. Mit dem Start stehen die Abnahmekriterien auf der Karte, und 48 Stunden danach – gezählt von Montag 8 Uhr bis Freitag 16 Uhr – erhalten Sie die Behebung auf der Staging-Seite mit einer kurzen Notiz zur Ursache, vorher geprüft und freigegeben von einem Senior-Entwickler. Wann die Korrektur auf die Live-Seite geht, entscheiden Sie. Die erste Aufgabe ist kostenlos, eine pro Unternehmen: Erste Aufgabe anlegen. Weitere Fehler und Updates arbeiten wir im Prozess-Abo in der Reihenfolge ab, die Sie auf dem Board festlegen. Details finden Sie unter Fehler beheben und im Leistungskatalog.
Die erste Aufgabe ist kostenlos – eine pro Unternehmen. Sie legen einen Workspace an, geben Zugang per Einladung und schreiben die Aufgabe auf Ihr Board. Wir liefern sie 48 Stunden nach Start, gezählt Mo 8 bis Fr 16 Uhr: Start am Montag um 10 Uhr – Lieferung am Mittwoch um 10 Uhr. Jede Lieferung prüft und gibt ein Senior-Entwickler frei, bevor sie zu Ihnen geht.
Danach im Prozess-Abo: Sie schreiben Aufgaben aufs Board und bestimmen die Reihenfolge, wir setzen sie um. Prozess-Abo 2,5: 2.500 € im Monat, 1 Aufgabe gleichzeitig in Arbeit, bis zu 4 Aufgaben pro Monat; Prozess-Abo 5: 5.000 € im Monat, 1 Aufgabe gleichzeitig in Arbeit; Prozess-Abo 10: 10.000 € im Monat, 2 Aufgaben parallel in Arbeit. Gezählt werden die Aufgaben, die wir im Abrechnungsmonat beginnen; eine Nachbesserung zählt nicht neu. Nicht genutzte Aufgaben verfallen am Monatsende. Preise zzgl. MwSt., nur für Unternehmen, monatlich kündbar – das Abo beginnt nur, wenn Sie es bestellen.
Fragen vorab oder mehr Aufgaben parallel? Im kostenlosen Projekt-Check (30 Minuten) klären wir das, auch für ein individuelles Abo.