Der WordPress Block-Editor lädt nicht — so behebst du es

Meistens steckt hinter einem WordPress Block-Editor, der nicht lädt, ein JavaScript-Fehler — ein einziges kaputtes Skript aus einem Plugin oder Theme legt die gesamte React-App lahm, und der Editor wird nie fertig gerendert. Öffne die Entwicklerkonsole deines Browsers (F12, oder Cmd+Option+I auf dem Mac), lade die Bearbeitungsseite neu und lies den roten Fehler. Fast immer nennt er die Datei, die den Fehler geworfen hat. Diese eine Zeile verrät dir, welches Plugin du deaktivieren musst, und normalerweise bist du in unter fünf Minuten wieder am Schreiben. WordPress neu installieren, das PHP-Speicherlimit hochsetzen und auf den Classic Editor wechseln sind die drei häufigsten Ratschläge im Netz — und alle drei sind meistens der falsche Weg.

Warum der Editor genau so kaputtgeht

Der Block-Editor (Gutenberg) ist eine Single-Page-React-Anwendung, die innerhalb von wp-admin/post.php und post-new.php läuft. WordPress lädt einen Stapel Skript-Pakete — wp-blocks, wp-element, wp-editor, wp-edit-post — und die App bootstrappt über wp.domReady(). JavaScript stoppt die Ausführung bei der ersten nicht abgefangenen Exception. Wenn also irgendein geladenes Skript beim Initialisieren des Editors einen Fehler wirft, stirbt alles danach mit ihm. Dein sorgfältig aufgebauter Beitragsbereich zerfällt zu einer leeren weißen Fläche oder zur Meldung „Der Editor ist auf einen unerwarteten Fehler gestoßen.“

Standardmäßig fasst WordPress außerdem Admin-Skripte zu weniger Requests zusammen (Konkatenierung). Das bedeutet: Das kaputte JS eines Plugins kann unbeteiligte Skripte im selben Bündel mit in den Abgrund reißen — deshalb ist der Übeltäter nicht immer allein am Verhalten zu erkennen. In der Konsole schon.

Der zweite Fehlertyp sieht anders aus: Der Editor lädt, aber beim Speichern kommt „Aktualisierung fehlgeschlagen. Die Antwort ist keine gültige JSON-Antwort.“ Das ist kein JavaScript-Problem. Der Editor spricht mit der REST-API unter /wp-json/wp/v2/ und erwartet sauberes JSON zurück. Wenn ein Plugin oder die functions.php deines Themes einen PHP-Hinweis, eine Warnung oder einen Fatal Error vor dem JSON ausgibt — oder ein Security-Plugin die REST-Route blockiert oder ein Redirect-Plugin die URL umschreibt — ist die Antwort verunreinigt und der Editor kann sie nicht parsen.

So behebst du es, das Schnellste zuerst

1. Lies die Konsole. Reproduziere den Fehler mit geöffneten DevTools. Ein Fehler wie Uncaught TypeError ... some-plugin/build/index.js zeigt direkt auf das schuldige Plugin. Dieser eine Schritt löst die meisten Fälle und erspart dir das blinde Durchprobieren.

2. Schließe den Browser aus. Hard-Refresh (Cmd/Ctrl+Shift+R), dann probier ein Inkognito-Fenster mit deaktivierten Erweiterungen. Ad-Blocker und Privacy-Erweiterungen entfernen gelegentlich Admin-Skripte. Wenn es im Inkognito-Modus funktioniert, liegt das Problem an einer Browser-Erweiterung oder einem veralteten Cache, nicht an deiner Website.

3. Prüfe die REST-API direkt, falls du die Meldung „keine gültige JSON-Antwort“ gesehen hast. Rufe https://deineseite.com/wp-json/ im Browser auf. Du solltest eine Wand aus JSON bekommen. Bekommst du HTML, einen 500er oder eine Weiterleitung zum Login, ist das dein Fehler — ein Plugin zerstört die REST-Antwort, nicht der Editor selbst.

4. Grenze deine Plugins ein. Deaktiviere alle, bestätige, dass der Editor lädt, und aktiviere sie dann einzeln wieder, bis es erneut bricht. Wenn du komplett aus wp-admin ausgesperrt bist, mach es per SFTP, indem du den Ordner umbenennst:

mv wp-content/plugins wp-content/plugins_off

WordPress deaktiviert alles, wenn der Ordner verschwindet. Benenne ihn zurück und schiebe die Plugins dann einzeln rein und raus.

5. Teste das Theme. Wechsle zu Twenty Twenty-Four. Ein Theme, das kaputtes Editor-JS lädt oder in der functions.php einen PHP-Fehler wirft, erzeugt dieselben Symptome.

6. Schalte das Log ein und lies den echten Fehler. Gerade bei den REST/JSON-Fehlern aktivierst du den Debug-Modus in der wp-config.php:

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

Der Fatal Error wird mit exakter Datei und Zeilennummer in wp-content/debug.log geschrieben. Wenn dieser Stacktrace dicht ist — Klassennamen mit Namespaces, require-Ketten, ein Fatal Error unter zehn Zeilen Trace vergraben — füge ihn in unseren WordPress Error-Log-Decoder ein, um in Klartext zu sehen, welches Plugin und welche Zeile ihn tatsächlich ausgelöst haben. Das ist der Unterschied zwischen „irgendwas ist kaputt“ und „Zeile 214 genau dieses Plugins ist kaputt“.

Wenn du vermutest, dass die Skript-Konkatenierung den echten Übeltäter verdeckt, erzwinge, dass jedes Skript einzeln geladen wird, damit der Konsolenfehler auf genau eine Datei zeigt:

define( 'SCRIPT_DEBUG', true );
define( 'CONCATENATE_SCRIPTS', false );

Was du nicht tun solltest

Installiere nicht einfach das Classic-Editor-Plugin und erkläre das Problem für gelöst. Es behebt nichts — es blendet nur den Block-Editor aus, sodass du den Fehler nicht mehr siehst. Das kaputte JavaScript oder die kaputte REST-Antwort ist immer noch da und wird dich im Site-Editor, bei den Widgets oder beim nächsten Update wieder einholen. Diagnostiziere zuerst; greif nur dann auf Classic zurück, wenn du dich bewusst dafür entschieden hast, keine Blöcke mehr zu nutzen.

Setze nicht reflexartig das PHP-Speicherlimit hoch. Das ist der beliebteste Copy-Paste-Fix des Internets, aber ein leerer Editor ist selten eine Speichererschöpfung. Echte Erschöpfung wirft einen spezifischen Fatal Error — „Allowed memory size of N bytes exhausted“ —, den du in der debug.log siehst. Fehlt diese Zeile, ändert mehr Speicher gar nichts.

Installiere WordPress-Core nicht neu. Die Core-Dateien sind auf jeder Installation Byte für Byte identisch. Wäre der Core das Problem, hätte gerade jede WordPress-Website auf der Welt einen kaputten Editor. Der Fehler steckt fast immer in deinen Plugins oder deinem Theme, und eine Core-Neuinstallation riskiert, Dinge zu überschreiben, ohne etwas zu beheben.

Lösche oder deaktiviere dein Cache-Plugin nicht blind als ersten Schritt. Aggressive JS-Minifizierung und -Konkatenierung können den Editor kaputtmachen, also lohnt sich ein Test — aber prüf die Konsole, bevor du wahllos Caches leerst. Raten ist der Weg, wie aus einem Fünf-Minuten-Fix ein ganzer Nachmittag wird.

Immer noch festgefahren?

Wenn die Konsole sauber ist, die REST-API gültiges JSON zurückgibt und ein kompletter Durchlauf durch Plugins und Theme den Editor trotzdem tot lässt, sitzt die Antwort fast immer in der debug.log. Aktiviere WP_DEBUG_LOG, reproduziere den Fehler einmal und jage den daraus entstehenden Fatal Error durch den Error-Log-Decoder. Der Stacktrace nennt die Datei — fang dort an.