WordPress 7.1: Beitragseditor immer im iframe

#Der Weg zum erzwungenen iframe

Der iframe ist nicht neu. Neu ist, dass die Bedingungen weggefallen sind, unter denen er bisher griff.

Die Regel aus 6.3 erklärt den größten Teil der Verwirrung, die in der Praxis herrscht. Ein einziger registrierter Block mit apiVersion 2 irgendwo auf der Installation schaltete den gesamten Editor zurück auf den Pfad ohne iframe. Ein Plugin konnte also im iframe gründlich kaputt sein, ohne dass es jemals jemand bemerkte, solange ein einziger Altblock auf derselben Installation dafür sorgte, dass der iframe nie zum Einsatz kam. Die Bedingung hat über Jahre Fehlermeldungen unterdrückt, die längst hätten geschrieben werden müssen.

Der Site-Editor lief unterdessen immer im iframe. Das ist der Grund, warum sich dasselbe Plugin je nach Bildschirm unterschiedlich verhält und warum Redaktionen im Support gern berichten, dass “es im Design-Bereich anders aussieht als im Beitrag”.

#Was der iframe technisch bedeutet

Warum das überhaupt Folgen hat, steht in einem Satz derselben Dev Note: “the iframe has its own document and window, separate from the admin page where editor scripts run.”

Die edit-Komponente Ihres Blocks wird weiterhin von React aus der äußeren Admin-Seite gerendert, aber die DOM-Knoten, die dabei entstehen, leben im iframe. Komponente und erzeugtes Markup teilen sich also kein document mehr. Ein Aufruf von document.querySelector() aus einem Block heraus läuft gegen post.php und nicht gegen das Canvas. Er wirft keinen Fehler. Er liefert null zurück, oder schlimmer, er liefert irgendeinen fremden Knoten aus der Editor-Oberfläche, und Ihr Code arbeitet auf einer falschen Grundlage weiter.

An React ändert sich nichts, an block.json ändert sich nichts. Was sich ändert: eine ganze Klasse von Annahmen, die bisher meistens zutraf, ist ab jetzt immer falsch. Genau diese Sorte Änderung fällt in der Entwicklung durch und wird auf Produktivseiten teuer.

#Warum es keinen Schalter zum Abschalten gibt

Die Begründung in Gutenberg PR #74042, gemergt am 10. Juli 2026, lohnt sich in voller Länge, der entscheidende Satz lautet aber: “far more breakage is caused by the inconsistency than blocks not functioning well with iframe.”

Das ist eine vertretbare technische Entscheidung. Zwei Renderumgebungen mit einer Umschaltung zur Laufzeit sind ein schlechterer Vertrag als eine einzige Umgebung, die sich gelegentlich sperrig anstellt. Es heißt aber auch, dass die Notausgänge zu sind: Der Pull Request entfernt den Pfad ohne iframe, und ein Reviewer hält fest, switchToLegacyCanvas() “does nothing anymore”. Wer eingeplant hatte, sich mit einem Filter noch einen Release-Zyklus Zeit zu kaufen, findet keinen Filter mehr vor.

Der Gegendruck ist real und er ist dokumentiert. Im Tracking-Issue #70743 schreibt der leitende Entwickler von Meta Box: “Switching to version 3 is impossible at the moment, as most of the JS the plugins use are using jQuery with DOM manipulation.” Das ist nicht das Problem eines einzelnen Plugins. Es beschreibt einen großen Teil des kommerziellen Ökosystems rund um Metaboxen und eigene Felder, und darauf stehen im deutschsprachigen Agenturgeschäft sehr viele Kundenseiten.

#Die Fehlerbilder und die passenden Korrekturen

Die Referenz ist die Handbuchseite zur Blockmigration für iframe-Kompatibilität. So sehen die Korrekturen in der Praxis aus.

#Zugriffe auf das globale document

Das ist der Fall, der keine Fehler liefert, sondern stillschweigend falsche Antworten. Gutenberg Issue #55947 ist ein sauberes Beispiel: Ein über enqueue_block_editor_assets eingebundenes Skript liest document.body.classList aus und bekommt das äußere post.php-Dokument, die geprüfte Klasse ist dort nie vorhanden.

Vorher:

import { useEffect } from '@wordpress/element';

export default function Edit( { attributes } ) {
	useEffect( () => {
		// `document` is the admin page. This finds nothing in 7.1.
		const heading = document.querySelector( '.wp-block-my-plugin-hero h2' );
		if ( heading && document.body.classList.contains( 'is-dark-theme' ) ) {
			heading.dataset.contrast = 'inverted';
		}
	}, [ attributes.style ] );

	return <div className="wp-block-my-plugin-hero">{ /* ... */ }</div>;
}

Nachher:

import { useRefEffect } from '@wordpress/compose';

export default function Edit( { attributes } ) {
	const ref = useRefEffect(
		( element ) => {
			// Resolve the canvas from a node that is already inside it.
			const canvas = element.ownerDocument;
			const heading = element.querySelector( 'h2' );
			if ( heading && canvas.body.classList.contains( 'is-dark-theme' ) ) {
				heading.dataset.contrast = 'inverted';
			}
		},
		[ attributes.style ]
	);

	return <div ref={ ref } className="wp-block-my-plugin-hero">{ /* ... */ }</div>;
}

Zwei Dinge haben sich geändert. element.ownerDocument liefert das Dokument, das den Knoten tatsächlich enthält, welches auch immer das gerade ist. Derselbe Code funktioniert damit im Beitragseditor, im Site-Editor und auf jeder künftigen Oberfläche. Und die Suche nach der Überschrift ist jetzt auf das eigene Element des Blocks begrenzt statt auf ein ganzes Dokument, was ohnehin die sauberere Variante war.

#Werte und Listener am falschen window

Alles, was an window gemessen wird, hat dasselbe Problem, und es ist gefährlicher, weil window.innerWidth eine plausible Zahl zurückgibt. Es ist nur die falsche Zahl: der Browser-Viewport und nicht das Canvas. In einem geteilten Editor mit geöffneter Seitenleiste liegen dazwischen mehrere hundert Pixel, und genau daran scheitern responsive Vorschauen in Blocks.

Vorher:

import { useState, useEffect } from '@wordpress/element';

export default function Edit() {
	const [ width, setWidth ] = useState( 0 );

	useEffect( () => {
		const onResize = () => setWidth( window.innerWidth );
		onResize();
		window.addEventListener( 'resize', onResize );
		return () => window.removeEventListener( 'resize', onResize );
	}, [] );

	return <div>{ width }</div>;
}

Nachher:

import { useState } from '@wordpress/element';
import { useRefEffect } from '@wordpress/compose';

export default function Edit() {
	const [ width, setWidth ] = useState( 0 );

	const ref = useRefEffect( ( element ) => {
		const view = element.ownerDocument.defaultView;
		const onResize = () => setWidth( view.innerWidth );
		onResize();
		view.addEventListener( 'resize', onResize );
		return () => view.removeEventListener( 'resize', onResize );
	}, [] );

	return <div ref={ ref }>{ width }</div>;
}

element.ownerDocument.defaultView ist das window, das zum Canvas gehört. Binden Sie Listener darüber, und binden Sie sie aus einem Ref-Callback heraus statt aus einem Effekt, der nicht weiß, gegen welches Dokument er gerade läuft.

Der Wechsel von useRef plus useEffect zu useRefEffect ist keine Kosmetik. Der useEffect-Callback wird nicht erneut aufgerufen, wenn sich das Ref ändert, und im gekapselten Editor ändert es sich: Der Canvas-Knoten wird über eine Bearbeitungssitzung hinweg erzeugt, ersetzt und wieder abgebaut. Ein Effekt, der einmal gegen einen längst verschwundenen Knoten lief, ist der direkte Weg zu Listenern auf einem toten Dokument und zu Aufräumlogik, die nie ausgeführt wird. Gutenberg PR #52588 macht den Abbaufall greifbar, dort wird beim Verschwinden des iframe ein Cannot read properties of null (reading 'getComputedStyle') geworfen.

#jQuery, select2 und alles, was nach einem Global greift

Das ist die Kategorie, die der Meta-Box-Kommentar beschreibt, und dort sitzt der Großteil des Codes, den Agenturen pflegen. Issue #47924 hält fest, dass select2 aus ACF und der jQuery-UI-Datepicker im iframe brechen.

Vorher:

import { useEffect } from '@wordpress/element';

export default function Edit( { clientId } ) {
	useEffect( () => {
		jQuery( `#my-plugin-select-${ clientId }` ).select2( { width: '100%' } );
	}, [ clientId ] );

	return <select id={ `my-plugin-select-${ clientId }` }>{ /* ... */ }</select>;
}

Nachher:

import { useRefEffect } from '@wordpress/compose';

export default function Edit() {
	const ref = useRefEffect( ( element ) => {
		const $ = element.ownerDocument.defaultView.jQuery;
		if ( ! $ ) {
			return;
		}
		const $select = $( element );
		$select.select2( { width: '100%' } );
		return () => {
			$select.select2( 'destroy' );
		};
	}, [] );

	return <select ref={ ref }>{ /* ... */ }</select>;
}

Drei Änderungen tragen die Korrektur. Die Bibliothek wird aus dem Canvas-window aufgelöst statt aus einem Global, das ist das Muster defaultView.jQuery(element). Das Element wird direkt übergeben, statt es über einen ID-Selektor zu suchen, damit entfällt die dokumentübergreifende Suche vollständig. Und die zurückgegebene Aufräumfunktion zerstört das Widget, sobald der Knoten verschwindet. Diesen dritten Teil lässt bestehender Code fast immer weg, weil der Knoten vor dem iframe praktisch nie verschwand.

Ist jQuery auf dem Canvas-window gar nicht vorhanden, liegt kein JavaScript-Problem vor, sondern ein Einbindungsproblem. Damit sind wir bei der letzten Kategorie.

#Styles und Skripte an der falschen Oberfläche

Die Regel aus der Handbuchseite zum Einbinden von Assets im Editor ist eine saubere Trennung. enqueue_block_editor_assets ist für die Editor-Oberfläche zuständig: Seitenleisten, Werkzeugleisten, Plugin-Panels, Format-Buttons. enqueue_block_assets ist für Inhalte zuständig und erreicht sowohl das Canvas als auch das Frontend.

Vorher:

add_action( 'enqueue_block_editor_assets', function () {
	wp_enqueue_style(
		'my-plugin-blocks-editor',
		plugins_url( 'build/blocks.css', __FILE__ ),
		array(),
		'1.4.0'
	);
} );

Nachher:

// Editor interface only: panels, toolbars, sidebar controls.
add_action( 'enqueue_block_editor_assets', function () {
	wp_enqueue_style(
		'my-plugin-blocks-panels',
		plugins_url( 'build/panels.css', __FILE__ ),
		array(),
		'1.4.0'
	);
} );

// Content: applies inside the canvas and on the front end.
add_action( 'enqueue_block_assets', function () {
	wp_enqueue_style(
		'my-plugin-blocks-content',
		plugins_url( 'build/blocks.css', __FILE__ ),
		array(),
		'1.4.0'
	);
} );

Ein Fehler an dieser Stelle erzeugt überhaupt keine Meldung. Das Stylesheet lädt, der Browser meldet 200, und die Regeln greifen im Canvas auf nichts, weil sie in ein anderes Dokument injiziert wurden. Gutenberg Issue #53236 dokumentiert genau das: Ein für den Editor eingebundenes Stylesheet wirkt im Canvas stillschweigend nicht mehr.

Für Skripte gilt dieselbe Trennung. Was gegen Inhaltsknoten laufen muss, muss dort geladen werden, wo diese Knoten leben.

#Der Test in zehn Minuten

Für die Frage, ob Sie überhaupt betroffen sind, brauchen Sie keine vollständige Prüfung. Sie brauchen eine Installation. Und Sie brauchen dafür nicht einmal einen Release Candidate, denn dieselbe Dev Note hält fest: “since Gutenberg 22.6, when the plugin is active the post editor is forced to be iframed regardless of the theme type or the block API versions in use”. Auf Deutsch: Seit Version 22.6 erzwingt allein das aktive Gutenberg-Plugin den gekapselten Beitragseditor, unabhängig vom Theme-Typ und von den verwendeten Block-API-Versionen.

1. Installieren Sie das Gutenberg-Plugin in Version 22.6 oder neuer auf einer Staging-Umgebung. Damit haben Sie das Verhalten von 7.1 sofort auf dem heutigen Core. Als Alternative bleibt eine Wegwerf-Installation mit WordPress 7.1 RC, ein lokaler Container genügt dafür.
2. Aktivieren Sie ein Plugin, das einen Block mit apiVersion 2 registriert. Ein Altblock aus dem eigenen Katalog reicht, einer von einer Kundenseite ebenso.
3. Öffnen Sie den Beitragseditor und fügen Sie den Block ein.
4. Öffnen Sie die Browser-Konsole und lassen Sie sie offen, während Sie mit dem Block arbeiten: hineinschreiben, eine Einstellung in der Seitenleiste ändern, zu einem anderen Block und zurück wechseln, dann den Block löschen.
5. Lesen Sie, was dabei herauskommt. Zugriffe auf Eigenschaften von null beim Abbau, Selektoren, die null liefern, fehlende Styles im Canvas, die im Frontend korrekt erscheinen.

Zwei Hinweise zur Auswertung. Schalten Sie SCRIPT_DEBUG ein, denn die in 6.9 ergänzten apiVersion-Warnungen erscheinen nur damit. Und prüfen Sie die Darstellung mit den Augen, nicht nur die Konsole, weil die oben beschriebene Fehlleitung von Assets vollkommen geräuschlos abläuft.

Zehn Minuten liefern ein Ja oder Nein pro Plugin. Das genügt, um den tatsächlichen Aufwand abzuschätzen.

#Klassische Metaboxen halten den Editor nicht mehr aus dem iframe

Eine Installation, die klassische Metaboxen registriert, gehörte bislang zu den Fällen, in denen der Beitragseditor ungekapselt blieb. In 7.1 gilt das nicht mehr. Der Field Guide zu 7.1 vom 5. August 2026 formuliert es knapp: “WordPress 7.1 completes the move to an iframe-based post editor, including for sites that register legacy meta boxes.” Auf Deutsch: Der Umzug in den iframe schließt ausdrücklich Seiten ein, die alte Metaboxen registrieren.

Das ist für Agenturen die unangenehmere Hälfte der Umstellung, weil sie nicht die eigenen Blocks trifft, sondern den Bestand: eigene Metaboxen aus dem Child-Theme, klassisch gerenderte ACF-Feldgruppen, zusätzliche Panels aus Shop- und Branchen-Plugins. Diese Bildschirme liefen jahrelang ohne iframe und wurden deshalb nie darin geprüft. Sie brauchen jetzt einen eigenen Durchgang.

#Was eine Agentur im Kundenbestand prüfen sollte

Wer Seiten betreut, die er nicht selbst gebaut hat, steht vor einer anderen Frage als “ist unser Code bereit”. Die eigentliche Frage lautet: Welcher Code auf diesen Installationen ist inzwischen niemandes Zuständigkeit mehr? Diese Inventur ist Entwicklungsarbeit, und sie gehört erledigt, bevor eine Redaktion anruft, weil das Layout im Editor verrutscht.

• Blockinventar aufbauen. Pro Seite festhalten, welche Plugins und Themes Blocks registrieren und welche apiVersion jeder Block deklariert. Das Hochsetzen der Zahl repariert in 7.1 kein Verhalten, aber die Anzahl der Version-2-Blocks zeigt, wo Sie zuerst hinsehen.
• Gepflegt von aufgegeben trennen. Für jedes betroffene Plugin das Datum der letzten Veröffentlichung prüfen und ob sich der Entwickler zur iframe-Kompatibilität geäußert hat. Bei einem gepflegten Plugin warten und testen Sie. Bei einem aufgegebenen entscheiden Sie zwischen lokalem Patch, Fork und Ersatz, und diese Entscheidung hat eine Vorlaufzeit.
• Den eigenen Code durchsuchen. Jedes eigene Plugin und Theme im Bestand nach document. und window. in Editor-Bundles durchsuchen, dazu nach jQuery( und nach jedem enqueue_block_editor_assets-Handler, der Inhalts-Styles registriert. Ein schneller, mechanischer Durchlauf mit konkretem Ergebnis.
• Die Metabox-Ebene gesondert ansehen. ACF, Meta Box und vergleichbare Werkzeuge stehen im höchsten Risiko, und sie stehen meist auf genau den Seiten, auf denen Redaktionen Störungen als Erstes bemerken.
• Einen zweiten Durchgang über die Metaboxen-Bildschirme legen. Nach dem Blocktest dieselbe Installation erneut öffnen, diesmal jeden Inhaltstyp mit klassischen Metaboxen: Felder ausfüllen, speichern, neu laden und prüfen, ob die Werte zurückkommen. Ein eigener Durchlauf, weil genau diese Bildschirme bis 7.1 ohne iframe liefen.
• Den Redaktionsablauf testen, nicht nur den Seitenaufruf. Die Fehler beim Abbau zeigen sich erst, wenn Blocks eingefügt, verschoben und gelöscht werden. Ein Rauchtest, der einen Beitrag öffnet und ihn ansieht, läuft auch auf einer kaputten Installation grün durch.
• Nach redaktioneller Last priorisieren. Eine Seite, deren Team täglich publiziert, muss vor dem 19. August sauber sein. Eine Imageseite, die zweimal im Jahr bearbeitet wird, muss das nicht.

Nichts daran ist exotisch. Es sind eine Inventur, ein grep und eine Testmatrix, und so etwas gehört in einen geplanten Turnus statt in einen Notfall. Wenn Sie das dauerhaft abgeben möchten, ist es Teil eines Programms zur WordPress-Wartung, in dem Tests zu Core-Releases ohnehin im Kalender stehen.

#Quellen

• Aki Hamano, Iframed Editor Changes in WordPress 7.1, 3. August 2026
• WordPress 7.1 Field Guide, 5. August 2026
• Ella Van Durpe, Iframed Editor Changes in WordPress 7.0, 24. Februar 2026
• Aki Hamano, Preparing the Post Editor for Full iframe Integration, 12. November 2025
• Block migration for iframe editor compatibility, Block Editor Handbook
• Enqueueing assets in the editor, Block Editor Handbook
• Gutenberg PR #74042, “Post editor: always iframe”, gemergt am 10. Juli 2026
• Gutenberg Tracking-Issue #70743, sowie die Issues #55947, #47924, #53236 und PR #52588