Der WordPress White Screen of Death: Ein Leitfaden zur Wiederherstellung

WordPress hat, wie MacOS und jetzt sogar Windows, einen berüchtigten „White Screen of Death“ oder kurz „WSOD“. Der WSOD erscheint, wenn etwas schief geht. Sie sehen aus unbekannten Gründen einen leeren oder größtenteils leeren weißen Bildschirm. Was jetzt?

Was ist der WordPress White Screen of Death (WSOD)?

Es ist unwahrscheinlich, dass Sie unter normalen Bedingungen auf einer WordPress-Site auf den „White Screen of Death“ (WSOD) stoßen. Es ist einfach ein leerer weißer Bildschirm, der anstelle der öffentlichen Front-End- oder Back-End-Oberfläche einer WordPress-Site angezeigt wird. Es bedeutet, dass WordPress abgestürzt ist und nicht richtig geladen wird.

Warum? Was ist schief gelaufen?

Seit WordPress 5.2 im Mai 2019 veröffentlicht wurde, verfügt WordPress über einen Wiederherstellungsmodus, um Sie vor dem WSOD zu schützen. Ohne den Wiederherstellungsmodus würden Kompatibilitätsprobleme viele WSODs und frustrierte WordPress-Benutzer erzeugen. Wenn Ihr Server eine Version von PHP oder MySQL verwendet, die von einem Plugin, Design oder einer Erweiterung, die Sie installieren, nicht unterstützt wird, erhalten Sie den Wiederherstellungsmodus, anstatt Ihre Website zu beschädigen. Heutzutage ist ein PHP Out-of-Memory (OOM)-Fehler wahrscheinlich das häufigste verbleibende Szenario, das den WSOD-Schutz umgeht und Sie mit einem völlig leeren Bildschirm zurücklässt.

Ich habe mit dem WordPress Core Contributor Marius Jensen nachgefragt, um herauszufinden, was heutzutage noch eine echte WSOD verursachen könnte. Marius ist der Autor des Plugins Site Health (jetzt Health Check and Troubleshooting), dessen Konzept und Funktionen schließlich in den WordPress-Kern einflossen. (So ​​haben wir den Wiederherstellungsmodus und andere Schutzmaßnahmen erhalten.) Marius bestätigte, dass die einzige Möglichkeit, WordPress mit einem völlig leeren Bildschirm zum Absturz zu bringen, darin besteht, den Ausführungsfluss von PHP zu unterbrechen, damit der schwerwiegende Fehlerbehandler nicht so arbeiten kann, wie er sollte. Dies wird erreicht, indem die Verbindung zwischen PHP und Ihrem HTTP-Server unterbrochen wird. Sie erhalten kein Feedback zur Fehlerbehebung auf dem Bildschirm. Das wäre frustrierend, aber wenn Sie einfach in WordPress arbeiten, Plugins installieren und konfigurieren, ist dies unwahrscheinlich.

Bedeutet der White Screen of Death, dass WordPress gehackt wurde?

Nein, ein WSOD bedeutet nicht, dass die bösen Jungs Sie erwischt haben. In seltenen Fällen kann dies jedoch eine Nebenwirkung einer Sicherheitsverletzung sein. Wenn Sie der Meinung sind, dass Hacker Ihre Website kompromittiert haben, gehen Sie zu Kathy Zants Anleitung, How to Clean a Hacked WordPress Site.

Ein PHP-Codierungsfehler, ein Konflikt zwischen zwei oder mehr Plugins oder ein Problem in Ihrer Serverumgebung sind die wahrscheinlichsten Ursachen für einen WSOD. Zum Glück sind das keine Katastrophen! Ihre Website und ihr Inhalt sind nicht verloren gegangen. Wenn Sie möchten, können Sie einen WSOD selbst reparieren.

In diesem Artikel gehen wir die Liste möglicher Diagnosen und Heilmittel für das WSOD durch. Sie erfahren, wie Sie Ihre WordPress-Site wieder zum Leben erwecken. Sie werden auch lernen, wie WordPress auf einer tieferen Ebene funktioniert.

Vorschau anzeigen

Der WordPress White Screen of Death: Habe ich das getan?

Ja. Der White Screen of Death ist wahrscheinlich das Ergebnis von etwas DU hast es mit deiner WordPress-Seite gemacht.

Die Ursache für einen WSOD liegt normalerweise in einem WordPress-Plugin, das Sie gerade installiert und aktiviert haben. Oder es könnte das Ergebnis eines kürzlichen Updates sein. Ein neu hinzugefügtes oder aktualisiertes Plug-in kann mit einem anderen Plug-in in Konflikt stehen. In diesem Szenario versucht ein Plugin dasselbe wie ein anderes zu tun, oder sie handeln zu widersprüchlichen Zwecken.

Wenn ein Plugin, ein Design oder fehlerhafte PHP-Codeschnipsel einen schwerwiegenden Fehler verursachen, erhalten Sie möglicherweise einen WSOD. Sie können einen Syntaxfehler, einen Bug oder Code enthalten, der nicht mit der von Ihnen verwendeten PHP-Version kompatibel ist. Wenn Sie oder Ihr Host gerade Ihre PHP-Version aktualisiert haben – was eine gute Sache ist! — Inkompatible Plugins fangen an, Fehler zu werfen und könnten Ihre Website mit einem WSOD zum Absturz bringen. Wenn Sie WordPress 5.2 oder höher verwenden, wie Sie es sollten, aktivieren Inkompatibilitätsprobleme den Wiederherstellungsmodus, der viel hilfreicher ist als ein echtes WSOD.

Typischerweise ist der Schuldige das, was gerade mit einem Plugin, Design oder benutzerdefinierten Code geändert wurde.

Da die WSOD oft eine Reaktion auf die letzte (oder kürzlich erfolgte) Änderung ist, die sich auf die Funktionalität Ihrer Website auswirkt. Überprüfen Sie alle kürzlich vorgenommenen Änderungen. Konzentrieren Sie sich auf die Änderungen, die am wahrscheinlichsten ein Problem verursachen. Wenn Sie gerade ein neues Plugin installiert oder einen Designcode geändert haben, sind dies die ersten Stellen, an denen Sie nachsehen sollten, was möglicherweise schief gelaufen ist.

Wenn WordPress nur größtenteils tot ist

Alle WSODs sind nicht gleich und einige sind nicht einmal echte WSODs.

Möglicherweise erhalten Sie anstelle eines vollständig weißen Bildschirms eine Art Fehlermeldung. Es kann sich um eine Serverfehlermeldung über einen HTTP 500-Fehler oder eine verlorene Datenbankverbindung handeln. Es kann sich um eine kritische Fehlermeldung von WordPress handeln. Oder Ihre Website wird für Besucher normal geladen, aber wenn Sie versuchen, sich anzumelden, wird der weiße Bildschirm des Todes angezeigt. In anderen Fällen kann das Gegenteil der Fall sein: Sie können sich beim WordPress-Dashboard anmelden, aber das öffentlich zugängliche Frontend Ihrer Website zeigt allen einen leeren Bildschirm.

Wenn Ihre WSOD-Erfahrung auf eine dieser Beschreibungen zutrifft, gute Nachrichten! Ihre Website ist nur größtenteils tot. Es wird nicht schwer sein, es wiederzubeleben.

Wenn Sie beim Besuch Ihrer WordPress-Site oder beim Versuch, sich anzumelden, vor einem völlig leeren weißen Bildschirm stehen, ist das der wahre WSOD. Sie müssen ein wenig tiefer graben, um festzustellen, was es verursacht.

WordPress-Wiederherstellungsmodus und der weiße Bildschirm des Todes

Zum Glück für alle, die mit einem WSOD konfrontiert sind, wurde der Wiederherstellungsmodus in WordPress 5.2 eingeführt, um es zu beseitigen. Der Wiederherstellungsmodus fängt viele schwerwiegende Fehler ab und hilft Ihnen, sie zu beheben. Wenn Sie nicht die neueste Hauptversion des WordPress-Kerns verwenden, beginnen Sie dort. Sich auf den neuesten Stand bringen!

Dank des Wiederherstellungsmodus von WordPress ist es selten, dass ein völlig leerer weißer Bildschirm angezeigt wird, wenn etwas schief geht. Ab WordPress 6.1 siehst du häufiger ein weißes Fenster über einem grauen Bildschirm mit der folgenden Meldung:

Ältere Versionen von WordPress zeigen ähnlich formulierte Nachrichten wie „Die Website hat technische Schwierigkeiten“.

Wenn Sie zu einer Backend- /wp-admin URL navigieren, wird auch ein Hinweis angezeigt, der Sie auffordert, Ihr Administrator-E-Mail-Konto auf weitere Informationen zu überprüfen:

In anderen Fällen sehen Sie möglicherweise einen weißen Bildschirm mit fettem Text, der einen „Internen Serverfehler“ mit einer Art Erklärung und Anleitung zur Reparatur Ihrer Website beschreibt.

Willkommen bei der Wiederherstellung

Dies ist der Wiederherstellungsmodus. WordPress versucht, Ihnen dabei zu helfen, ihm wieder auf die Beine zu helfen.

Als Erstes müssen Sie die mit Ihrem WordPress-Administratorkonto verknüpfte E-Mail-Adresse überprüfen. WordPress versucht, schwerwiegende PHP-Fehler im gesamten ausgeführten Code zu identifizieren.

Wenn möglich, „pausiert“ WordPress ein Plugin oder anderen Code, der nicht funktioniert. WordPress verhindert, dass der fehlerhafte Code ausgeführt wird. Dann werden die Details per E-Mail an die Administratoren gemeldet.

In der E-Mail zum Wiederherstellungsmodus finden Sie Anweisungen und einen temporären Link zum Anmelden bei WordPress unter Wiederherstellungsmodus. (Dieser Link ist 24 Stunden lang gültig. Danach wird ein neuer gesendet, wenn auf der Website immer noch ein kritischer Fehler auftritt.)

PROFITIPP: Wenn du die Wiederherstellungsmodus-E-Mail nicht erhältst, kannst du dich möglicherweise trotzdem im Wiederherstellungsmodus bei WordPress anmelden, indem du die folgende Adresse zu deiner Basisseiten-URL hinzufügst, wenn du als Administrator angemeldet bist: /wp-login.php?action=entered_recovery_mode .

Hier haben Sie die Möglichkeit, weiter nachzuforschen. Wenn der Wiederherstellungsmodus ein bestimmtes Plugin als Ursache für Ihren WSOD identifiziert hat, deaktivieren Sie es. Dadurch wird Ihre Website für alle wieder verfügbar. Dann können Sie alle bekannten Probleme für dieses Plugin untersuchen. Schau mal ob es dafür ein Update gibt. Wenden Sie sich an die Personen, die für die Wartung verantwortlich sind.

Nicht jeder White Screen of Death ist in WordPress gleich

In wenigen Ausnahmefällen ist an anderer Stelle in WordPress oder deiner Serverumgebung etwas schief gelaufen. Möglicherweise ist ein Aktualisierungs- oder Installationsvorgang ins Stocken geraten, wodurch Ihre Website im Wartungsmodus stecken geblieben ist. Möglicherweise haben Sie, Ihr Hosting-Provider oder ein von Ihnen installiertes Plugin php.ini oder .htaccess -Dateien mit unerwarteten Ergebnissen geändert. Ihre vorhandene Umgebung unterstützt möglicherweise nicht die Anforderungen eines neu installierten Plugins.

Der WordPress-Wiederherstellungsmodus kann diese Situationen nicht bewältigen, erzeugt jedoch sichtbare Fehlermeldungen auf einem ansonsten weißen Bildschirm. Auf das Front-End Ihrer Website kann möglicherweise nicht zugegriffen werden, aber der Administrator-Anmeldebildschirm und die Back-End-Oberfläche funktionieren möglicherweise normal.

Dies sind keine echten WSOD-Situationen, aber sie sind genauso ärgerlich. Normalerweise verursacht eine der folgenden Bedingungen sie:

1. Sie stecken im Wartungsmodus fest

Während der Aktualisierung von WordPress Core, Plugins oder Themes geht WordPress in den „Wartungsmodus“. Wenn Sie zu einem beliebigen Teil der Website navigieren, wird ein grauer Bildschirm mit einem weißen Nachrichtenfenster angezeigt, das besagt:

Manchmal klärt sich das nicht in einer Minute, aber qualitätsverwaltetes WordPress-Hosting wird dies bemerken und mit einem automatisierten Prozess beheben. Wenn Sie einige Minuten ohne Änderung gewartet haben, können Sie den Wartungsmodus verlassen, indem Sie die .maintenance -Datei in Ihrem Web-/Anwendungsstammordner löschen, in dem WordPress installiert ist. (Um es zu sehen, müssen Sie möglicherweise die Anzeige von „unsichtbaren“ Dateien aktivieren, denen ein Punkt im Dateinamen vorangestellt ist.)

Wenn keine .maintenance -Datei vorhanden ist, wird Ihre Website wie erwartet geladen.

2. Sie haben eine Datei-Upload- oder Post-Größenbeschränkung erreicht

Ihre Website kann während eines Upload-, Post-Publishing- oder Formularübermittlungsprozesses zu einem weißen Bildschirm führen, weil Sie zu viele Daten senden.

Lösung: Erhöhen Sie Ihr Post-Content-Limit in wp-config.php :

 ini_set('pcre.recursion_limit',20000000);
ini_set('pcre.backtrack_limit',10000000);

Lösung: Erhöhen Sie Ihr Datei-Upload- und Beitragsgrößenlimit in php.ini :

 upload_max_filesize = 256 MB
post_max_size = 256M

Es kann auch hilfreich sein, die Zeit (in Sekunden) zu verlängern, bevor ein Beitrag oder eine Formularübermittlung abläuft. Sie können auch die Zeit erhöhen, die PHP zum Ausführen von Skripten und zum Analysieren der Eingabe hat. Darüber hinaus können wir die Anzahl der Variablen erhöhen, die in einer Formularübermittlung zulässig sind. Schließlich können wir das Zeitlimit angeben, nach dem PHP übermittelte Daten als Müll behandelt:

 max_execution_time = 300
max_input_time = 300
max_input_vars = 1000
session.gc_maxlifetime = 1000

Oder in .htaccess , httpd.conf oder virtualhost :

 php_value upload_max_filesize 256M
php_value post_max_size 256M
php_value max_execution_time 300
php_value max_input_time 300
php_value max_input_vars 1000
php_value session.gc_maxlifetime 1000

Oder in einem benutzerdefinierten Code-Snippet für WordPress oder einer Theme- functions.php -Datei:

 @ini_set( 'upload_max_filesize', '256M' );
@ini_set( 'post_max_size', '256M' );
@ini_set( 'max_execution_time', '300' );
@ini_set('max_input_time', '300' );
@ini_set('max_input_vars', '1000' );
@ini_set('session.gc_maxlifetime', '1000' );

Die Speicher- und Zeitwerte in diesen Parametern sind nur Empfehlungen. Um sicherzustellen, dass sie funktionieren, und um ihre aktuellen Werte zu überprüfen, verwenden Sie das Site Health-Tool in Ihrer WordPress-Admin-Oberfläche.

Zusammen mit dem Wiederherstellungsmodus führte WordPress 5.2 das Site Health-Tool ein. Es ist sehr hilfreich, um Probleme zu diagnostizieren und technische Informationen zu Ihren Site-Einstellungen und Ihrer Serverumgebung zu erhalten. Sie finden es in Ihrem Admin-Menü unter Tools > Site Health. Sie können auch von den erweiterten Funktionen im Health Check and Troubleshooting Plugin für WordPress profitieren.

3. PHP hat keinen Speicher mehr

PHP ist die serverseitige Skriptsprache, auf der der WordPress-Kern basiert. Ein WSOD wird angezeigt, wenn nicht genügend Speicher für PHP vorhanden ist, um WordPress und Ihre aktiven Plugins auszuführen. Möglicherweise wird dies in einer Fehlermeldung oder einem Protokoll angezeigt.

Abhängig von Ihrem Hosting-Plan können Sie möglicherweise das PHP-Speicherlimit für alle Anwendungen auf Ihrem Server oder eine bestimmte Instanz von WordPress erhöhen. Bitten Sie das technische Support-Team Ihres Gastgebers um Hilfe, wenn Sie sich nicht sicher sind, was Sie tun sollen.

wp-config.php

Normalerweise wird durch Hinzufügen der folgenden Einstellung zu deiner wp-config.php Datei in deinem WordPress-Ordner das Front-End-Speicherlimit für WordPress in diesem Beispiel auf 256 MB gesetzt:

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

128 bis 256 MB sollten mehr als ausreichend sein. Möglicherweise können Sie auch den maximalen oder Back-End-Speicher definieren, der PHP zugewiesen wird (256 MB im nächsten Beispiel), indem Sie auch die folgende Zeile zu wp-config.php :

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

Die zweite Zahl ist die maximale Speichergrenze, die den gesamten Speicher definiert, den PHP für sich selbst zur Verfügung hat. Die erste Zahl ist der Speicher für WordPress, der innerhalb dieses größeren PHP-Limits läuft. Das maximale PHP-Speicherlimit sollte gleich oder höher als das WordPress-Anwendungsspeicherlimit sein.

php.ini

Eine andere Möglichkeit, das maximale PHP-Speicherlimit zu definieren, ist eine Einstellung in einer php.ini -Datei, die sich in deinem WordPress-Ordner befindet:

 memory_limit = 256 MB

Achten Sie darauf, dass am Anfang der Zeile kein Semikolon steht! Und beachten Sie, php.ini nur Auswirkungen auf die Instanz von WordPress (oder einer anderen PHP-Anwendung) hat, die in oder unter dem Ordner ausgeführt wird, in dem sich die php.ini -Datei befindet. Wenn Sie Zugriff auf Ihren Server oder Ihr Web-Root haben, wird eine php.ini -Datei, die sich dort befindet, regelt die Umgebungseinstellungen für alle PHP-Anwendungen, es sei denn, sie haben ihre eigene php.ini -Datei, die andere Bedingungen angibt.

.htaccess

Eine dritte Möglichkeit, das PHP-Speicherlimit zu definieren, ist die .htaccess -Datei in Ihrem WordPress-Ordner, wenn Sie Apache oder Litespeed als HTTP-Server verwenden. Wie in den obigen Beispielen muss .htaccess eine unkommentierte Zeile wie diese haben, um ein maximales PHP-Limit von 256 MB festzulegen:

 php_value memory_limit 256M

Fehler in der Syntax von Anwendungs- und Servereinstellungen in wp-config.php , php.ini und .htaccess können ebenfalls einen WSOD verursachen. Möglicherweise müssen Sie sie manuell korrigieren oder durch ihre ursprünglichen Standardwerte ersetzen, wenn sie Ihre Website beschädigen. Wenn Sie einen Apache- oder Litespeed-Webserver verwenden, kann die .htaccess -Datei, die ihre Funktionsweise regelt, von vielen WordPress-Plugins geändert werden. Fehler, die in einer dieser Dateien eingeführt werden, können ein WSOD auslösen und Ihre Website zum Absturz bringen.

4. Ihr HTTP-Server stürzt ab

HTTP (oder seine verschlüsselte, sichere Form HTTPS) ist das Hypertext-Übertragungsprotokoll, das einen Webserver zu einem Webserver macht. Auf diese Weise stellen Server Webseiten (HTTP-Dokumente) Clients (wie Browsern) auf Anfrage bereit.

Häufig verwendete HTTP-Server für WordPress-Sites sind Apache, Litespeed und NGINX. Ihre Fehlerbildschirme sehen etwas anders aus und können sich in der Art und Weise unterscheiden, wie Browser sie anzeigen, aber sie melden alle dieselben HTTP-Fehlercodes.

Ein HTTP 500-Fehler, auch bekannt als interner Serverfehler, weist darauf hin, dass ein unerwartetes Problem mit Ihrem HTTP-Server vorliegt, das ihn daran hindert, HTTP-Anforderungen zu erfüllen. Andere 5xx-Serverfehlercodes, insbesondere 502 (Bad Gateway), 503 (Service Unavailable) und 504 (Gateway Timeout), weisen darauf hin, dass Ihr Server überlastet oder nicht erreichbar ist. Der interne Fehler 500 ist ein Sammelbegriff für Ausfälle auf dem Server, die ihn daran hindern, die angeforderte Seite/das angeforderte Dokument zurückzugeben.

Ihr Browser bietet möglicherweise seine eigene einzigartige Einstellung zu HTTP-Fehlerbildschirmen und zeigt möglicherweise eigene spezielle Fehlercodes an. Google Chrome (und andere Chromium-basierte Browser) listet und erklärt intern alle seine eigenen Fehlercodes, wenn Sie in Ihrer Adressleiste zu chrome://network-errors/ navigieren, während Sie Chrome verwenden.

Serverseitige Probleme

Zu den häufig verwendeten HTTP-Serversoftware für WordPress-Sites gehören Apache, Litespeed und NGINX. Viele WordPress-Hosts verwenden sie mit Caching, um die Leistung zu maximieren.

Wenn eine harte Aktualisierung Ihres Browsers oder das Löschen Ihrer Browser-Cookies und Ihres Caches den 500-Fehlerbildschirm nicht beseitigt, könnten Sie einige fehlerhafte serverseitige Cache-Dateien abholen. Serverseitiges Caching kann viel Verwirrung stiften, wenn es nicht gut funktioniert, also sollten Sie auch versuchen, es zu löschen. Ihr Hosting-Kontrollfeld oder Ihre WordPress-Administrationsoberfläche verfügt möglicherweise über Steuerelemente zum Löschen des Caches.

Häufige Ursachen für einen HTTP 500-Fehler können die folgenden serverseitigen Bedingungen sein:

1. Das PHP-Speicherlimit wurde überschritten.
2. Andere PHP-Fehler, wenn PHP nicht auf die Anzeige von Fehlern eingestellt ist.
3. Unzureichende Berechtigung für den Zugriff auf Serverdateien und -ordner.
4. Syntaxfehler in der .htaccess-Konfigurationsdatei.

Wir haben uns bereits mit PHP-Speichergrenzen und deren Erhöhung befasst. Wir werden uns im nächsten Abschnitt weiter unten mit dem PHP-Debugging befassen.

Falsche Berechtigungen sollten bei modernem, verwaltetem WordPress-Hosting nicht vorkommen, aber sie sind bei traditionellem Shared Hosting üblich. Dateien sollten auf 664 oder 644 gesetzt werden, Ordner sollten auf 775 oder 755 gesetzt werden und wp-config.php sollte auf 660, 600 oder 644 gesetzt werden. Erfahre mehr über das Ändern von Dateiberechtigungen auf WordPress.org.

Wenn Sie Änderungen an Ihrer .htaccess-Datei vorgenommen haben oder ein Plugin verwenden (häufig oder zwischengespeichert), das sie ändert, müssen Sie sie möglicherweise auf Fehler überprüfen, wiederherstellen oder eine neue, funktionierende .htaccess-Datei neu erstellen. Erfahren Sie mehr über .htaccess auf WordPress.org.

Clientseitige Probleme

HTTP 500-Fehler können auch auf der Client-Seite (in Ihrem Browser) durch andere Bedingungen verursacht werden:

5. Falsche Browsereinstellungen.
6. Ein beschädigter Cache.
7. Beschädigte JavaScript-Dateien, die in Ihrem Browser ausgeführt werden.
8. Probleme mit der Internetverbindung.

Versuchen Sie, Ihre Website in einem anderen Browser zu laden, um Ihren aktuellen Browser als Problem zu beseitigen. Wenn Sie ein Browserproblem haben, versuchen Sie, ihn auf die Standardeinstellungen zurückzusetzen. Deaktivieren Sie alle Browsererweiterungen oder Plug-ins, die Sie installiert haben, um zu sehen, ob sie schlecht mit Ihrer Website interagieren.

Wenn Ihr Problem mit fehlerhaften Cache-Dateien zusammenhängt, ist der nicht zwischengespeicherte WordPress-Adminbereich möglicherweise immer noch für Sie zugänglich. Wenn Sie sich immer noch bei der WordPress-Administrationsoberfläche anmelden können, können Sie dort möglicherweise Cache-Löschschalter verwenden oder die unten beschriebenen zusätzlichen Schritte zur Fehlerbehebung ausprobieren.

Es ist auch möglich, dass ein HTTP 500-Fehler durch ein Problem mit der Datenbank, ein Problem mit einem Plugin oder Design auf einer WordPress-Site oder ein Problem mit WordPress selbst verursacht wird.

Um einen HTTP 500-Fehler zu beheben, sollten Sie die Fehlerprotokollierung für Ihren HTTP-Server und PHP aktivieren. Überprüfen Sie dann, welche Fehler in beiden auftreten. Sie können auch das PHP-Speicherlimit überprüfen und möglicherweise erhöhen, Plugins deaktivieren und zu einem Standarddesign wechseln, um zu sehen, ob eine dieser Aktionen Ihre Website wieder zum Laufen bringt.

Auf diese Schritte gehen wir weiter unten genauer ein. Wenn das Befolgen dieser Anweisungen den 500-Fehler nicht beseitigt, wenden Sie sich für weitere Unterstützung an das Support-Team Ihres Webhosts.

Wenn WordPress wirklich tot ist

Wenn Sie auf jeder Front- und Backend-Seite Ihrer WordPress-Site einen vollständig weißen Bildschirm ohne überhaupt sichtbares Fehler-Feedback erhalten, ist das die volle WSOD-Erfahrung. Sie können einige Fehlermeldungen und Diagnoseinformationen erhalten, wenn Sie wissen, wie Sie auf Ihre PHP-Fehlerprotokolle und HTTP-Serverprotokolle zugreifen. Das Aktivieren des PHP-Debuggings für WordPress ist eine weitere Option. Ihr Host verfügt möglicherweise über einige Tools, um das Debuggen für Sie zugänglicher zu machen. Aber wenn das nicht der Fall ist, können Sie einfach diese Liste von Heilmitteln für das allgemeine WSOD durchgehen, bis Sie Ihre Lösung gefunden haben.

Eine Master-Checkliste zur Fehlerbehebung und Behebung des White Screen of Death von WordPress

Um den WordPress White Screen of Death zu reparieren, führen Sie die folgenden Schritte zu einer Lösung. Sie sind in der Reihenfolge der häufigsten WSOD-Ursachen organisiert, wie ich sie erlebt habe, aber Sie können sie in beliebiger Reihenfolge ausprobieren.

Es ist am sinnvollsten, die Lösungen zu priorisieren, die für Ihre spezielle Situation am relevantesten erscheinen.

Der Fehlerprotokollierungs- und Debugging-Schritt (Nr. 2) ist der technischste, aber er ist gründlich und wird Ihnen immer sagen, was zum Abbruch von WordPress führt.

Ich habe Links zu einigen kostenlosen Plugins bereitgestellt, die nützliche Diagnose- und Reparaturwerkzeuge sein können. Möglicherweise finden Sie iThemes Security auch besonders hilfreich für die Datenbank-Scan- und Reparaturfunktion sowie die Erkennung von Dateiänderungen. Es verfügt sogar über Server-Tools für einen tieferen Einblick in Ihre Servereinstellungen und -funktionen.

Letztendlich bringt ein gutes, aktuelles Backup Ihre Website in ihrem letzten bekannten guten Zustand wieder online. Backup Buddy ist das beste Plugin für diese Rolle.

Löschen Sie Ihren Browser-Cache und Cookies

Zwischengespeicherte Seiten Ihrer Website in Ihrem Browser und auf Ihrem Server können Ihnen etwas anderes zeigen als das, was tatsächlich passiert. Stellen wir sicher, dass Sie sehen, was WordPress brandneuen Besuchern Ihrer Website anzeigt.

Löschen Sie zunächst den Cache und die Cookies Ihres Browsers. Dadurch wird Ihre Benutzersitzung beendet, wenn Sie bei WordPress oder einer anderen Website angemeldet sind, sodass Sie sie wie jeder andere Besucher betrachten.

Verwenden Sie als Nächstes Ihr Hosting-Panel und den WordPress-Administrator (falls verfügbar), um alle serverseitigen Zwischenspeicherungen zu löschen, die Ihr Host und die WordPress-Cache-Plugins erstellen. Versuchen Sie, das gesamte Site- und Server-Caching zu deaktivieren. Führen Sie in Ihrem Browser eine harte Aktualisierung durch. Wenn das Problem dadurch behoben wird, liegt das Problem möglicherweise darin, dass Sie Cache-Einstellungen aktiviert haben, die auf Ihrem System nicht funktionieren. Durch einen Ausschlussprozess können Sie feststellen, welche funktionieren und welche nicht.

2. Suchen Sie nach PHP-Fehlern

PHP-Code im WordPress-Kern, -Themen oder -Plugins kann einen schwerwiegenden Fehler erzeugen, der WordPress dazu bringt, mit einem White Screen of Death den Geist aufzugeben.

Um weitere Informationen zu schwerwiegenden PHP-Fehlern und deren Ursache zu erhalten, können Sie die PHP-Fehlerberichterstattung aktivieren und sie an den Bildschirm, eine Protokolldatei oder beides senden. Schwerwiegende Fehler weisen wahrscheinlich auf die Quelle des WSOD hin.

Als PHP-basierte Webanwendung verfügt WordPress über ein eigenes Diagnoseberichtssystem zum Debuggen, mit dem Sie die Fehlerprotokollierungsfunktionen von PHP nutzen können. Um es einzuschalten und zu steuern, stelle sicher, dass es eine Zeile in wp-config.php , die besagt:

 define('WP_DEBUG', true);

Möglicherweise müssen Sie es hinzufügen oder den Wert von "false" in "true" ändern. Dies weist WordPress an, das PHP-Debugging zu aktivieren.

Sie können auch eine Abkürzung nehmen, indem Sie das WP-Debugging-Plugin installieren und aktivieren. Es aktiviert das PHP-Debugging für WordPress, ohne dass Sie wp-config.php direkt selbst ändern müssen.

Die unten gezeigten zusätzlichen wp-config.php Parameter drucken standardmäßig die Debugging-Ausgabe als HTML und eine Datei mit dem Namen „error_log“ auf den Bildschirm:

 define( 'WP_DEBUG_DISPLAY', true );
define( 'WP_DEBUG_LOG', true );

Es kann auch hilfreich sein, WordPress zu zwingen, die nicht optimierten Versionen seiner CSS- und JavaScript-Abhängigkeiten zu verwenden, falls sie ein Problem verursachen:

 define( 'SCRIPT_DEBUG', true );

Das Plugin Debug Bar ist ein nützliches zusätzliches und ergänzendes Tool. Es zeigt Ihnen Debugging-Daten in einer netten Oberfläche.

Dazu muss in der php.ini eine Zeile vorhanden sein, die der Konstante error_reporting einen anderen Wert als NONE gibt, wie error_reporting = E_ALL . Diese Zeile darf nicht mit einem Semikolon überschrieben sein; das macht es eher zu einem Kommentar als zu einer aktiven Einstellung. Beachten Sie, dass Sie jeden PHP-Fehler, jede Warnung und jeden Hinweis erhalten, wenn Sie E_ALL verwenden. Verwenden Sie einen anderen Wert wie E_ERROR , um nur schwerwiegende Laufzeitfehler zu protokollieren, die zum Absturz von WordPress führen.

3. Suchen Sie nach Design- und Plugin-Konflikten

Das Debuggen von PHP-Fehlern, wie im vorherigen Schritt beschrieben, sollte Sie auf eine eindeutige Design- oder Plugin-Datei als Quelle Ihres WSOD hinweisen. Sie können sich dem auch mit einem weniger technischen Eliminierungsprozess nähern.

Themen zur Fehlerbehebung

Der White Screen of Death wird oft durch Konflikte zwischen WordPress-Themes und/oder Plugins verursacht. Um die Konfliktquelle(n) zu identifizieren, können Sie versuchen, alle Ihre Plugins zu deaktivieren und zu den aktuellen, unveränderten Standard-Designpaketen mit WordPress-Kern wie Twenty Twenty-Three zu wechseln.

Beginnen Sie mit dem Thema – es ist am einfachsten zu testen. Wenn das Wechseln Ihres aktiven Designs zu einem bekanntermaßen funktionierenden, unveränderten Standarddesign Ihre Website wieder online bringt, wissen Sie, dass Ihr Problem in dem von Ihnen verwendeten Design liegt.

Werfen Sie einen Blick auf die Datei functions.php Ihres Themes, falls vorhanden. Wenn Sie es kürzlich geändert haben, ist dies eine wahrscheinliche Quelle Ihres Leidens. In der Datei functions.php wird benutzerdefinierter Funktionscode zur Verwendung mit einem Thema hinzugefügt, wenn es aktiviert ist. Schlechter Code und Syntaxfehler geben Ihnen hier einen WSOD.

Fehlerbehebung bei Plugins

Sie können Plugins ohne Zugriff auf den WordPress-Admin über die Befehlszeile/SSH oder SFTP deaktivieren, indem Sie einfach die Plugin-Ordner vorübergehend aus dem Ordner /wp-content/plugins/ verschieben. Meine Praxis besteht darin, einen Plugin-Unterordner mit dem Namen „A“ zu erstellen, sodass er zuerst im alphabetisch sortierten /plugins Verzeichnis erscheint. Dann verschiebe ich alle anderen Plugin-Ordner in „A“.

Sobald Sie dies getan haben, laden Sie Ihre Website neu. WordPress verhält sich so, als wären alle Plugins verschwunden. Sie sind noch installiert, aber deaktiviert. Wenn der White Screen of Death verschwindet, können Sie versuchen, Ihre Plugins und Ihr Design nacheinander zu reaktivieren und Ihre Homepage jedes Mal zu aktualisieren, um zu sehen, welches zum Absturz Ihrer Website führt.

Meks Quick Plugin Disabler ist ein praktisches Tool, das schnell alle aktiven Plugins deaktiviert und sie dann auf Ihren Befehl aus dem WordPress-Admin heraus wieder aktiviert.

4. Reparieren Sie beschädigte Core-Dateien

Ihr WSOD kann die Folge beschädigter WordPress-Kerndateien sein. Obwohl dies unwahrscheinlich ist, ist es einfach, die neueste Version von WordPress mit einem Klick im Bereich WordPress Dashboard Updates schnell neu zu installieren. Dies schadet keinem Ihrer Plugins, Designs oder vorhandenen Inhalte, daher ist es eine gute und einfache Möglichkeit, zu bestätigen, dass Ihre Kerndateien in Ordnung sind.

Wenn keiner der oben genannten Schritte hilft, wird der WSOD möglicherweise durch ein Problem mit Ihrer Serverumgebung verursacht, das außerhalb Ihrer Reichweite liegt. In diesem Fall müssen Sie sich möglicherweise an Ihren Hosting-Provider wenden, um Unterstützung zu erhalten. Als letzten Ausweg können Sie Ihre Website auch auf einen „zuletzt bekannten guten“ Zustand zurücksetzen, indem Sie ein Backup wiederherstellen.

So verhindern Sie einen WSOD – Ratschläge für Eigentümer und Ersteller von WordPress-Sites

WordPress funktionierte einwandfrei – und dann kam plötzlich der White Screen of Death!

Dies liegt wahrscheinlich daran, dass SIE etwas Entscheidendes an der Funktionsweise von WordPress geändert haben.

Wenn Sie ein solides verwaltetes WordPress-Hosting-Konto mit Liquid Web oder Nexcess verwenden, das ordnungsgemäß mit ausreichenden Ressourcen für die Dinge konfiguriert ist, die Sie damit tun, können 99 % der Möglichkeiten, WordPress mit einem WSOD zu beschädigen, vermieden werden.

Das Problem ist, dass Websitebesitzer diese Praktiken nicht vermeiden!

Was nicht zu tun ist

1. Cowboy-Codierung. Hinzufügen oder Bearbeiten von Funktionscode auf einer Live-Site über SFTP, die Befehlszeile oder Code-Editoren und Skript-Inserter im WordPress-Adminbereich. Ein kleiner Fehler wird die Website zum Absturz bringen. Das Ändern von Konfigurationsdateien wie .htaccess und wp-config.php kann eine Website ebenfalls zum Absturz bringen. Arbeiten Sie stattdessen an einer lokalen Test- oder Live-Staging-Site (aber nicht öffentlich).
2. Dubiose Themes, Plugins und Erweiterungen installieren. Die Installation von minderwertiger oder sogar genullter Software auf einer Live-Site ist eine Einladung für Ärger. Einfach zu viele Dinge auf einmal hinzuzufügen, kann es schwierig machen zu bestimmen, was letztendlich eine Breaking Change ist. Ähnlich wie bei der Cowboy-Codierung ist die Installation neuer Code-Produkte auf einer Live-Site riskant. Testen Sie zuerst gut auf einer privaten lokalen oder Staging-Site.
3. Kompliziertes Caching. Es gibt verschiedene Arten von serverseitigem Caching, die Ihr Host möglicherweise anbietet und die möglicherweise nicht mit allen Caching- und Leistungsoptimierungs-Plugins gut funktionieren. Wenn Sie neue Caching-Methoden oder -Einstellungen implementieren, testen Sie sie sorgfältig in lokalen und Staging-Umgebungen, bevor Sie Änderungen an einer Live-Site implementieren.
4. Alles auf einmal aktualisieren. Sie können viele Designs und Plugins auf einmal stapelweise aktualisieren. Normalerweise funktioniert das, aber wenn bei Ihrem Server eine Zeitüberschreitung auftritt, bleiben Sie möglicherweise im Wartungsmodus hängen. Außerdem kann neu aktualisierter Code neue Fehler, Konflikte oder Kompatibilitätsprobleme einführen. Wenn dies passiert und Ihre Website ausfällt, ist es schwieriger, die Ursache des Problems zu identifizieren. Es könnte eine beliebige Anzahl von Elementen sein, wenn Sie mehrere Designs, Plugins und Erweiterungen gleichzeitig aktualisiert haben. Aktualisierter Code kann lokal und auf Live-Staging-Sites getestet werden, bevor er auf Ihrer öffentlichen Hauptsite bereitgestellt wird.

Tipps für ein Leben ohne WSOD

Der WSOD kann jeder WordPress-Site passieren, sollte aber kein Grund zur Beunruhigung sein. Wenn Sie die Tipps in diesem Leitfaden befolgen, können Sie das Problem identifizieren und schnell beheben, bevor Ihre Website-Besucher es überhaupt bemerken.

Probleme mit einer WordPress-Seite unterstreichen die Bedeutung der richtigen Wartung und Pflege. Besser als auf WSODs zu reagieren, können Sie lernen, auf WordPress so zu arbeiten, dass Ihre Besucher niemals Fehlermeldungen und leeren Bildschirmen ausgesetzt werden.

Nehmen Sie Ihre Änderungen sorgfältig und bewusst vor. Behandeln Sie Ihre potenziellen WSODs in einer lokalen Test- oder Staging-Umgebung. Dies sind Standardtools und -funktionen für die meisten verwalteten WordPress-Hosts von heute. Wenn Sie diese grundlegenden Best Practices befolgen, müssen Sie sich keine Sorgen um den WordPress White Screen of Death machen.

Das beste WordPress-Sicherheits-Plugin zum Sichern und Schützen von WordPress

WordPress betreibt derzeit über 40 % aller Websites, sodass es zu einem leichten Ziel für Hacker mit böswilligen Absichten geworden ist. Das iThemes Security Pro-Plug-in beseitigt das Rätselraten bei der WordPress-Sicherheit, um es einfach zu machen, Ihre WordPress-Website zu sichern und zu schützen. Es ist, als hätten Sie einen Vollzeit-Sicherheitsexperten im Team, der Ihre WordPress-Site ständig für Sie überwacht und schützt.

Holen Sie sich iThemes Security Pro

Dan Knauss

Dan Knauss ist StellarWPs Technical Content Generalist. Er ist Autor, Lehrer und Freiberufler, der seit Ende der 1990er Jahre mit Open Source und seit 2004 mit WordPress arbeitet.