Block-Editor lädt nicht oder bleibt weiß: So grenze ich Plugin-Konflikte und Browser-Erweiterungen ein

Sie öffnen einen Beitrag zum Bearbeiten, und statt der gewohnten Blöcke sehen Sie eine leere, weiße Fläche. Oder der Editor lädt scheinbar ewig, die Symbolleiste erscheint, aber kein einziger Block lässt sich anklicken. Manchmal hilft ein Neuladen der Seite, manchmal nicht. Das Problem tritt meist nach einem Update auf — WordPress selbst, ein Plugin oder das Theme —, kann aber auch mitten im Alltag ohne erkennbaren Auslöser auftauchen.

Ich gehe bei diesem Fehlerbild immer in derselben Reihenfolge vor, weil die häufigsten Ursachen auch die sind, die sich am schnellsten ausschließen lassen.

Woran es liegt

Ein weißer oder hängender Block-Editor entsteht fast immer dadurch, dass JavaScript im Browser abbricht, bevor der Editor fertig aufgebaut ist. Die Kandidaten, die ich der Reihe nach prüfe:

• Eine Browser-Erweiterung greift in die Seite ein — Werbeblocker, Passwort-Manager und Übersetzungs-Tools sind die häufigsten Störer.
• Ein Plugin lädt eigenes JavaScript, das mit dem Editor kollidiert, oft nach einem Update dieses Plugins.
• Das Theme bringt Skripte in den Editor-Bereich ein, die dort nicht gedacht waren.
• Die REST-API von WordPress ist blockiert — durch ein Sicherheits-Plugin, eine falsch konfigurierte `.htaccess` oder ein restriktives Hosting-Firewall-Regelwerk.
• Der verfügbare Arbeitsspeicher für PHP reicht nicht aus, wenn gleichzeitig viele Plugins Daten in den Editor laden.

Theoretisch kommt auch ein fehlerhafter Block selbst infrage — dafür gibt es allerdings ein eigenes Fehlerbild mit roter Meldung, kein weißer Bildschirm. Diesen Fall habe ich bereits in einem eigenen Beitrag beschrieben.

So gehe ich Schritt für Schritt vor

Zuerst die Browser-Seite: Editor im Inkognito-Fenster öffnen, dort sind die meisten Erweiterungen automatisch deaktiviert. Lädt der Editor dort normal, schalte ich im normalen Fenster nacheinander Erweiterungen ab, bis sich der Übeltäter zeigt — meistens ist es ein Werbeblocker oder ein Tool, das Formularfelder automatisch ausfüllt.

Bleibt der Editor auch im Inkognito-Modus weiß, liegt es nicht am Browser. Als Nächstes öffne ich die Entwicklerkonsole (F12, Reiter „Konsole“) und lade die Seite neu. Eine rote Fehlermeldung mit Dateiname verrät fast immer, welches Skript abbricht — steht dort der Name eines Plugin-Ordners, deaktiviere ich genau dieses Plugin testweise über „Plugins“ im Backend. Lässt sich das Backend selbst nicht mehr öffnen, hilft der Zugriff per FTP oder Dateimanager: den betreffenden Plugin-Ordner umbenennen, WordPress deaktiviert ihn dann automatisch.

Zeigt die Konsole keinen eindeutigen Hinweis, deaktiviere ich testweise alle Plugins bis auf WordPress selbst und schalte sie einzeln wieder ein, bis der Fehler zurückkommt. Das kostet etwas Zeit, führt aber sicher zur Ursache, wenn die Konsole schweigt. Parallel wechsle ich kurz auf ein Standard-Theme — meldet sich der Editor dort wieder, liegt es am Theme, nicht an einem Plugin.

Bleibt der Editor trotzdem weiß, prüfe ich die REST-API: Unter ihredomain.de/wp-json/ sollte eine JSON-Antwort erscheinen, keine Fehlerseite. Kommt dort ein 403 oder 406, blockiert ein Sicherheits-Plugin oder eine Firewall-Regel den Zugriff — in dem Fall braucht die Regel eine Ausnahme für /wp-json/wp/v2/.

Was danach zu prüfen ist

Nach der Lösung öffne ich testweise zwei oder drei weitere Beiträge unterschiedlichen Typs (Seite, Beitrag, falls vorhanden ein Produkt), weil sich ein Plugin-Konflikt manchmal nur bei bestimmten Inhaltstypen zeigt. Außerdem lohnt ein Blick in die E-Mails an die Administrator-Adresse: Hat WordPress ein Plugin automatisch über den Fehlerschutz-Modus abgeschaltet, kommt dort eine Benachrichtigung mit Link zur Reaktivierung an.

Wie ich es künftig vermeide

Updates von Plugins und Theme einzeln einspielen statt alle auf einmal, idealerweise zuerst auf einer Staging-Kopie — dazu mehr in meinem Beitrag zu WordPress-Updates ohne Schrecksekunde. Wer regelmäßig mit demselben Browser-Profil arbeitet, sollte Erweiterungen, die tief in Seiteninhalte eingreifen, für den Administrationsbereich gezielt deaktivieren statt sie dauerhaft laufen zu lassen. Und: ein zweites Administrator-Konto mit einem „sauberen“ Browserprofil spart im Ernstfall viel Zeit bei der Fehlersuche — mehr dazu auch in meinen Praxisbeiträgen zum Thema WordPress.

Kurz beantwortet

Woran erkenne ich, ob es am Browser oder an der Website liegt?

Öffnen Sie den Editor im Inkognito-Fenster. Funktioniert er dort, liegt es an einer Browser-Erweiterung im normalen Fenster.

Muss ich bei einem Plugin-Konflikt gleich alle Plugins deaktivieren?

Nur als letzten Schritt, wenn die Entwicklerkonsole keine eindeutige Fehlermeldung zeigt. Oft genügt es, einzelne zuletzt aktualisierte Plugins testweise abzuschalten.

Was tue ich, wenn ich mich ins Backend gar nicht mehr einloggen kann?

Dann hilft nur der Zugriff per FTP oder Dateimanager des Hostings: den vermuteten Plugin-Ordner umbenennen, WordPress deaktiviert ihn dadurch automatisch.

Sie möchten das Thema für Ihr Unternehmen umsetzen? Mehr zu unseren Leistungen: Webdesign, SEO, GEO & AEO.