Weißer WordPress-Bildschirm: 5 einfache Lösungen

von | WordPress

Wenn Ihre Website WordPress plötzlich erscheint eine völlig leere Seite. ohne Die Botschaft lautet: Sie sind nicht „verflucht“, sondern stehen lediglich vor einem schwerwiegenden Fehler, den WordPress nicht korrekt anzeigen kann.

das Problem

Der „WSOD“ (White Screen of Death) äußert sich durch das vollständige Fehlen von Inhalten. Manchmal erhält man eine serverseitige Fehlermeldung, beispielsweise einen 500-Fehler oder eine minimale Meldung wie:

HTTP ERROR 500

Oder, falls der Hosting-Anbieter PHP-Fehler anzeigt (selten im Produktivbetrieb), etwa so:

Fatal error: Uncaught Error: Call to undefined function ... in /home/.../wp-content/themes/.../functions.php:123

Wo und wann erscheint es?

  • Front-End : leere Homepage oder nur bestimmte Seiten (oft eine Seite mit einem Shortcode, einem Widget, einer bestimmten Vorlage).
  • Admin (/wp-admin) : weißer Bildschirm beim Anmelden, nicht zugängliches Dashboard oder weißer Bildschirm auf einer bestimmten Seite (Erweiterungen, Darstellung, Editor…).
  • Cron / geplante Aufgaben Die Website funktioniert zwar, aber einige Aktionen (E-Mails, Importe) werden nicht ausgeführt, und in den Protokollen finden sich Fehler.
  • REST-API / AJAX Elementor/Divi/Avada kann den Editor nicht mehr laden, XHR-Anfragen schlagen fehl oder die Vorschau wird nicht geladen.

Typische Umstände, die ich am häufigsten sehe:

  • Direkt nach einem mise à jour (WordPress 6.9.4, a Plugin(ein Thema, ein Erbauer).
  • Nach dem Hinzufügen eines Schnipsel in functions.php oder über ein Snippets-Plugin.
  • Nach der Aktivierung eines "schweres" Plugin (Cache, Sicherheit, Builder, E-Commerce).
  • Nach einer Änderung auf Serverseite (PHP-Version, OPcache-Modul, Speichergrenzen).

Für wen ist das geeignet? Wenn Sie Anfänger sind, aber Zugriff auf Ihren FTP-/Dateimanager (oder zumindest das Admin-Panel) haben, können Sie die Website richtig diagnostizieren und wieder online bringen. Am Ende wissen Sie, was zu tun ist. Ermitteln Sie den genauen Fehler, den Täter isolieren (Plugin/Theme/Snippet) und Vermeiden Sie durch den Cache verursachte falsche weiße Bildschirme..

Kurze Zusammenfassung

  • Rate nicht : Aktivieren Sie das Debugging und lesen Sie den Fehler (Lösung 1).
  • Isolieren : Deaktivieren Sie alle Plugins und wechseln Sie zurück zum Standard-Theme (Lösung 2).
  • Speicher prüfen Viele WSODs haben ihren Ursprung in einem Der zulässige Speicherplatz ist erschöpft. (Lösung 3).
  • Snippets : ein fehlendes Semikolon in functions.php genug, um alles zu bleichen (Lösung 4).
  • Cache Sie können die Website „reparieren“, ohne es zu sehen, wenn OPcache/CDN die alte Version ausliefert (Lösung 5).

Symptome

Ein WSOD ist nicht immer „nur eine leere Seite“. Hier sind die konkreten Anzeichen, auf die Sie achten sollten (und was sie bedeuten).

  • Leere Seite (Vorderseite) aber / Wp-admin Fehler: Oft liegt das Problem im Theme, einer Vorlage, einem Shortcode oder einem beschädigten Seitencache.
  • / Wp-admin Auch bei Weiß: Häufiger ein schwerwiegender PHP-Fehler (Plugin, Theme, Code-Snippet) oder eine Speicherbegrenzung.
  • Fehler 500 im Browser: häufig ein schwerwiegender PHP-Fehler, eine Serverkonfiguration oder ein Modul (OPcache), das veralteten Code ausliefert.
  • Der Elementor-/Divi-/Avada-Editor lädt nicht mehr REST-API-/AJAX-Fehler, Speicherprobleme, Plugin-Konflikte (Sicherheit/Caching) oder versteckte JS-Fehler.
  • Die Website funktioniert lokal. jedoch nicht im Produktivbetrieb: Unterschiede in der PHP-Version, PHP-Erweiterungen, Speichergrenzen, Server-Cache und Dateiberechtigungen.
  • Nur bestimmte Seiten Fehlerhafter Shortcode, zu große Anfrage, Endlosschleife oder Bild/Ressource, die den Speicher erschöpft.

Schnelle Diagnose im Browser: Öffnen Sie die Konsole (F12) und schauen Sie nach:

  • Console : JavaScript-Fehler (besonders nützlich für Entwickler).
  • Netzwerk XHR-Abfragen an /wp-json/ (REST-API) oder admin-ajax.php 500/403.

Warum passiert das

Einfache Erklärung (für Anfänger)

WordPress führt PHP-Code (Themes und Plugins) aus. Tritt ein schwerwiegender PHP-Fehler auf, wird die Ausführung sofort abgebrochen. Je nach Serverkonfiguration kann der Fehler (aus Sicherheitsgründen) ausgeblendet werden, und Sie sehen möglicherweise nur einen weißen Bildschirm.

Das WSOD ist daher selten „mystisch“. Es ist fast immer:

  • un Codefehler (Plugin/Theme/Snippet),
  • un Ressourcenmangel (Gedächtnis/Zeit),
  • oder Cache-Speicher Dadurch wird Ihnen eine fehlerhafte Version angezeigt, obwohl Sie sie repariert haben.

Technische Erklärung (Mittelstufe/Profi)

Im Hintergrund tritt der Fehler häufig beim Laden von WordPress-Hooks auf. Haken ist ein Erweiterungspunkt: ein Aktion führt Code zu einem bestimmten Zeitpunkt aus, ein Filter verändert einen Wert (z. B. den Inhalt), bevor er verwendet wird.

Die Ursachen (von der häufigsten zur seltensten) sowie meine Beobachtungen bei der Fehlersuche in WordPress 6.9.4:

  • Das Plugin ist nicht kompatibel mit PHP 8.1+ (oder ein Fehler nach dem Update).
  • Thema / Kinderthema : Code in functions.phpVorlage oder Überschreiben WooCommerce.
  • Ausschnitt aus einem alten Tutorial kopiert (veraltete Funktion, falscher Hook oder Code, der zu früh ausgeführt wird).
  • Unzureichender PHP-Speicher (Builder + WooCommerce + Sicherheits-Plugins = klassische Kombination).
  • Server-Cache (OPcache) / CDN die eine veraltete Version verwendet.
  • Berechtigungen (Ein echter WSOD tritt seltener auf, kann aber zu 500-Fehlern führen).

Um Ihnen die Sache zu erleichtern, finden Sie hier eine Diagnosetabelle: „Symptom → Untersuchung → Lösung“.

Symptom Mögliche Ursache Überprüfung Lösung
Überall weißer Bildschirm PHP-Fehler WP_DEBUG aktivieren + lesen debug.log Lösung 1 + 2
Fehler 500 Schwerwiegender PHP-Fehler / Speicherlimit / Server-Cache Serverprotokolle + debug.log Lösung 1 + 3 + 5
Admin OK, weiße Vorderseite Theme / Shortcode / Seitencache Design vorübergehend ändern + Cache leeren Lösung 2 + 5
Elementor/Divi öffnet den Editor nicht mehr REST/AJAX-Fehler, Speicherproblem Konsole + Netzwerk (XHR 500/403) Lösung 3 + „Wenn das immer noch nicht funktioniert“
WSOD nach dem Hinzufügen eines Code-Snippets Syntaxfehler / Hook zu früh Letzte geänderte Datei, Protokolle Lösung 4

Voraussetzungen vor Beginn

Speichern Sie die Einstellungen, bevor Sie Änderungen vornehmen. Falls Sie mit Dateien arbeiten müssen, erstellen Sie mindestens eine Kopie von:

  • wp-config.php
  • den Ordner wp-content (oder zumindest themes et plugins)

Empfohlene technische Voraussetzungen (WordPress 6.9.4, Stand April 2026):

  • PHP 8.1 + (Mindestempfehlung). Liegen Sie darunter, erhöht sich das Risiko von Fehlern und Sicherheitslücken erheblich.
  • Zugriff auf FTP / SFTP oder an den Dateimanager des Hosting-Anbieters.
  • Im Idealfall ein Aufführung (Testseite). Viele Hosting-Anbieter bieten dies mit einem Klick an.

Nützliche (kostenlose) Tools:

Goldene Regel : Den Kern niemals verändern. (die WordPress-Dateien in wp-includes / wp-adminDie Korrektur erfolgt in einem Plugin, einem Child-Theme oder der Konfiguration.

Lösung 1: Aktivieren Sie das Debugging ordnungsgemäß (und finden Sie den genauen Fehler).

Ein leerer Bildschirm ohne sichtbare Fehler zwingt zum Raten. Ziel ist es, eine brauchbare Fehlermeldung in einer Protokolldatei zu erhalten.

Wo man eingreifen sollte: In der Datei wp-config.php, im Stammverzeichnis von WordPress (auf der gleichen Ebene wie wp-content).

Vor dem Ändern speichern. Ein Tippfehler in wp-config.php kann dazu führen, dass die Website nicht erreichbar ist.

VORHER (typische Konfiguration, die alles ausblendet)

Viele Websites enthalten gar nichts oder nur unvollständiges Debugging:

<?php
// ... contenu existant ...

/* C'est tout : aucune trace d'erreur exploitable. */

NACHHER (Debugging-orientierte Fehlerbehebung, ohne Anzeige für Besucher)

Fügen Sie diese Konstanten hinzu (oder passen Sie sie an). Platzieren Sie sie avant la ligne /* That's all, stop editing! */ falls es in Ihrer Datei existiert.

<?php
// ... contenu existant ...

/**
 * Debug WordPress (WordPress 6.9.4+ / PHP 8.1+)
 * Objectif : écrire les erreurs dans wp-content/debug.log sans les afficher aux visiteurs.
 */
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

// Évite d'afficher des erreurs PHP directement dans le HTML.
@ini_set( 'display_errors', '0' );

dann:

  1. Laden Sie die leere Seite (Frontend oder Admin) neu.
  2. geöffnet wp-content/debug.log und suche nach dem letzten Fehler.

Beispiele für Fehler, die auftreten können:

PHP Fatal error:  Uncaught Error: Call to undefined function my_plugin_helper() in /wp-content/plugins/mon-plugin/mon-plugin.php:88
PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in /wp-includes/class-wpdb.php on line ...

Warum dies das Problem behebt: Manchmal wird der „WSOD“ durch diesen Schritt nicht behoben, aber Sie können ihn wiederherstellen. Informationen Das ermöglicht eine schnelle Korrektur (bestimmtes Plugin, bestimmte Datei, bestimmte Zeile). Ohne diese Funktion verschwenden Sie Zeit.

Wenn Sie fertig sind: Geben Sie es ab. WP_DEBUG à false auf einer Produktionsumgebung. Wenn die Protokolldatei unzureichend geschützt ist, können Serverpfade und sensible Informationen offengelegt werden, wenn das Protokoll aktiv bleibt.

Offizielle Quelle: WordPress debuggen

Lösung 2: Einen Plugin-/Theme-Konflikt isolieren (Anfängermethode + Methode „ohne Administratorzugriff“)

Meiner Erfahrung nach wird ein White Screen (WSOD) häufig durch ein aktualisiertes Plugin (oder einen Builder) verursacht, das einen schwerwiegenden Fehler auslöst. Die Lösung: auf eine minimale Konfiguration zurücksetzen und die Plugins anschließend einzeln wieder aktivieren.

Methode A (Anfänger): über das Admin-Panel, falls Sie Zugriff darauf haben

  1. gehen Erweiterungen> Installierte Erweiterungen.
  2. Alles auswählen, dann deaktivieren.
  3. Testen Sie die Website.
  4. Reaktivieren eine Erweiterung nach der anderen bis der WSOD reproduziert wird.

Wechseln Sie als Nächstes vorübergehend zu einem Standarddesign:

  • Erscheinungsbild > Designs > ein offizielles Design aktivieren (oft ein Twenty*).
  • Versuchen Sie es erneut.

Wenn Sie Divi 5, Elementor oder Avada verwenden: Diese Themes/Builder fügen viel Code hinzu. Konflikte mit Caching-/Sicherheits-Plugins sind häufig. Der Test „Standard-Theme + deaktivierte Plugins“ ist der schnellste Weg, diesen Teufelskreis zu durchbrechen.

Methode B (ohne Administratorzugriff): via FTP/SFTP

Si /wp-admin ist weiß, verwenden Sie FTP/SFTP.

Schritt 1: Alle Plugins gleichzeitig deaktivieren

Wo man eingreifen sollte: Ordner umbenennen wp-content/plugins en plugins.offWordPress wird die Plugins als nicht vorhanden betrachten und sie deaktivieren.

# Exemple (le nom exact dépend de votre outil FTP)
wp-content/plugins  →  wp-content/plugins.off

Testen Sie die Website. Wenn das Problem weiterhin besteht, haben Sie bestätigt, dass das/die Plugin(s) die Ursache ist/sind. Installieren Sie es/sie anschließend neu.

wp-content/plugins.off  →  wp-content/plugins

Dann im Inneren pluginsBenennen Sie die Ordner nacheinander um (z. B. elementor → elementor.off) den Täter zu finden.

Schritt 2: Erzwingen eines Ausweichdesigns, falls das Design abstürzt

Wenn die Seite auch bei deaktivierten Plugins noch weiß ist, liegt das Problem wahrscheinlich am Theme (oder Child-Theme).

Option einfach : Benennen Sie den Ordner des aktiven Themes (oder Child-Themes) um. WordPress wechselt dann zu einem anderen verfügbaren Theme.

wp-content/themes/mon-theme-enfant  →  wp-content/themes/mon-theme-enfant.off

Warum dies das Problem behebt: Sie verhindern das Laden des absturzverursachenden Codes. Ein schwerwiegender Fehler in einem Plugin/Theme verhindert, dass WordPress fortfährt.

Falls Sie eine offizielle Fehlerbehebungsanleitung wünschen: Häufig gestellte Fragen zur Fehlerbehebung (WordPress.org)

Lösung 3: Behebung eines Absturzes aufgrund von Speichermangel (PHP/WordPress)

Unzureichender Speicherplatz ist ein häufiges Problem auf Websites, die Elementor/Divi/Avada in Kombination mit WooCommerce und Sicherheits-/Caching-Plugins verwenden. Manchmal äußert sich dies in einem weißen Bildschirm (WSOD), manchmal in einem 500-Fehler oder darin, dass der Editor nicht geladen wird.

Die typische Nachricht in debug.log :

PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate ...)

Schritt 1: Erhöhen Sie den Arbeitsspeicher auf der WordPress-Seite (schnell).

Wo man eingreifen sollte: in wp-config.php, bevor „Bearbeitung beenden“.

VORHER (keine explizite Begrenzung)

<?php
// ...

NACHHER (fordert von WordPress die Nutzung von mehr Speicher auf)

<?php
// ...

/**
 * Augmente la mémoire pour WordPress.
 * Attention : si PHP a une limite plus basse, cela ne suffira pas.
 */
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' ); // Utile pour l'admin et certaines tâches lourdes.

Warum es funktioniert: WP_MEMORY_LIMIT WordPress wird der Zielspeicher zugewiesen. Wenn Ihr Server jedoch ein niedrigeres Limit festlegt, kann WordPress dieses nicht überschreiten.

Schritt 2: Erhöhen Sie die Speicherzuweisung auf der PHP-Seite (oft unerlässlich).

Je nach Hosting-Anbieter erfolgt dies über:

  • das Unterbringungsgremium (empfohlen),
  • eine Datei php.ini ou .user.ini,
  • oder die PHP-FPM-Konfiguration (falls Sie den Server administrieren).

Beispiel (Datei) .user.ini (bei vielen Shared-Hosting-Diensten):

memory_limit = 512M
max_execution_time = 120

Offizielle PHP-Referenz (memory_limit): php.net memory_limit

Was ich nach der Speichererweiterung teste

  • Leere Seite wird geladen.
  • Den Editor öffnen (Elementor/Divi/Avada).
  • Bei WooCommerce: In den Warenkorb legen, zur Kasse gehen und eine Produktseite aufrufen.

Wenn die Website wieder erreichbar ist, aber weiterhin langsam bleibt, könnte eine Ihrer Abfragen zu groß sein (Query Monitor ist dabei sehr hilfreich).

Lösung 4: Einen defekten Code-Schnipsel (functions.php / Snippet-Plugin) reparieren, ohne alles zu zerstören

Das frustrierendste Szenario: Man fügt zehn Codezeilen hinzu, „um WordPress zu verbessern“, speichert … und alles ist leer. Ich habe das schon oft auf Webseiten gesehen, wo der Code in die falsche Datei eingefügt wurde oder eine Klammer fehlt.

Bedingungen:

  • Schnipsel : ein kleines Codefragment, das dem Theme hinzugefügt wird (oft functions.phpoder über ein Plugin.
  • Syntaxfehler PHP kann die Datei nicht lesen (fehlendes Semikolon, zusätzliche geschweifte Klammer...). Das ist ein schwerwiegender Fehler.

Fall A: Der Code wurde in functions.php (Child-Theme) hinzugefügt.

Wo man eingreifen sollte: wp-content/themes/VOTRE-THEME-ENFANT/functions.php

Ein sehr häufiger Fehler: das Vergessen eines Semikolons oder das Schließen einer geschweiften Klammer.

VORHER (fehlerhaft: Semikolon fehlt)

<?php
add_action( 'wp_enqueue_scripts', 'mon_site_styles' );

function mon_site_styles() {
	// Charge une feuille de style
	wp_enqueue_style( 'mon-style', get_stylesheet_directory_uri() . '/style.css' )
}

NACH (korrigiert)

<?php
add_action( 'wp_enqueue_scripts', 'mon_site_styles' );

function mon_site_styles() {
	// Charge une feuille de style
	wp_enqueue_style( 'mon-style', get_stylesheet_directory_uri() . '/style.css' );
}

Warum dies das Problem behebt: PHP benötigt ein Semikolon am Ende der Anweisung. Ohne dieses wird ein Syntaxfehler ausgelöst und WordPress kann nicht mehr geladen werden.

Fall B: Der Code verwendet einen Hook zu früh (Funktion "noch nicht geladen")

Ein weiterer Fall, auf den ich stoße: In einem alten Tutorial wird eine Funktion aufgerufen, die zum Zeitpunkt der Codeausführung noch nicht existiert.

VORHER (fehlerhaft: sofortige Ausführung zu früh)

<?php
// Mauvaise idée : ce code s'exécute dès le chargement du fichier.
ma_fonction_qui_depend_de_wordpress();

function ma_fonction_qui_depend_de_wordpress() {
	// Exemple : vous faites des appels à des APIs WordPress non disponibles à cet instant
	update_option( 'test', 'ok' );
}

NACHHER (korrigiert: Ausführung durch eine Aktion)

<?php
/**
 * On utilise une action pour attendre que WordPress soit chargé.
 * Une "action" est un hook qui déclenche votre code à un moment précis.
 */
add_action( 'init', 'ma_fonction_qui_depend_de_wordpress' );

function ma_fonction_qui_depend_de_wordpress() {
	update_option( 'test', 'ok' );
}

Warum es korrigiert: init Es wird ausgeführt, nachdem WordPress geladen wurde. Dadurch werden vorzeitige Aufrufe verhindert.

Fall C: Code-Snippet über ein Plugin (WPCode, Code Snippets usw.)

Wenn Sie ein Snippet-Plugin verwenden, besteht der Vorteil darin, dass es fehlerhafte Snippets manchmal automatisch deaktivieren kann. Sollte das Admin-Panel jedoch nicht erreichbar sein, deaktivieren Sie das Snippet-Plugin per FTP (Lösung 2) und beheben Sie anschließend das Problem mit dem Snippet.

Referenz (Hooks): developer.wordpress.org/plugins/hooks

Lösung 5: Beseitigen Sie einen durch den Cache (Seitencache, CDN, OPcache) verursachten falschen WSOD.

Hier tappen viele Anfänger in die Falle: Man behebt den Fehler, sieht aber trotzdem noch den weißen Bildschirm. In Wirklichkeit liefert ein Cache eine fehlerhafte Version aus.

Ich sehe das oft auf:

  • Websites hinter Cloudflare (oder einem anderen CDN),
  • Hosting-Anbieter mit aggressivem Server-Caching
  • Websites, bei denen OPcache aktiviert und nach der Bereitstellung fälschlicherweise deaktiviert wurde.

Schritt 1: Löschen Sie die „sichtbaren“ Caches

  • Leeren Sie Ihren Plugin-Cache (LiteSpeed ​​Cache, WP Rocket, W3TC…).
  • Leeren Sie den CDN-Cache (Cloudflare: „Alles löschen“ oder gezieltes Löschen).
  • Test im privaten Browsermodus + durch Hinzufügen eines Parameters: ?nocache=1

Schritt 2: OPcache (serverseitig)

Wenn Sie Serverzugriff haben, ist die effektivste Lösung, PHP-FPM neu zu starten (abhängig von Ihrem System). Beispiel (Linux):

sudo systemctl reload php8.2-fpm

Wenn Sie Shared Hosting nutzen, steht Ihnen dieser Befehl nicht zur Verfügung. In diesem Fall:

  • Suchen Sie im Bedienfeld nach der Option „OPcache leeren“.
  • oder bitten Sie den Support, den OPcache zu leeren (dies ist oft eine Standardanfrage).

Warum das das Problem behebt: OPcache kann eine ältere Version einer PHP-Datei im Speicher ablegen. Sie korrigieren die Datei … aber PHP führt weiterhin die alte Version aus.

Offizielle OPcache-Referenz: php.net OPcache

Nachkorrekturprüfungen

Sobald die Website wieder erreichbar ist, führe ich immer die gleichen „einfachen, aber effektiven“ Tests durch:

  1. Vorderreifen Startseite + 2-3 Unterseiten + Suche.
  2. Administrator : Dashboard, Erweiterungen, Darstellung, Editor (falls verwendet).
  3. Builders :
    • Elementor: Editor öffnen + Änderung speichern.
    • Divi 5: Öffnen Sie den Visual Builder und überprüfen Sie die responsive Vorschau.
    • Avada: Fusion Builder öffnen + Containerbearbeitung überprüfen.
  4. Forms : Formular einreichen (Kontakt-/Newsletter-Formular).
  5. REST API Schnelltest durch Besuch /wp-json/ (Sie sollten JSON sehen, nicht eine leere Seite).

dann:

  • Korrekturlesen wp-content/debug.log Wenn die Seite weiter wächst, gibt es immer noch Fehler (selbst wenn die Seite „funktioniert“).
  • Deaktivieren Sie das Debugging, falls Sie es in der Produktionsumgebung aktiviert haben (Lösung 1).

Wenn das immer noch nicht funktioniert

Wenn die fünf „Anfängerlösungen“ nicht ausreichen, gehe ich systematischer vor. Das Verfahren ist immer noch machbar, erfordert aber etwas Vorgehen.

1) Überprüfen Sie die Serverprotokolle (oft informativer als die Datei debug.log).

Bei vielen Hosting-Anbietern finden Sie im Kontrollpanel ein Apache/Nginx-„Fehlerprotokoll“. Suchen Sie nach:

  • PHP Fatal error
  • Premature end of script headers
  • Allowed memory size

2) Verwenden Sie den Gesundheitscheck (Fehlerbehebungsmodus)

Wenn Sie über Administratorrechte verfügen, können Sie mit dem Health Check-Plugin Plugins/Themes deaktivieren. nur für dichohne Auswirkungen auf die Besucher. Dies ist auf einer Live-Website sehr praktikabel.

Plugin: Health Check & Fehlerbehebung

3) Überprüfen Sie die tatsächliche PHP-Version

Eine Website könnte zwar annehmen, dass sie mit PHP 8.1 läuft, aber eine Subdomain oder ein Cronjob könnte mit Version 7.4 laufen (ich habe das schon erlebt). Prüfen Sie Folgendes:

  • Tools > Site-Status
  • oder das Panel des Hosting-Anbieters

4) Deaktivieren Sie vorübergehend die mu-Plugins.

Die Mu-Plugins (unbedingt zu verwendende Plugins) werden automatisch geladen von wp-content/mu-pluginsSie sind in der Liste der Standarderweiterungen nicht sichtbar. Einige Hosting-Anbieter verwenden Caches/Sicherheitsmaßnahmen.

Test: umbenennen mu-plugins en mu-plugins.off per FTP, dann testen.

5) Permanente Links / Rewrite-Regeln („Admin OK, Seiten 404/500“)

Dies ist kein typischer WSOD, aber nach einer Migration oder einem Plugin kommt es häufig zu Verwechslungen. Gehen Sie zu:

Einstellungen> Permalinks dann klick Speichern (ohne etwas zu ändern).

Offizielles Dokument: WP-CLI (für Profis) (Nützlich, wenn Sie SSH-Zugriff haben, aber hier optional).

6) Dateiberechtigungen prüfen (selten, aber vorkommend)

Zu restriktive Berechtigungen können Serverfehler verursachen. In gemeinsam genutzten Linux-Umgebungen beobachten wir häufig Folgendes:

  • Dateien: 755
  • Dateien: 644

Falls Ihr Hosting-Anbieter andere Empfehlungen hat, befolgen Sie diese.

Häufige Fallstricke und Fehler

Symptom Mögliche Ursache Empfohlene Lösung
Sie haben WP_DEBUG aktiviert, aber debug.log erscheint nicht wp-content Nicht beschreibbar / Fehlerhafte Konfiguration / Fehler beim Laden Überprüfen Sie die Berechtigungen und sehen Sie sich dann die Serverprotokolle an.
Weißer Bildschirm direkt nach dem Einfügen eines Codes Fehlendes Semikolon/fehlende geschweifte Klammer, Code an der falschen Stelle eingefügt Lösung 4 (den Codeabschnitt korrigieren), idealerweise in einem benutzerdefinierten Plugin.
Im privaten Browsermodus funktioniert es, aber nicht "normal". Browser-Cache / Plugin / CDN Lösung 5 (Bereinigungen) + vorübergehende Deaktivierung der Minifizierung
Elementor/Divi/Avada öffnet den Editor nicht mehr Speicherzugriffe, REST/AJAX-Angriffe aus Sicherheitsgründen blockiert, Plugin-Konflikt Lösung 3 + Konsole prüfen + Sicherheits-Plugin deaktivieren
Du hast ein altes Tutorial befolgt. Inkompatibler Code: WordPress 6.9.4 / PHP 8.1 Ersetzen Sie dies durch einen Ansatz, der die vorhandenen Hooks nutzt, und testen Sie ihn in der Staging-Umgebung.
Sie haben das übergeordnete Design geändert. Verlust von Änderungen beim Update, Bruchrisiko Verwenden Sie ein Child-Theme oder ein benutzerdefiniertes Plugin (siehe Abschnitt „Vermeiden“).
Der weiße Bildschirm erscheint nach der "Reparatur" erneut. OPcache/CDN verwendet immer noch die alte Version Lösung 5 (PHP-FPM nach Möglichkeit löschen und neu laden)

Die häufigsten menschlichen Fehler, die ich beobachte:

  • Fügen Sie einen Codeausschnitt ein in eine fehlerhafte Datei (z.B. in einer Vorlage anstelle von functions.php).
  • Vergessen eines Klammer oder Semikolon.
  • Verwechseln Aktion et Filter (z. B. verwenden) add_action statt add_filter).
  • Testen Sie direkt auf Produktion ohne Datensicherung.
  • Vergessen Sie Leeren Sie den Cache nach der Korrektur.

Variante / Alternative

Methode ohne Programmierung (empfohlen für Anfänger)

Wenn Sie Zugriff auf das Admin-Panel haben, installieren Sie Folgendes:

Dies ist die sicherste Methode auf einer Online-Plattform: Man ermittelt, ohne das Besuchererlebnis zu beeinträchtigen.

Erweiterte Methode (für Entwickler): mu-Plugin-Backup

Wenn Sie häufig Fehler beheben (oder mehrere Websites verwalten), können Sie ein Mu-Plugin (Automatisch geladen), um eine minimale Protokollierung zu erzwingen und die Anzeige von Fehlern zu vermeiden.

Wo der Code eingefügt werden soll: Datei erstellen wp-content/mu-plugins/00-rescue.php (Erstellen Sie den Ordner, falls er nicht existiert).

<?php
/**
 * Plugin Name: Rescue minimal
 * Description: Aide au dépannage : loggue des infos minimales si le site plante tôt.
 * Author: Votre Nom
 *
 * Attention : ceci ne remplace pas WP_DEBUG. C'est un filet de sécurité.
 */

if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

// Exemple : log simple pour confirmer que WordPress charge bien les mu-plugins.
error_log( '[Rescue] mu-plugin chargé' );

Risiken: Zu viele Einträge in die Protokolldatei können diese füllen. Halten Sie die Datei daher so klein wie möglich und löschen Sie sie nach der Fehlerbehebung.

Offizielle Referenz zu mu-Plugins: developer.wordpress.org/advanced-administration/plugins/mu-plugins

Vermeiden Sie dieses Problem in Zukunft

WSODs treten immer wieder auf, wenn man schnelle Lösungen versucht, ohne seine Gewohnheiten zu ändern. Hier erfahren Sie, was das Risiko tatsächlich verringert.

1) Nehmen Sie Ihre Änderungen in einem benutzerdefinierten Plugin vor, nicht in der functions.php.

Für wiederverwendbare Code-Schnipsel bevorzuge ich ein kleines, individuell entwickeltes Plugin. Der Vorteil ist, dass man es mit einem Klick deaktivieren kann, ohne das Theme zu beeinträchtigen.

Wo der Code eingefügt werden soll: erstellen wp-content/plugins/mon-plugin-custom/mon-plugin-custom.phpDann aktiviere es.

<?php
/**
 * Plugin Name: Mon plugin custom
 * Description: Snippets stables pour ce site (WordPress 6.9.4+ / PHP 8.1+).
 * Version: 1.0.0
 */

if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

/**
 * Exemple : on accroche un code sur une action.
 */
add_action( 'init', function () {
	// Code sûr : exécuté après le chargement de WordPress.
} );

2) Einen Stufenplan umsetzen

Testen Sie Updates (WordPress, Plugins, Themes, Builder) in einer Testumgebung. Das ist der Unterschied zwischen „5 Minuten Stress“ und „2 Stunden Panik“.

3) Auf Kompatibilität mit PHP 8.1+ prüfen.

Ein nicht mehr gewartetes Plugin kann nach einem PHP-Versionsupdate nicht mehr funktionieren. Prüfen Sie die Kompatibilität auf der Plugin-Seite (wordpress.org) und behalten Sie die Änderungsprotokolle im Auge.

4) Halten Sie einen Notfallzugang bereit

  • Funktionaler SFTP/FTP-Zugriff
  • Zugriff auf das Hosting-Kontrollpanel (Protokolle, PHP-Version, Cache)
  • Tägliche Datensicherung (idealerweise extern)

5) Cache: Dokumentieren Sie Ihren „Löschpfad“

Bei Websites mit CDN, Plugin-Cache und Server-Cache sollte klar angegeben werden, wo der Cache geleert werden soll. Andernfalls wird zwar ein Problem „behoben“, die tatsächliche Behebung ist aber nicht sichtbar.

Ressourcen

Häufig gestellte Fragen

Wird WSOD zwangsläufig durch ein Plugin verursacht?

Nein. Ein Theme, ein Child-Theme, ein Code-Snippet, unzureichender Speicher oder ein Server-Cache können alle dasselbe Symptom hervorrufen. Die schnellste Methode bleibt: debug.log + Massendeaktivierung (Lösung 1 + 2).

Warum erhalte ich keine Fehlermeldungen?

Da die meisten Server PHP-Fehler im Produktivbetrieb verbergen, ist dies normal (aus Sicherheitsgründen). Aktivieren Sie die Protokollierung über WP_DEBUG_LOG Den Fehler abrufen, ohne ihn den Besuchern anzuzeigen.

Kann ich das ohne FTP beheben?

Ja, wenn Sie Administratorrechte haben: Ein Systemcheck und das Deaktivieren von Plugins reichen oft aus. Ohne Administratorrechte ist der Dateizugriff (FTP/SFTP) der direkteste Weg.

Meine Website ist nur auf einer Seite weiß, nicht überall. Warum?

Diese Seite löst wahrscheinlich spezifischen Code aus: einen Shortcode, ein Widget, eine Vorlage, eine ressourcenintensive Anfrage oder Inhalte, die nicht genügend Speicherplatz haben. Aktivieren Sie das Debugging und laden Sie diese Seite anschließend neu, um eine aussagekräftige Ablaufverfolgung zu erhalten.

Elementor zeigt im Editor einen weißen Bildschirm an: Ist das dasselbe?

Oft ja, aber das Problem könnte auf der REST-API-/AJAX-Seite liegen. Überprüfen Sie den Netzwerk-Tab: Wenn die Anfragen an /wp-json/ ou admin-ajax.php Wenn der Fehlercode 500 zurückgegeben wird, suchen Sie nach einem PHP-Fehler (Lösung 1) oder nach einem Speichermangel (Lösung 3).

Nach der Korrektur sehe ich immer noch einen weißen Bildschirm. Was soll ich tun?

Denken Sie an Caching: privates Surfen, Plugin-Löschung, CDN-Löschung und, wenn möglich, OPcache-Löschung (Lösung 5). Dies ist eine sehr häufige Falle.

Ist es gefährlich, WP_DEBUG auf einer Produktionsseite zu aktivieren?

Wenn Sie Fehler auf dem Bildschirm anzeigen, ja (Sie könnten sensible Informationen preisgeben). Wenn Sie nur protokollieren (WP_DEBUG_DISPLAY à falseDas Hauptrisiko besteht in der Erzeugung einer großen Protokolldatei. Deaktivieren Sie diese Funktion nach der Fehlerbehebung.

Welche Datei muss ich ändern: functions.php, wp-config.php oder .htaccess?

Zur Diagnose: wp-config.php (Lösung 1). So korrigieren Sie einen Codeabschnitt: functions.php vom Child-Theme oder, noch besser, von einem benutzerdefinierten Plugin (Lösung 4 / „Vermeiden“). .htaccess ist eher für Probleme mit dem Umschreiben von Links/Permalinks gedacht, nicht für die Mehrheit der WSODs.

Die Website funktioniert wieder, wenn ich ein Plugin deaktiviere, aber ich brauche sie. Was soll ich tun?

Notieren Sie sich die genaue Fehlerursache (Datei/Zeile) und aktualisieren Sie das Plugin. Kontaktieren Sie anschließend den Entwickler mit dem Trace. Suchen Sie in der Zwischenzeit nach einer Alternative oder deaktivieren Sie nur die Funktion, die den Fehler auslöst (häufig Caching, Minifizierung oder Sicherheitseinstellungen).

In Verbindung stehende Artikel

Senden Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Diese Website verwendet Akismet, um unerwünschte Inhalte zu reduzieren. Erfahren Sie mehr über die Verarbeitung Ihrer Feedback-Daten.