Gutenberg hängt: WordPress-Blockeditor reparieren

Wenn der Block-Editor jemals bei „Wird geladen…“ hängen bleibt oder die Fehlermeldung „Der Editor ist auf einen unerwarteten Fehler gestoßen“ anzeigt, liegt wahrscheinlich ein Problem mit Ihrer REST-API, Ihren Admin-Skripten oder dem Caching/der Sicherheit vor. In WordPress 6.9.4 (April 2026) setzt Gutenberg noch stärker als zuvor auf eine übersichtliche Admin-Oberfläche: REST-APIs, Nonces, versionierte Skripte und saubere JSON-Antworten.

das Problem

Die typischen Meldungen, die ich in der Browserkonsole (oder in der Benutzeroberfläche) sehe, sehen folgendermaßen aus:

"The editor has encountered an unexpected error."
"Updating failed. The response is not a valid JSON response."
"Error: The REST API encountered an error."
"GET https://example.com/wp-json/wp/v2/types/post?context=edit 403 (Forbidden)"

Es erscheint im Admin-Panel, am Artikel → Hinzufügen / Seiten → Bearbeiten, manchmal nur bei bestimmten Inhaltsarten (CPT) und oft direkt im Anschluss:

ein Sicherheits-/Cache-Plugin-Update,
eine Änderung der WAF/CDN-Regel (Cloudflare, Sucuri, ModSecurity),
Hinzufügen eines Code-Snippets, das den HTML-Code „bereinigt“,
eine Migration (URL, HTTPS, Reverse-Proxy),
oder ein Theme-Update (Avada) / Page-Builder-Update (Elementor, Divi 5), das Admin-Skripte hinzufügt.

Diese Anleitung richtet sich an fortgeschrittene Benutzer: Sie wissen, wie man die Konsole öffnet, Logs liest, ein MU-Plugin installiert und WP-CLI verwendet. Am Ende werden Sie in der Lage sein, die Ursache (REST, JS, Cache, Sicherheit, PHP) zu isolieren und eine saubere Lösung anzuwenden, die mit WordPress 6.9.4+ und PHP 8.1+ kompatibel ist.

Kurze Zusammenfassung

Beginnen Sie mit der Konsole. : der Fehler Der sichtbare Fehler (403 REST, ungültiges JSON, JS-Datei 404) bestimmt den Rest.
Sofortiger REST-Test : /wp-json/wp/v2/types/post?context=edit Vergleichen Sie anschließend, während Sie angemeldet sind, mit einem Administratorkonto.
Störsender deaktivieren Sicherheits-/Cache-Plugins, Code-Snippets, JS/CSS-Optimierung, CDN – aktivieren Sie diese anschließend einzeln.
Saubere Protokolle aktivieren : WP_DEBUG_LOG + Query Monitor und Suche nach „REST“, „Nonce“, „Header bereits gesendet“, „fatal“.
Gutenberg sollte nicht mit jQuery "repariert" werden. Die meisten Fehler entstehen durch eine Warteschlange oder einen Filter, der die JSON-Antworten verändert.
Wenn Sie auf einem Bauplatz sind Divi 5/Elementor/Avada fügen Administrator-Assets hinzu; ein Optimierungs- oder Sicherheitskonflikt ist häufig.

Symptome

Hier sind die Symptome, die ich am häufigsten sehe (von den häufigsten bis zu den „kniffligsten“).

Weißer Bildschirm im Editor mit einem unendlichen Spinner.
UI-Meldung „Dem Verlag ist ein unerwarteter Fehler unterlaufen.“
Veröffentlichungsfehler „Das Update ist fehlgeschlagen. Die Antwort ist keine gültige JSON-Antwort.“
Browserkonsole (F12 → Konsole / Netzwerk):
- 403/401 raus /wp-json/... (oft WAF oder Sicherheitsregel),
- 500-Fehler bei einer REST-Route (schwerwiegender PHP-Fehler auf Serverseite),
- 404-Fehler bei einer Datei wp-includes/js/dist/*.min.js (Cache/CDN oder unvollständige Bereitstellung),
- CORS- oder CSP-Fehler (übermäßig strenge Sicherheitsheader),
- Unexpected token < in JSON (HTML, das in eine JSON-Antwort eingefügt wird, typischerweise eine PHP-Warnung oder eine HTML-403-Seite).
Es funktioniert lokal, aber nicht in der Produktion. : CDN, aggressives Caching, WAF oder Unterschiede in PHP/Erweiterungen.
Es funktioniert für einen Administrator, aber nicht für einen Redakteur. : Fähigkeiten, Nonces oder Plugins, die nach Rolle filtern.
Es bricht nur bei einem CPT ab. : show_in_rest Fehlende oder benutzerdefinierte REST-Route, was fatal ist.

Schnelldiagnosetabelle

Symptom	Mögliche Ursache	Überprüfung	Lösung
„Ungültige JSON-Antwort“	HTML/Warnung in REST eingefügt	Öffnen Sie die Netzwerkantwort von `/wp-json/...`	Plugin/Snippet deaktivieren, corriger Warnhinweise, siehe Lösung 1
403 auf `/wp-json/`	WAF, Sicherheitsregel, Basisauthentifizierung	REST-Test im privaten Browsermodus + WAF-Protokolle	REST-Header auf die Whitelist setzen, siehe Lösung 1
Endlos-Spinner, JS-Fehler	Defekte Admin-Warteschlange / JS-Optimierung	Konsole: „Eigenschaften von undefinierten Objekten können nicht gelesen werden“	Korrigieren Warteschlange einrichten, Assets ausschließen, siehe Lösung 2
404 auf `wp-includes/js/dist/`	Unvollständige Bereitstellung / CDN-Cache	Testen Sie dies, indem Sie das CDN deaktivieren und den Cache leeren.	Bereinigung und erneute Bereitstellung, siehe Lösung 3
500 auf einer REST-Straße	Schwerwiegender PHP-Fehler (Plugin/Theme)	WP_DEBUG_LOG + Abfragemonitor	Um schwerwiegende Fehler zu beheben, führen Sie ein Rollback durch (siehe Lösung 1).

Warum passiert das

Vereinfacht gesagt: Der Block-Editor ist eine JavaScript-Anwendung, die über die REST-API ständig mit Ihrer Website kommuniziert. Wenn die REST-API etwas anderes als sauberes JSON zurückgibt (oder wenn die benötigten Skripte nicht geladen werden), kann der Editor seinen Zustand nicht initialisieren.

Hier ist, was hinter den Kulissen passiert (technische Version):

Gutenberg lädt Pakete von wp-includes/js/dist/ und Admin-Stile.
Es ruft Daten über REST-Endpunkte ab (Typen, Taxonomien, Einstellungen, automatisches Speichern, Beitrag, Etc.).
Es sendet authentifizierte Anfragen mit Nonces. Wenn ein Plugin Header ändert, Routen blockiert oder "Bearbeitungskontext"-Antworten zwischenspeichert, funktioniert es nicht mehr.
Eine PHP-Warnung, ein „Hinweis“ oder sogar ein Leerzeichen davor <?php kann ausreichen, um eine JSON-Antwort zu verfälschen.

Mögliche Ursachen (von der häufigsten zur seltensten):

REST-Blockierung durch Sicherheits-/Cache-/CDN-Daten (403, Herausforderung, Basisauthentifizierung, ModSecurity-Regel).
verschmutzte REST-Antwort durch eine PHP-Warnung, ein var_dump()oder ein Plugin, das HTML ausgibt.
JS/CSS-Optimierung wodurch die Admin-Skripte (oder „verzögerte“ WordPress-Skripte) kombiniert/minimiert werden.
Schlecht gestaltete Admin-Warteschlange (fehlende Abhängigkeiten, ungeeigneter Hook, globales Laden auf allen Seiten).
CSP/Sicherheitsheader zu streng (blockiert blob:, data:oder die erwarteten Skripte/Stile).
Cache-Inkonsistenz (Service Worker, Browser-Cache, Objekt-Cache, CDN), der Ressourcen aus einer anderen Version bereitstellt.
Serverproblem (Dateiberechtigungen, unvollständige Bereitstellung, Opcache, fehlende PHP-Erweiterung).

Voraussetzungen vor Beginn

Sauvegarde Dateien + Datenbank (oder Snapshot, falls Sie einen Managed-Hosting-Service nutzen). Testen Sie nicht „zufällig“ in der Produktionsumgebung.
Test Umgebung Idealerweise eine Vorbereitungsphase oder zumindest ein Wartungsfenster.
Versionen WordPress 6.9.4 und PHP 8.1+ werden empfohlen. Einchecken Tools → Site-Status.
Nützliche Plugins :
- Abfrage-Monitor (Abfragen, PHP-Fehler, Hooks, REST).
- Health Check & Fehlerbehebung (Fehlerbehebungsmodus ohne Beeinträchtigung der Besucher).
Logs vorübergehend aktivieren WP_DEBUG_LOG (ohne Anzeige im Frontend).

Empfohlene (vorübergehende) Konfiguration in wp-config.php :

<?php
// Active le debug sans afficher les erreurs à l'écran (évite de polluer des réponses JSON).
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );

// Log dans wp-content/debug.log
define( 'WP_DEBUG_LOG', true );

// Optionnel : réduit les "notices" bruyantes de certains plugins (à ajuster selon votre besoin).
// error_reporting( E_ALL & ~E_NOTICE & ~E_DEPRECATED );

Sicherheitsrisiko Verlasse nicht WP_DEBUG Dauerhaft auf einer öffentlichen Website aktiviert. Protokolle können Pfade, Anfragen und sogar sensible Informationen enthalten.

Lösung 1: Die REST-API ist blockiert (403/401/500) und Gutenberg kann nicht mehr gestartet werden.

Wenn Gutenberg nicht geladen werden kann, beginne ich immer mit einer einfachen REST-Anfrage. Denn wenn REST nicht funktioniert, kann man alle Skripte der Welt reparieren: Der Editor bleibt instabil.

Diagnostisch

Öffnen Sie den Editor als Administrator und drücken Sie dann F12 → Tabulatortaste. Netzwerk.
Filtern auf wp-json.
Identifizieren Sie die erste Fehlerabfrage (oft types, settings, posts).
Klicken Sie auf die Abfrage → anzeigen Antwort :
- Wenn Sie HTML-Code sehen (Fehlerseite, Abfrage, Anmeldeseite), haben Sie es gefunden.
- Notieren Sie sich alle WordPress-Fehlermeldungen im JSON-Format. code et message.

Schneller Test über die Kommandozeile (mit WP-CLI und Cookie/Nonce ist es komplexer). Für einen einfachen Test führen Sie den Befehl im Browser aus, während Sie angemeldet sind:

URL : https://votre-site.tld/wp-json/wp/v2/types/post?context=edit

Wenn Sie einen 403/401-Fehler oder einen HTML-Seitenfehler erhalten, liegt die Ursache fast immer außerhalb von WordPress (WAF, Sicherheits-Plugin, Basic Auth, Reverse-Proxy).

Häufiger Fall: Ein Plugin blockiert REST durch einen zu strengen Filter.

Ich bin schon oft auf Code-Schnipsel gestoßen, die aus Sicherheitsgründen die REST-API deaktivieren, aber dadurch funktioniert der Editor nicht mehr (und manchmal auch Elementor/Divi/Avada auf der Admin-Seite nicht mehr).

VORDERSEITE (defekt)

<?php
// Mauvaise idée : bloque l'API REST pour tout le monde, y compris l'admin.
// Résultat : Gutenberg ne peut plus charger.
add_filter( 'rest_authentication_errors', function( $result ) {
	return new WP_Error(
		'rest_disabled',
		'REST API désactivée',
		array( 'status' => 403 )
	);
} );

NACH (korrigierte, gezielte Einschränkung)

<?php
/**
 * Restriction REST plus sûre : ne bloque pas l'admin, et limite seulement certaines routes publiques.
 * À placer dans un plugin (ou MU-plugin), pas dans functions.php si vous changez souvent de thème.
 */
add_filter( 'rest_authentication_errors', function( $result ) {

	// Si une authentification a déjà échoué/réussi, respectez le résultat.
	if ( ! empty( $result ) ) {
		return $result;
	}

	// Autorisez toujours les utilisateurs connectés (Gutenberg en dépend).
	if ( is_user_logged_in() ) {
		return $result;
	}

	// Exemple : bloquer uniquement une route custom publique (à adapter).
	$request_uri = isset( $_SERVER['REQUEST_URI'] ) ? (string) $_SERVER['REQUEST_URI'] : '';

	if ( str_contains( $request_uri, '/wp-json/mon-namespace/v1/' ) ) {
		return new WP_Error(
			'rest_forbidden',
			'Accès REST interdit.',
			array( 'status' => 403 )
		);
	}

	return $result;
} );

Warum korrigiert es? Gutenberg ruft REST-Endpunkte im Kontext auf edit die eine bestehende Sitzung erfordern. REST „global“ zu blockieren, entspricht dem Trennen der internen API des Herausgebers.

Punkt der Wachsamkeit Dieser Filtertyp muss präzise sein. Blockieren nach „Vorhandensein von /wp-json/„ist ein Anti-Pattern. Wenn Sie die REST-Angreifbarkeit wirklich reduzieren wollen, gehen Sie Route für Route vor und testen Sie die Administration.“

Häufiger Fall: „Ungültige JSON-Antwort“ aufgrund einer PHP-Warnung

Wenn die REST-Antwort mit HTML beginnt, zeigt Gutenberg häufig die Meldung „Ungültige JSON-Antwort“ an. Die eigentliche Ursache ist manchmal eine einfache PHP-Warnung, die vor dem JSON ausgegeben wird.

VORDERSEITE (defekt)

<?php
// Exemple réaliste : un plugin/thème affiche un warning (variable non définie) et pollue la réponse REST.
add_action( 'init', function() {
	// Mauvais : echo en init, peut s'exécuter pendant une requête REST.
	if ( isset( $_GET['debug'] ) ) {
		echo "DEBUG"; // Pollue la sortie JSON.
	}
} );

NACH (korrigiert)

<?php
// Ne jamais "echo" dans le cycle WordPress global.
// Utilisez error_log() et limitez à WP_DEBUG.
add_action( 'init', function() {
	if ( defined( 'WP_DEBUG' ) && WP_DEBUG && isset( $_GET['debug'] ) ) {
		error_log( 'Debug init déclenché' );
	}
} );

Warum korrigiert es? Die REST-API muss striktes JSON zurückgeben. Jedes Ausgabezeichen (Warnung, Byte Order Mark, Echo) führt zu einem Fehler bei der JSON-Analyse im Browser.

Häufiger Fall: WAF/CDN-Blockierung (403, Challenge, Basic Auth)

Wenn die 403-Antwort eine „Zugriff verweigert“-HTML-Seite oder eine Challenge ist, ist WordPress nicht verantwortlich.

Deaktivieren Sie vorübergehend die WAF/CDN (oder wechseln Sie in den „Entwicklermodus“).
explizit erlauben /wp-json/ et /wp-admin/admin-ajax.php.
Wenn Sie die Basisauthentifizierung im Staging-Modus aktiviert haben, kann Gutenberg je nach Browserkonfiguration fehlschlagen. Erlauben Sie in diesem Fall die Administrator-IP-Adresse oder deaktivieren Sie die Basisauthentifizierung vorübergehend während der Bearbeitung.

Um den REST-Vertrag auf der WordPress-Seite zu verstehen, finden Sie die offizielle Dokumentation hier: REST-API-Handbuch.

Lösung 2: Fehlerhafte Editor-Skripte (Einreihen, Abhängigkeiten, Ladefolge)

Das zweite klassische Szenario: Ein Theme oder Plugin lädt ein Skript im Admin-Panel, aber:

am falschen Haken,
ohne Abhängigkeiten,
oder durch Überschreiben einer Bibliothek (React, lodash), die WordPress bereits bereitstellt.

Ergebnis: JS-Fehler des Typs wp is not defined, Cannot read properties of undefinedoder ein lautloser Unfall.

Diagnostisch

F12 → Konsole: Beachten Sie die Premiere Fehler (nicht der 15.). Der erste Fehler ist oft die Ursache.
F12 → Netzwerk: Suche nach einer JS-Datei mit einem 404/Blockierungsfehler.
Deaktiviere vorübergehend Optimierungs-Plugins (Minify/Combine/Defer), die sich auf das Admin-Panel auswirken.

Typischer Fall: globale Umfrage zu `admin_enqueue_scripts` ohne den Bildschirm anzuvisieren

Ich habe oft gesehen, dass überall ein "Admin"-Skript geladen wird, und es setzt die Existenz von wp.data (Gutenberg) sogar auf Bildschirmen, die es nicht laden. Oder umgekehrt: Es überschreibt globale Variablen.

VORDERSEITE (defekt)

<?php
// Mauvais : charge un script partout dans l'admin, sans dépendances, et trop tôt.
// Sur l'écran de l'éditeur, ça peut entrer en conflit.
add_action( 'admin_enqueue_scripts', function() {
	wp_enqueue_script(
		'mon-admin',
		get_stylesheet_directory_uri() . '/assets/admin.js',
		array(), // Oublie des dépendances éventuelles.
		'1.0',
		true
	);
} );

NACHHER (korrigiert: Targeting + Abhängigkeiten + Versionierung)

<?php
/**
 * Charge un script admin uniquement sur l'éditeur de blocs, avec des dépendances correctes.
 * Compatible WP 6.9.4+.
 */
add_action( 'admin_enqueue_scripts', function( $hook_suffix ) {

	// Cible les écrans post.php (édition) et post-new.php (création).
	if ( ! in_array( $hook_suffix, array( 'post.php', 'post-new.php' ), true ) ) {
		return;
	}

	$screen = function_exists( 'get_current_screen' ) ? get_current_screen() : null;
	if ( ! $screen ) {
		return;
	}

	// Optionnel : ne chargez que pour certains post types.
	$allowed_post_types = array( 'post', 'page' );
	if ( empty( $screen->post_type ) || ! in_array( $screen->post_type, $allowed_post_types, true ) ) {
		return;
	}

	$src  = get_stylesheet_directory_uri() . '/assets/admin-editor.js';
	$path = get_stylesheet_directory() . '/assets/admin-editor.js';

	wp_enqueue_script(
		'mon-admin-editor',
		$src,
		array( 'wp-data', 'wp-edit-post', 'wp-element' ), // Dépendances Gutenberg.
		file_exists( $path ) ? filemtime( $path ) : '1.0.0',
		true
	);
} );

Warum korrigiert es? Sie vermeiden eine Überfrachtung des gesamten Admin-Panels, laden nur dort, wo Gutenberg vorhanden ist, und deklarieren stabile Abhängigkeiten. Versionierung durch filemtime() Außerdem werden dadurch nach der Bereitstellung "Geistercaches" vermieden.

Häufiger Fall: Ein Plugin lädt React/ReactDOM manuell.

Wenn ein Plugin eine eigene Version von React im Admin-Bereich einbindet (oder diese über ein CDN lädt), können schwer zu diagnostizierende Fehler auftreten, insbesondere nach einem WordPress-Update. WordPress stellt die notwendigen Pakete für den Editor bereits bereit.

VORDERSEITE (defekt)

<?php
// Anti-pattern : charger React via CDN dans l'admin.
// Peut casser Gutenberg (deux React différents).
add_action( 'admin_enqueue_scripts', function() {
	wp_enqueue_script( 'react', 'https://unpkg.com/react@18/umd/react.production.min.js', array(), null, true );
	wp_enqueue_script( 'react-dom', 'https://unpkg.com/react-dom@18/umd/react-dom.production.min.js', array( 'react' ), null, true );
} );

NACHHER (korrigiert: WordPress-Pakete verwenden)

<?php
// Utilisez les packages WordPress (wp-element) au lieu de React embarqué.
add_action( 'admin_enqueue_scripts', function( $hook_suffix ) {
	if ( ! in_array( $hook_suffix, array( 'post.php', 'post-new.php' ), true ) ) {
		return;
	}

	wp_enqueue_script(
		'mon-ui',
		plugin_dir_url( __FILE__ ) . 'assets/mon-ui.js',
		array( 'wp-element', 'wp-components', 'wp-i18n' ),
		'1.0.0',
		true
	);
} );

Nützliche Dokumentation: wp-element-Paket et Block-Editor-Handbuch.

Divi 5 / Elementor / Avada-Kompatibilität

Divi 5 Wenn Sie Leistungsoptionen aktivieren, die die Administrationsoberfläche „optimieren“, testen Sie Gutenberg anschließend. Divi lädt manchmal Asset-Editoren für seine Module; schließen Sie diese aus. /wp-admin/ aggressive Optimierungen.
Elementor Obwohl Elementor über einen eigenen Editor verfügt, ist es in das WordPress-Admin-Panel integriert. Ein Optimierungs-Plugin, das Admin-Skripte kombiniert, kann Gutenberg und die Elementor-Oberfläche beeinträchtigen.
Avada Fusion Builder und Avada Live laden ressourcenintensive Skripte. Falls ein Cache-/Minifizierungsprozess den Administrationsbereich beeinträchtigt, zeigt Avada das Problem oft als erstes an.

Lösung 3: Caching, Sicherheit und CSP (Content-Security-Policy), die die Administration beeinträchtigen

Wenn Gutenberg nur in der Hälfte der Fälle oder erst nach einem vollständigen Neuladen funktioniert, vermute ich ein Cache-Problem. Bei Fehlermeldungen wie „Laden verweigert… aufgrund eines Verstoßes gegen die CSP-Richtlinien“ vermute ich fehlerhaft konfigurierte Sicherheitsheader.

Häufiger Fall: Optimierung, die die Administrationsdatei minimiert/verkettet

Viele Optimierungs-Plugins bieten die Option „Auch den Adminbereich optimieren“. Unter WordPress 6.9.4 ist dies oft keine gute Idee: Die Benutzeroberfläche ändert sich schnell, die Bundles sind bereits optimiert, und die Gefahr, Abhängigkeiten zu beschädigen, ist real.

Konkrete Maßnahmen:

JS/CSS-Optimierung deaktivieren /wp-admin/.
Mindestens ausschließen:
- /wp-includes/js/dist/
- /wp-admin/js/
- load-scripts.php et load-styles.php (falls verwendet)
Bereinigen: Plugin-Cache + Server-Cache + CDN + Browser.

Häufiger Fall: Übermäßig strenger sozioökonomischer Status

Ein „hochsicherer“ CSP kann Mechanismen blockieren, die vom Herausgeber verwendet werden (abhängig von Plugins, Medien, iFrames usw.). Fehler werden in der Konsole angezeigt, nicht in WordPress.

Beispiel für einen Konsolenfehler:

Refused to load the script 'blob:https://example.com/...' because it violates the following Content Security Policy directive...

Wenn Sie CSP über PHP verwalten (Sicherheits-Plugin, benutzerdefinierte Header), testen Sie, indem Sie die Einschränkungen nur für das Admin-Panel lockern. Hier ist ein Beispiel. minimal (muss an Ihre Sicherheitsrichtlinie angepasst und validiert werden):

<?php
/**
 * Exemple : définir des headers CSP uniquement dans l'admin.
 * Attention : une CSP doit être pensée globalement. Ne copiez pas ceci sans comprendre votre surface d'attaque.
 */
add_action( 'send_headers', function() {

	if ( ! is_admin() ) {
		return;
	}

	// Exemple volontairement simple. Ajustez selon vos besoins.
	// Objectif : éviter de casser des scripts/styles nécessaires à l'éditeur.
	header( "Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' blob:; style-src 'self' 'unsafe-inline'; img-src 'self' data: blob:; connect-src 'self' https:; frame-src 'self';" );
}, 20 );

Warum korrigiert es? Gutenberg und einige Admin-Komponenten können URLs verwenden. blob: / data: (abhängig von Funktionen und Erweiterungen). Eine zu restriktive CSP blockiert das Laden/Auswerten, und die JS-Anwendung startet nicht.

Sicherheitsrisiko : 'unsafe-inline' et 'unsafe-eval' Dies erhöht das Risiko von XSS-Angriffen. Idealerweise sollte dies vermieden werden. In der Praxis sind jedoch viele WordPress-Stacks (einschließlich Plugins) noch nicht für eine perfekt „streng-dynamische“ Content Security Policy (CSP) geeignet. Verwenden Sie stattdessen eine progressive CSP und den entsprechenden Modus. Nur Bericht um zu wiederholen.

Häufiger Fall: Assets einer älteren Version, die über CDN/opcache bereitgestellt werden

Nach einem WordPress-Update habe ich bereits einige gesehen wp-includes/js/dist/* Gutenberg lädt dann Dateien einer früheren Version über ein CDN. Anschließend werden Dateien aus einer früheren Version geladen.

Checkliste:

Leeren Sie den CDN-Cache (und nicht nur den Plugin-Cache).
Leeren Sie den PHP-Opcache, falls Sie Zugriff darauf haben (oder starten Sie PHP-FPM neu).
Überprüfen Sie, ob die Bereitstellung erfolgreich hochgeladen wurde. alle WordPress-Dateien (insbesondere über manuelles SFTP).

Nachkorrekturprüfungen

Öffnen Sie einen bestehenden Artikel und erstellen Sie einen neuen: Beide Bildschirme sollten funktionieren.
Testen Sie mit einem Konto Administrator dann ein Konto Herausgeber (Die REST-Funktionen unterscheiden sich).
Konsole: Null Beim ersten Laden trat ein schwerwiegender Fehler auf. Es können einige Warnungen vorliegen, jedoch kein blockierender Fehler.
Netzwerk: Anfragen /wp-json/ Der Status muss 200 sein, und die Antwort muss im JSON-Format vorliegen.
Kurzer Test des Veröffentlichungsprozesses: Entwurf → veröffentlichen → aktualisieren.

Wenn Sie Elementor/Divi/Avada verwenden, öffnen Sie auch deren Bearbeitungsbildschirme: Ein „Admin“-Patch sollte das gesamte System verbessern, nicht nur Gutenberg.

Wenn das immer noch nicht funktioniert

Vorgehensweise, die ich anwende, wenn das Problem weiterhin besteht (in dieser Reihenfolge, um zu vermeiden, dass man sich im Kreis dreht).

1) Fehlerbehebungsmodus ohne Beeinträchtigung der Besucher

ermöglichen Gesundheitscheck und verwenden Sie die Fehlerbehebungsmodus.
Deaktivieren Sie in diesem Modus alle Plugins, das Theme bleibt aktiv.
Probieren Sie Gutenberg.

Wenn das funktioniert, reaktivieren Sie die Plugins nacheinander, bis Sie den Übeltäter gefunden haben (oft ein Sicherheits-, Cache-, Optimierungs- oder ein schlecht programmiertes Plugin für benutzerdefinierte Felder).

2) Überprüfen Sie die PHP-Protokolle und REST-Fehler.

geöffnet wp-content/debug.log direkt nach einem fehlgeschlagenen Ladevorgang.
Suchen nach: Fatal error, headers already sent, Deprecated (Einige veraltete Funktionen könnten die Ausgabe verfälschen, wenn sie angezeigt werden), REST.

Um die Fehler „Ungültiges JSON“ zu verstehen, finden Sie die offizielle Debugging-Dokumentation hier: Debuggen in WordPress.

3) Abfragemonitor: Überprüfung auf Fehler und AJAX-/REST-Anfragen

Der Query Monitor zeigt PHP-Fehler, Hooks und manchmal HTTP-Aufrufe an. Bei der Fehlersuche in Gutenberg verwende ich ihn hauptsächlich für Folgendes:

um eine Warnung zu identifizieren, die bei einer REST-Anfrage ausgelöst wird,
Identifizieren Sie das verantwortliche Plugin anhand des Stack-Traces.
Prüfen Sie, ob der Administrator unerwartete Skripte lädt.

4) Überprüfen Sie den Zustand der Website und die Serverkapazitäten.

PHP-Speicher Gutenberg, Builder und große Plugins können Probleme verursachen. Unzureichender Speicherplatz kann zu sporadischen Abstürzen führen.
Begrenztheit : max_input_vars Zu niedrige Werte können sich auf einige Bildschirmgrößen auswirken (seltener bei reinem Gutenberg, häufiger bei umfangreichen Metaboxen).
Berechtigungen Wenn die WP-Kerndateien nicht lesbar sind, erhalten Sie 404/500-Fehler bei den Assets.

5) Permalinks zurücksetzen (selten, aber schnell)

Wenn REST 404-Fehler zurückgibt, obwohl die Datei existiert, habe ich nach der Migration inkonsistente Rewrite-Regeln festgestellt.

Einstellungen → Permalinks → Speichern (ohne Änderungen).

6) Auf Snippet-Konflikte prüfen.

Snippet-Plugins (oder die functions.php) sind eine Hauptursache, denn ein einfacher Syntaxfehler kann alles durcheinanderbringen.

Achten Sie auf einen Fehler wie „fehlendes Semikolon“ oder Klammern.
Prüfen Sie, ob ein Code-Snippet ausgeführt wird auf init / wp_loaded und machte ein echo / var_dump.

7) WP-CLI: Integrität und Versionen prüfen.

Auf einer Website, bei der ich eine unvollständige Bereitstellung vermute, ist WP-CLI sehr effektiv:

# Vérifie l'intégrité des fichiers du core WordPress
wp core verify-checksums

# Liste plugins et mises à jour en attente
wp plugin list
wp plugin update --all

# Vérifie la version PHP (vue par WP-CLI)
php -v

WP-CLI-Dokumentation: WP-CLI-Befehle.

Häufige Fallstricke und Fehler

Symptom	Mögliche Ursache	Empfohlene Lösung
„Ungültige JSON-Antwort“ nach dem Hinzufügen eines Code-Snippets	`echo`/`var_dump` oder PHP-Warnung während REST	Löschen Sie die Ausgabe, verwenden Sie `error_log()`Warnungen korrigieren (Lösung 1)
Gutenberg wird nur in bestimmten Browsern geladen.	Browser-Cache/Service Worker oder Erweiterung	Testen Sie den privaten Browsermodus, deaktivieren Sie Erweiterungen und leeren Sie den Cache (Lösung 3).
JS-Fehler „wp ist nicht definiert“	Das Skript wurde zu früh oder auf dem falschen Bildschirm geladen.	Targeting `post.php`/`post-new.php` + Abhängigkeiten (Lösung 2)
403 auf `/wp-json/` nur in Produktion	WAF/CDN, ModSecurity-Regel, Basisauthentifizierung	REST/admin-ajax auf die Whitelist setzen, WAF-Protokolle umgehen (Lösung 1)
Es funktioniert nach Deaktivierung des Caches, dann tritt der Fehler wieder auf.	Reaktives Optimierungs-Plugin „minify admin“	Ausschließen `/wp-admin/` und WP-Bundles (Lösung 3)
Fehler nach WordPress-Update, JS-Dateien zeigen 404-Fehler an	Unvollständige Bereitstellung / Das CDN liefert die alte Version aus	CDN-Bereinigung + `wp core verify-checksums` (Lösung 3)
Der Code befindet sich zwar an der richtigen Stelle, funktioniert aber nicht.	In die falsche Datei kopiert (Plugin- vs. Child-Theme-Datei) oder ein unpassender Hook	Zum MU-Plugin hinzufügen, Hook und Priorität prüfen.
Es tritt nur bei der Rolle des Redakteurs auf.	REST/Nonce-Funktionen, Rollen-Plugin	Testen Sie REST-Routen mit dieser Rolle und den korrekten Fähigkeiten.

Fehler, die ich häufig bei fortgeschrittenen Nutzern beobachte:

Testen Sie direkt in der Produktionsumgebung ohne Backup und beheben Sie die Probleme anschließend umgehend.
Fügen Sie einen Code-Schnipsel aus einem alten Tutorial (vor Version 6.x) hinzu, der REST „aus Sicherheitsgründen“ blockiert.
Vergessen, den CDN-Cache nach einem WordPress-Update zu leeren.
Verwendung eines zu globalen Hooks (z.B. init) um HTML auszugeben oder JS zu laden.
Den Admin-Bereich minimieren/zusammenfassen, um 0,2 Sekunden zu sparen, und dabei den Editor entfernen.

Variante / Alternative

Methode ohne Code: Isolation mit Health Check + kontrolliertem Rollback

Health Check → Fehlerbehebungsmodus → Plugins nach Kategorie deaktivieren (Sicherheit/Caching/Optimierung).
Wenn der Übeltäter identifiziert ist, aktualisieren oder ersetzen Sie ihn.
Falls der Fehler durch ein kürzlich erfolgtes Update verursacht wurde, führen Sie ein temporäres Rollback (Plugin) durch und öffnen Sie anschließend ein Ticket beim Herausgeber.

Erweiterte Methode: MU-Plugin „safeguard“ zur Protokollierung von REST-Fehlern

Bei komplexen Websites (Avada + Elementor + Sicherheit + Cache) installiere ich manchmal ein temporäres MU-Plugin, um REST-Fehler zu protokollieren, ohne den Produktivbetrieb zu beeinträchtigen.

<?php
/**
 * Plugin Name: MU - Debug REST pour éditeur de blocs
 * Description: Journalise les erreurs REST (temporaire) pour diagnostiquer Gutenberg.
 * Author: Votre équipe
 * Version: 1.0.0
 *
 * À placer dans wp-content/mu-plugins/mu-debug-rest.php
 */

add_filter( 'rest_request_after_callbacks', function( $response, $handler, $request ) {

	// Ne loguez que si WP_DEBUG est actif pour éviter du bruit en prod.
	if ( ! defined( 'WP_DEBUG' ) || ! WP_DEBUG ) {
		return $response;
	}

	if ( is_wp_error( $response ) ) {
		error_log( '[REST][WP_Error] route=' . $request->get_route() . ' code=' . $response->get_error_code() . ' message=' . $response->get_error_message() );
		return $response;
	}

	if ( $response instanceof WP_REST_Response ) {
		$status = $response->get_status();
		if ( $status >= 400 ) {
			error_log( '[REST][HTTP ' . $status . '] route=' . $request->get_route() );
		}
	}

	return $response;
}, 10, 3 );

Diese Schutzmaßnahme hilft dabei, einen fehlerhaften Gutenberg-Bildschirm mit einer präzisen REST-Route zu korrelieren.

Vermeiden Sie dieses Problem in Zukunft

REST darf nicht global blockiert werden.Wenn Sie die Sicherheit erhöhen, tun Sie dies über Routen, Rollen und Kontexte. Testen Sie den Administrator nach jeder Änderung.
Optimieren Sie nicht die Administration (Minimieren/Kombinieren/Verschieben) außer in streng kontrollierten Fällen. Der Nutzen ist minimal, die Risiken enorm.
Laden Sie Ihre Admin-Skripte ordnungsgemäß. :
- Bildschirmausrichtung ($hook_suffix + get_current_screen()),
- Abhängigkeiten wp-* erklärt,
- zuverlässige Versionierung (filemtime in einer einfachen Umgebung).
PHP-Warnungen überwachen In PHP 8.1 und höher lösen bestimmte Muster vermehrt Warnungen/Hinweise auf veraltete Funktionen aus. Eine angezeigte Warnung kann JSON-Konvertierungen beschädigen.
Aktualisierungsprozess : Staging → Cache leeren → Produktion. Und nach einem WordPress-Update systematisches CDN-Leeren.
Sicherheitsheader : CSP bereitstellen in Nur Bericht Zuerst sollten Sie die Einstellungen schrittweise anpassen. Andernfalls riskieren Sie, die Administration durch das nächste Plugin, das einen iFrame oder einen Blob hinzufügt, zu beeinträchtigen.

Nützliche PHP-Referenzen: PHP-Fehlerbehandlungskonfiguration.

Ressourcen

Häufig gestellte Fragen

Warum zeigt Gutenberg die Meldung „Die Antwort ist keine gültige JSON-Antwort“ an?

Da die REST-Anfrage JSON erwartet, aber etwas anderes liefert (403/500-Fehler, HTML-Warnung, unerwünschte Ausgabe), öffnen Sie die Antwort im Netzwerk-Tab: Dort ist die Ursache oft sofort ersichtlich.

Ist das Deaktivieren der REST-API „aus Sicherheitsgründen“ eine gute Vorgehensweise?

Nein, nicht global. WordPress (und Gutenberg) verwenden es intern. Wenn Sie es absichern, tun Sie dies schrittweise und unter Beibehaltung der Funktionalität des Administrationsbereichs. Testen Sie systematisch. /wp-json/wp/v2/types/post?context=edit in Verbindung gebracht.

Warum funktioniert es für einen Administrator, aber nicht für einen Redakteur?

Die Funktionen unterscheiden sich, und einige Rollen-/Sicherheits-Plugins filtern REST-Anfragen rollenbasiert. Testen Sie mit dem entsprechenden Konto und prüfen Sie, ob REST-Routen im Kontext auf 403-Fehler stoßen. edit.

Kann ein Caching-Plugin Gutenberg beschädigen?

Ja, insbesondere wenn es authentifizierte REST-Endpunkte zwischenspeichert oder Administratorskripte optimiert/minimiert. Ausschließen /wp-admin/ et /wp-json/ aggressive Caching-Regeln.

Was soll ich tun, wenn ich auf einer REST-Route nur einen 500-Fehler erhalte?

Dies ist fast immer ein schwerwiegender PHP-Aufruf, der während dieser Anfrage ausgelöst wird. Aktivieren WP_DEBUG_LOGreproduzieren, dann ansehen debug.logQuery Monitor hilft dabei, das verantwortliche Plugin/Theme zu identifizieren.

Sind Divi 5 / Elementor / Avada mit Gutenberg kompatibel?

Ja, aber sie fügen Skripte und Leistungsoptionen hinzu. Konflikte entstehen hauptsächlich durch Administratoroptimierungen, Minifizierung oder übermäßig strenge Sicherheitsregeln. Falls Gutenberg nicht funktioniert, testen Sie auch den Builder-Editor: Die Ursache ist oft dieselbe.

Würde „Permalinks erneut speichern“ helfen?

Wenn REST nach einer Migration oder einem Serverwechsel 404-Fehler zurückgibt, ist dies zwar nicht immer die erste Maßnahme, die man ergreifen sollte, aber sie ist schnell und risikofrei.

Kann ich Gutenberg "reparieren", indem ich jQuery neu lade oder benutzerdefiniertes JavaScript hinzufüge?

Dies ist meist nur eine Notlösung, die das eigentliche Problem (defekter REST-Server, Skriptkonflikte) verschleiert. Beheben Sie die Ursache: REST-Blockierung, fehlerhaftes Enqueueing, Cache-/CDN-Probleme oder schwerwiegender PHP-Fehler.

Welche Dateien sollte ich überprüfen, wenn Gutenberg-Assets einen 404-Fehler zurückgeben?

Schau dir die URLs an wp-includes/js/dist/ et wp-includes/css/dist/Ein 404-Fehler kann auf eine unvollständige Bereitstellung oder ein CDN hinweisen, das eine ältere Version ausliefert. wp core verify-checksums Das hilft sehr.

Ich erhalte die Meldung „Laden verweigert… verstößt gegen die Content-Security-Policy“. Was soll ich tun?

Lockern Sie die CSP für den Administrator, idealerweise durch Nur Bericht Prüfen Sie zunächst die Richtlinien. script-src, style-src, connect-srcund die Genehmigung von blob:/data: Falls erforderlich. Führen Sie dies schrittweise durch, um das Risiko von XSS zu minimieren.

Gutenberg hängt: WordPress-Blockeditor reparieren

das Problem

Kurze Zusammenfassung

Symptome

Schnelldiagnosetabelle

Warum passiert das

Voraussetzungen vor Beginn

Lösung 1: Die REST-API ist blockiert (403/401/500) und Gutenberg kann nicht mehr gestartet werden.

Diagnostisch

Häufiger Fall: Ein Plugin blockiert REST durch einen zu strengen Filter.

VORDERSEITE (defekt)

NACH (korrigierte, gezielte Einschränkung)

Häufiger Fall: „Ungültige JSON-Antwort“ aufgrund einer PHP-Warnung

VORDERSEITE (defekt)

NACH (korrigiert)

Häufiger Fall: WAF/CDN-Blockierung (403, Challenge, Basic Auth)

Lösung 2: Fehlerhafte Editor-Skripte (Einreihen, Abhängigkeiten, Ladefolge)

Diagnostisch

Typischer Fall: globale Umfrage zu admin_enqueue_scripts ohne den Bildschirm anzuvisieren

VORDERSEITE (defekt)

NACHHER (korrigiert: Targeting + Abhängigkeiten + Versionierung)

Häufiger Fall: Ein Plugin lädt React/ReactDOM manuell.

VORDERSEITE (defekt)

NACHHER (korrigiert: WordPress-Pakete verwenden)

Divi 5 / Elementor / Avada-Kompatibilität

Lösung 3: Caching, Sicherheit und CSP (Content-Security-Policy), die die Administration beeinträchtigen

Häufiger Fall: Optimierung, die die Administrationsdatei minimiert/verkettet

Häufiger Fall: Übermäßig strenger sozioökonomischer Status

Häufiger Fall: Assets einer älteren Version, die über CDN/opcache bereitgestellt werden

Nachkorrekturprüfungen

Wenn das immer noch nicht funktioniert

1) Fehlerbehebungsmodus ohne Beeinträchtigung der Besucher

2) Überprüfen Sie die PHP-Protokolle und REST-Fehler.

3) Abfragemonitor: Überprüfung auf Fehler und AJAX-/REST-Anfragen

4) Überprüfen Sie den Zustand der Website und die Serverkapazitäten.

5) Permalinks zurücksetzen (selten, aber schnell)

6) Auf Snippet-Konflikte prüfen.

7) WP-CLI: Integrität und Versionen prüfen.

Häufige Fallstricke und Fehler

Variante / Alternative

Methode ohne Code: Isolation mit Health Check + kontrolliertem Rollback

Erweiterte Methode: MU-Plugin „safeguard“ zur Protokollierung von REST-Fehlern

Vermeiden Sie dieses Problem in Zukunft

Ressourcen

Häufig gestellte Fragen

Warum zeigt Gutenberg die Meldung „Die Antwort ist keine gültige JSON-Antwort“ an?

Ist das Deaktivieren der REST-API „aus Sicherheitsgründen“ eine gute Vorgehensweise?

Warum funktioniert es für einen Administrator, aber nicht für einen Redakteur?

Kann ein Caching-Plugin Gutenberg beschädigen?

Was soll ich tun, wenn ich auf einer REST-Route nur einen 500-Fehler erhalte?

Sind Divi 5 / Elementor / Avada mit Gutenberg kompatibel?

Würde „Permalinks erneut speichern“ helfen?

Kann ich Gutenberg "reparieren", indem ich jQuery neu lade oder benutzerdefiniertes JavaScript hinzufüge?

Welche Dateien sollte ich überprüfen, wenn Gutenberg-Assets einen 404-Fehler zurückgeben?

Ich erhalte die Meldung „Laden verweigert… verstößt gegen die Content-Security-Policy“. Was soll ich tun?

In Verbindung stehende Artikel

Senden Sie einen Kommentar Annuler la réponse

Typischer Fall: globale Umfrage zu `admin_enqueue_scripts` ohne den Bildschirm anzuvisieren