Websupporter

Vor allem über WordPress.

Fatale Fehler in WordPress 5.2

Zugegeben, der Titel für diesen Beitrag ist Nahe am Clickbait, aber einen Titel für dieses neue Feature in WordPress 5.2 zu finden, der kein Clickbait darstellt ist so gut wie unmöglich. Es geht um den sogenannten „Fatal Error Recovery Mode“, welcher mit WordPress 5.2 in den Core kommen wird.

Sicherlich hast Du das auch schon erlebt: Du aktualisierst ein Plugin und plötzlich sehen Deine Besucher nur noch einen weißen Bildschirm, wo eigentlich Deine Startseite hätte erscheinen sollen. Der sogenannte „White Screen of Death“. Meistens bedeutet dies, dass es einen Programmierfehler im Plugin oder Theme gibt, welcher dazu führt, dass die Ausführung von WordPress insgesamt nicht mehr statt finden kann. Der Server weiß schlichtweg nicht mehr, was er tun soll und bricht die Ausführung von WordPress ab; die Besucher erhalten eine weiße Seite ohne weitere Informationen, warum dem so ist. Oder sie erhalten (wenn die Konstante WP_DEBUG auf true gesetzt ist) eine kryptische Fehlermeldung, welche die Sache eigentlich nur noch schlimmer macht:

PHP Fehlermeldung, wenn WP_DEBUG gesetzt ist.
Eine kryptische Fehlermeldung, welche Besucher bisher erhielten. Der sogenannte „White Screen of Death“

Eine gecrashte Seite ist der Albtraum des Admins

Für Seitenbetreiber ist dieses Szenario die reinste Hölle. Während es für mich und viele andere WordPress Entwickler sozusagen zum Tagesgeschäft gehört, sich mit solchen Fehlern herumzuschlagen, benutzen die meisten Leute WordPress tatsächlich nicht um des WordPress‘ Willens, sondern, um ihre spezifische Expertise zu verbreiten. Wenn das nicht gerade PHP oder WordPress ist, dann ist ein solcher Fehler schlichtweg das Ende der Webseite, beziehungsweise häufig stunden-, wenn nicht tagelanges, Suchen und Fragen im Supportforum und auf Facebook. Zwei kleine Kostproben:

Ich war jetzt einige Wochen nicht mehr eingelogged und bin am Montag wieder mal rein um Anpassugnen anzufügen. Ich habe dann auch gleich alls hängigen Updates sofort installiert um mit dem neuesten Stand loslegen zu können. […]
Und jetzt mein Problem: Meine zuvor kreierte Seite ist nur noch ‚weiss‘.

https://de.wordpress.org/support/topic/seite-verschwunden/

ich habe, wie ich glaubte mustergültig, ein Child-Theme erstellt. Die Umstellung auf dieses Child-Theme hatte zwei Konsequenzen:
1) Die Seite zeigt keine Inhalte mehr
2) Ich bin von der WP-Administration ausgeschlossen, kann mich also nicht mehr einloggen (bspw. um wieder auf das Parent-Theme zurückzustellen)
In meiner Verzweiflung habe ich via FTP alle Dateien des Parent-Theme in den Ordner des Child-Theme kopiert. Das hat aber auch nicht die erhoffte Wirkung gebracht. Darum bin ich hier.

https://de.wordpress.org/support/topic/weisser-bildschirm-nichts-tut-sich/

Die WordPress Supportforen sind voll mit solchen Hilfegesuchen.

Der „Fatal Error Recovery Mode“

Damit soll jetzt Schluss sein. WordPress führt den sogenannten „Fatal Error Recovery Mode“ ein. Tritt ein schwerwiegender Fehler in WordPress auf, so schaltet WordPress in diesen Modus. Besucher sehen dann statt eines nichtssagenden weißen Bildschirms eine kleine Meldung:

The site is experiencing technical difficulties.
Diese neue Meldung erhält der Besucher, wenn ein schwerwiegender Fehler auftritt.

Somit sind schon einmal die Seitenbesucher abgeholt und wissen Bescheid. Doch auch der Seitenbetreiber erhält eine Emailbenachrichtigung, dass seine Seite gerade nicht funktioniert. In dieser Email befindet sich zusätzlich ein Link. Folgt man diesem, kommt man zur Login-Seite von WordPress und kann sich wie gewohnt einloggen:

Youtube

Click the button below to load the content from Youtube.

Dieses Video demonstriert den Fatal Error Recovery Mode in WordPress

WordPress weißt den Administrator nun den Weg zu dem Plugin, welches den Fehler schmeißt und der Administrator ist in der Lage, das Plugin einfach zu deaktivieren! Alles innerhalb von WordPress, obwohl dieses eigentlich gerade vollkommen überfordert ist, eine einfache Seite zu rendern!

Vor WordPress 5.2 hätte man eigentlich über FTP das entsprechende Plugin finden und löschen oder umbenennen müssen. Jetzt führt WordPress den Administrator ganz einfach durch den Admin, um das Problem zu beheben!

Das größere Bild

Dieses Feature für sich genommen ist schon ein großer Schritt zu einer besseren Verwaltung der eigenen WordPress Webseite. Es bedarf nun nicht mehr des „Expertenwissens“ von WordPress-Profis, um eine Seite nach einem White Screen wieder von den Toten zurück zu holen. Insofern steht dieses Feature in der guten Tradition von WordPress‘ Wahlslogan „Democratize Publishing“.

Doch das Feature wurde noch aus einem anderen Grund eingeführt. WordPress verabschiedet sich mit seiner Version 5.2 von der längst veralteten PHP Version 5.2.

Für manche Seitenbetreiber bedeutet ein solcher Sprung in der unterstützten PHP Version, dass sie PHP aktualisieren müssen. Sollten auf diesen Installationen nun Plugins oder Themes rumlungern, welche mit moderneren PHP Versionen nicht kompatibel sind, führt dies zwangsläufig zu Problemen, häufig genug zu einem „White Screen of Death“.

Der Recovery Modus ist also auch eine Handreichung an jene Seitenbetreiber, welche sich bisher nicht trauten PHP zu aktualisieren, weil sie einen solchen White Screen befürchteten. WordPress hat damit einen Mechanismus etabliert, welcher es ermöglicht, sehr viel zügiger die Unterstützung veralteter PHP Versionen aufzugeben.

Was haltet Ihr von dem neuen Feature? Gab es Situationen, in welchen Ihr dieses Feature gerne schon früher im Core gesehen hättet?

Über den Autoren

Seine erste Webseite hat David Remer 1998 in HTML verfasst. Wenig später war er fasziniert von DHTML und JavaScript. Nach jahrelanger Freelancerei arbeitete er zunächst für Inpsyde und ist heute Entwickler bei Automattic. Außerdem hat er das Buch "WordPress für Entwickler" verfasst.

Kommentare

    1. Hi Jens,
      ich hatte es in einigen Szenarien ausprobiert und war ganz zufrieden. Das Video zeigt ja eines der Szenarien. Aber der Praxistest auf Millionen von Seiten steht natürlich noch aus. Multisite und mu-plugins sind derzeit noch nicht integriert. Bin gespannt, ob das noch nachgezogen werden kann.

      Beste Grüße,
      David.

  1. Hallo David, danke für die Erklärung. „Error thrown – Call to undefined function wp_is_recovery_mode()“ Wenn ich es richtig verstehe, ist das dieser Fall. Was ist, wenn diese Email von der du sprichst (mit Weiterleitung zum Problem) unauffindbar ist? Ich bin dir sehr dankbar für eine Rückmeldung. Ich finde noch nicht einmal eine Mailadresse um darum zu bitten, die Problem-beheb-mail (nochmal) zuzuschicken.

    1. Hi Julia,
      wenn man die Mail verloren hat sollten die „traditionellen“ Wege (beispielsweise über FTP Plugins umbenennen) eigentlich trotzdem noch funktionieren.

      „Error thrown – Call to undefined function wp_is_recovery_mode()“

      Das verstehe ich nicht ganz. Hast Du schon auf WordPress 5.2 aktualisiert?

      Beste Grüße und danke für Deine Nachfrage,
      David.

  2. Hallo David, bin grad durch mein Problem auf diesen beitrag gestoßen und vielleicht kannst du mir ja weiterhelfen. Ich erlebe als WP Laie gerade diesen Alptraum durch .. Wollte vorhin das Gutenberg Plugin installieren und hab dadurch meine Seite anscheinend zum Einsturz gebracht. Weiß überhaupt nicht weiter.. Hab überhaupt keinen Zugriff mehr auf WordPress.
    Es zeigt folgendes an: Fatal error: Uncaught Error: Call to undefined function register_block_type() in /var/www/****/wp-content/plugins/coblocks/includes/class-coblocks-form.php:130 Stack trace: #0 /var/www/****/wp-includes/class-wp-hook.php(286): CoBlocks_Form->register_form_blocks(“) #1 /var/www/****/wp-includes/class-wp-hook.php(310): WP_Hook->apply_filters(NULL, Array) #2 /var/www/****/wp-includes/plugin.php(453): WP_Hook->do_action(Array) #3 /var/www/****/wp-settings.php(450): do_action(‚init‘) #4 /var/www/****/wp-config.php(115): require_once(‚/var/www/vhosts…‘) #5 /var/www/****/wp-load.php(37): require_once(‚/var/www/vhosts…‘) #6 /var/www/****/wp-admin/admin.php(31): require_once(‚/var/www/vhosts…‘) #7 /var/ in /var/www/****/wp-content/plugins/coblocks/includes/class-coblocks-form.php on line 130

    Hoffe auf Hilfe und beste Grüße
    Lukas

    1. Hi Lukas,
      auf den ersten Blick sieht es für mich so aus, als hättest Du noch eine WordPress Version kleiner 5.0. Am Besten wäre es wahrscheinlich erstmal WordPress zu aktualisieren. Da Du derzeit aber gar nicht in WordPress reinkommst kannst du erstmal via FTP in das wp-content/plugins Verzeichnis und dort das Verzeichnis „coblocks“ löschen. Dann sollte zumindest WordPress wieder laufen.

      Ich hoffe, das hilft 🙂

  3. Hallo,
    seit heute kann ich meine websites nicht mehr starten, bei einer Seite kommt der weiße Bildschirm, für eine andere Seite habe ich eine mail von wordpress bekommen, in der die Fehlerdetails beschrieben werden und ein ling für den „“Wiederherstellungsmodus“. Wenn ich diesen link anklicke, erscheint die Fehlermeldung „Recovery Mode not initialized“. habe schon über ftp im wp-content file die plugins umbenannt in plugins.hold, aber trotz allem komme ich nicht auf mein dashboard, was kann ich noch tun?

  4. Mittlerweile ist die Funktion ganz nützlich, denn als Tipp: Wenn diese Seite mit dem kritischen Fehler auftaucht, dann weiß man, dass man in den debug log reinschauen muss und dort dann fast immer die Fehlermeldung steht. So kann man das Problem schnell identifizieren.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.