WordPress 7.1: innleggseditoren alltid i iframe

#Hva iframen betyr teknisk

Hele konsekvensen står i én setning i den samme dev-noten: “the iframe has its own document and window, separate from the admin page where editor scripts run.” Iframen har med andre ord sitt eget dokument og sitt eget vindu, atskilt fra admin-siden der editorskriptene kjører.

edit-komponenten i blokken din rendres fortsatt av React fra den ytre admin-siden, men DOM-nodene den produserer, bor inne i iframen. Komponenten og markupen den eier, deler dermed ikke lenger document. Et kall til document.querySelector() fra innsiden av en blokk kjører mot post.php, ikke mot lerretet. Det kaster ingen feil. Det returnerer null, eller verre, det returnerer en tilfeldig node fra editorgrensesnittet, og koden din jobber videre på et feilaktig grunnlag.

Ingenting endres i React. Ingenting endres i block.json. Det som endres, er at en hel klasse av antakelser som pleide å stemme mesteparten av tiden, nå er feil hele tiden. Slike endringer glipper gjennom utviklingen og blir dyre i produksjon.

#Feilbildene og rettelsene

Referansen er håndbokssiden om blokkmigrering for iframe-kompatibilitet. Slik ser rettelsene ut i praksis.

#Oppslag mot globale document

Dette er tilfellet som gir stille gale svar i stedet for feilmeldinger. Gutenberg-sak #55947 er et rent eksempel: et skript lastet inn via enqueue_block_editor_assets leser document.body.classList og får det ytre post.php-dokumentet, så klassen det ser etter, er aldri der.

Før:

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>;
}

Etter:

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>;
}

To ting er endret. element.ownerDocument gir dokumentet som faktisk inneholder noden, uansett hvilket dokument det viser seg å være, så den samme koden virker i innleggseditoren, i nettstedseditoren og på enhver framtidig flate. Og oppslaget etter overskriften er nå begrenset til blokkens eget element i stedet for å lete gjennom et helt dokument, noe som uansett alltid var den riktigere framgangsmåten.

#Verdier og lyttere knyttet til feil window

Alt som måles av window, har det samme problemet, og det er farligere, fordi window.innerWidth returnerer et helt troverdig tall. Det er bare feil tall: nettleserens visningsområde, ikke lerretet. I en delt editor med innstillingspanelet åpent kan avstanden være flere hundre piksler, og det er nettopp der responsive forhåndsvisninger inne i blokker begynner å lyve.

Før:

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>;
}

Etter:

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 er det window som hører til lerretet. Bind lyttere gjennom det, og bind dem fra en ref-callback i stedet for fra en effekt som ikke aner hvilket dokument den kjører mot.

Overgangen fra useRef pluss useEffect til useRefEffect er ikke kosmetikk. Callbacken i useEffect kalles ikke på nytt når referansen endrer seg, og i en editor som ligger i iframe, endrer den seg: lerretsnoden opprettes, byttes ut og rives ned gjennom en redigeringsøkt. En effekt som kjørte én gang mot en node som ikke finnes lenger, er den korteste veien til lyttere på et dødt dokument og opprydding som aldri blir utført. Gutenberg PR #52588 gjør nedrivingstilfellet konkret, med en Cannot read properties of null (reading 'getComputedStyle') som kastes idet iframen forsvinner.

#jQuery, select2 og alt som griper etter noe globalt

Dette er kategorien Meta Box-kommentaren beskriver, og det er her mesteparten av koden byråene faktisk vedlikeholder, befinner seg. Sak #47924 dokumenterer at select2 fra ACF og datovelgeren i jQuery UI ryker inne i iframen.

Før:

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>;
}

Etter:

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>;
}

Tre endringer bærer rettelsen. Biblioteket hentes fra lerretets window i stedet for fra noe globalt, altså mønsteret defaultView.jQuery(element). Elementet sendes inn direkte i stedet for å bli funnet med en ID-selektor, slik at oppslag på tvers av dokumenter forsvinner helt. Og oppryddingsfunksjonen som returneres, river ned widgeten når noden forsvinner. Akkurat den tredje delen utelater eksisterende kode nesten alltid, rett og slett fordi noden i praksis aldri forsvant før iframen kom.

Er jQuery ikke til stede på lerretets window i det hele tatt, er det ikke et JavaScript-problem, men et innlastingsproblem. Dermed er vi ved den siste kategorien.

#Stiler og skript lastet inn på feil flate

Regelen fra håndbokssiden om innlasting av assets i editoren er et rent skille. enqueue_block_editor_assets gjelder editorgrensesnittet: sidepaneler, verktøylinjer, plugin-paneler, formatknapper. enqueue_block_assets gjelder innhold, og den når både lerretet og frontsiden.

Før:

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

Etter:

// 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'
	);
} );

Tar du feil her, får du ingen feilmelding overhodet. Stilarket lastes, nettleseren rapporterer 200, og reglene treffer ingenting i lerretet fordi de ble injisert i et annet dokument. Gutenberg-sak #53236 sporer nøyaktig det: et stilark lastet inn for editoren slutter lydløst å virke på lerretet.

Det samme skillet gjelder skript. Alt som skal kjøre mot innholdsnoder, må lastes der de nodene bor.

#Slik tester du på ti minutter

Du trenger ingen fullstendig gjennomgang for å finne ut om du har et problem, og du trenger heller ingen release candidate. Den samme dev-noten peker på en raskere vei: “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.” Er Gutenberg-pluginen aktiv fra og med versjon 22.6, tvinges innleggseditoren altså inn i iframe uansett tematype og uansett hvilke block-API-versjoner som er i bruk. Én plugin på et staging-miljø setter dermed nettstedet i 7.1-tilstand i dag, på den kjerneversjonen det allerede kjører.

1. Aktiver Gutenberg-pluginen i versjon 22.6 eller nyere på en staging-kopi av nettstedet. Vil du heller teste selve kjernen, gir et engangsnettsted på WordPress 7.1 RC samme svar, og en lokal container holder uansett hvilken vei du velger.
2. Aktiver én plugin som registrerer en blokk med apiVersion 2. En gammel blokk fra din egen katalog duger, det samme gjør en fra et kundenettsted.
3. Åpne innleggseditoren og sett inn blokken.
4. Åpne konsollen i nettleseren og la den stå åpen mens du jobber med blokken: skriv i den, endre en innstilling i sidepanelet, bytt til en annen blokk og tilbake, og slett den til slutt.
5. Les det du får. Oppslag mot egenskaper på null under nedriving, selektorer som returnerer null, manglende stiler i lerretet som ser riktige ut på frontsiden.

To merknader til hvordan du leser resultatet. Slå på SCRIPT_DEBUG, for apiVersion-advarslene som kom i 6.9, vises bare med den påslått. Og kontroller stilene visuelt, ikke bare i konsollen, siden feilrutingen av assets beskrevet over er helt lydløs.

Ti minutter gir deg et ja eller nei per plugin. Det er nok til å måle det egentlige arbeidet.

#Hvordan editoren havnet her

Iframen er ikke ny. Det nye er at betingelsene er borte.

Regelen fra 6.3 forklarer det meste av forvirringen ute i felten. Fordi én eneste registrert blokk med apiVersion 2 hvor som helst på installasjonen slo hele editoren tilbake til stien uten iframe, kunne en plugin være grundig ødelagt inne i en iframe uten at noen noen gang så det, så lenge én gammel blokk på samme installasjon sørget for at iframen aldri ble tatt i bruk. Betingelsen gjorde jobben til en feilrapport-demper i årevis.

Nettstedseditoren har på sin side alltid kjørt i iframe. Det er derfor den samme pluginen ofte oppfører seg forskjellig avhengig av hvilken skjerm en redaktør tilfeldigvis står på, og hvorfor supporthenvendelsen ofte lyder at det ser annerledes ut i designdelen enn i innlegget.

#Hvorfor det ikke finnes noen av-bryter

Begrunnelsen i Gutenberg PR #74042, flettet inn 10. juli 2026, er verdt å lese i sin helhet, men den avgjørende linjen er: “far more breakage is caused by the inconsistency than blocks not functioning well with iframe.” Det er selve inkonsekvensen som skaper mest ødeleggelse, mer enn blokker som ikke fungerer godt i iframe.

Det er en forsvarlig teknisk avgjørelse. To rendringsmiljøer med en bryter mellom seg i kjøretid er en dårligere kontrakt enn ett miljø som av og til er ubehagelig. Det betyr samtidig at nødutgangene er stengt: pull requesten fjerner stien uten iframe, og en av dem som gikk gjennom den, noterer at switchToLegacyCanvas() “does nothing anymore”, altså at funksjonen ikke gjør noe lenger. Hadde du tenkt å kjøpe deg en utgivelsessyklus med et filter, finnes det ikke noe filter å ta i.

Motpresset er reelt, og det er dokumentert. I sporingssaken #70743 skriver hovedutvikleren bak 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.” Å bytte til versjon 3 er med andre ord umulig i dag, fordi mesteparten av JavaScriptet i disse pluginene bruker jQuery til DOM-manipulasjon. Dette er ikke problemet til én enkelt plugin. Det beskriver en stor del av det kommersielle økosystemet rundt metabokser og egendefinerte felt, og svært mange byråbygde kundenettsteder står på nettopp det.

#Gamle metabokser mister unntaket sitt

Det er ikke bare blokker som har holdt editoren utenfor iframen. Å registrere klassiske metabokser var en av de andre veiene, og derfor finnes det mange installasjoner med egendefinerte metabokser og ACF-feltgrupper tegnet opp på gamlemåten som aldri har møtt iframe-oppførsel i det hele tatt. Feltguiden for 7.1 stenger den døren i én setning: “WordPress 7.1 completes the move to an iframe-based post editor, including for sites that register legacy meta boxes.” WordPress 7.1 fullfører altså overgangen til en innleggseditor basert på iframe, også for nettsteder som registrerer gamle metabokser.

Det er denne flaten som er mest sannsynlig å treffe et byrå, for den krever ikke at noen har skrevet en eneste blokk. Den krever bare en gammel innholdstype med felter skrudd på, og det beskriver en stor del av enhver portefølje man har overtatt fra andre. Disse skjermene må testes for seg: et nettsted kan komme grønt gjennom blokktesten over og likevel ryke her, fordi det som har byttet grunnlag, er selve redigeringsskjermen.

#Hva et byrå bør gå gjennom i kundeporteføljen

Drifter du nettsteder du ikke har bygget selv, er ikke det avgjørende spørsmålet om din egen kode er klar. Det er hvilken kode på disse installasjonene som ikke lenger er noens ansvar. Den opptellingen er utviklingsarbeid, og den er verdt å gjøre før en redaktør ringer og sier at oppsettet ser rart ut.

• Bygg blokkoversikten. Noter per nettsted hvilke plugins og temaer som registrerer blokker, og hvilken apiVersion hver blokk erklærer. Å skru opp tallet reparerer ingen oppførsel i 7.1, men antallet versjon 2-blokker forteller deg hvor du skal se først.
• Skill vedlikeholdt fra forlatt. Sjekk for hver berørt plugin når siste utgivelse kom, og om utvikleren har sagt noe om iframe-kompatibilitet. En vedlikeholdt plugin betyr at du venter og tester. En forlatt plugin betyr at du velger mellom en lokal lapp, en fork eller en erstatning, og den avgjørelsen har ledetid.
• Søk gjennom din egen kode. Let i alle egenutviklede plugins og temaer i porteføljen etter document. og window. i editorbunter, i tillegg til jQuery( og enhver enqueue_block_editor_assets-handler som registrerer innholdsstiler. Dette er en rask, mekanisk gjennomgang som gir en konkret liste.
• Se særskilt på metaboks-laget. ACF, Meta Box og lignende verktøy ligger i den høyeste risikokategorien, og de sitter som regel på nettopp de nettstedene der redaksjonen merker feil raskest.
• Kjør en egen runde på metaboks-skjermene. Når blokktesten er unnagjort, åpne hver innholdstype som har egendefinerte metabokser eller klassiske ACF-feltgrupper, lagre et innlegg og kontroller at verdiene består og at panelene fortsatt tegnes opp. Dette er en runde nummer to, ikke et punkt inne i den første.
• Test redigeringsflyten, ikke bare sidelastingen. Feilene under nedriving viser seg først når blokker settes inn, flyttes og slettes. En røyktest som åpner et innlegg og ser på det, går grønt også på en ødelagt installasjon.
• Prioriter etter redaksjonell belastning. Et nettsted der redaksjonen publiserer daglig, må være i orden før 19. august. En presentasjonsside som redigeres to ganger i året, må ikke det.

Ingenting av dette er eksotisk. Det er en opptelling, et søk i koden og en testmatrise, og det hører hjemme i en planlagt syklus framfor i en krisesituasjon. Vil du ha det tatt hånd om som en løpende avtale, hører det inn under et program for vedlikehold av WordPress-nettsider, der testing av kjerneutgivelser allerede står i kalenderen.

#Kilder

• Aki Hamano, Iframed Editor Changes in WordPress 7.1, 3. august 2026
• Ella Van Durpe, Iframed Editor Changes in WordPress 7.0, 24. februar 2026
• WordPress 7.1 Field Guide, 5. august 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”, flettet inn 10. juli 2026
• Gutenberg sporingssak #70743, samt sakene #55947, #47924, #53236 og PR #52588