Gutenberg 24.2 og React 19: hva bør du sjekke i egne blokker?

Oppdatering, 3. november 2026. Gutenberg 24.3 er ute (utvidelsen datert 28. oktober; What’s new-innlegg publisert 2. november). Redaksjonelle endringer som teller på et live-nettsted: formater tekst over et flervalg av blokker, emoji-reaksjoner på notater (hjerte, fest, øyne og noen flere), Media-innsetter bygget om på DataViews-rutenettet med forhåndsvisning av filer som ikke er bilder, og lagre/autosave-feilmeldinger med detaljer, HTTP-status når den finnes, kopiering og nedtelling til neste forsøk. Utgivelsen tar også med sikkerhetsfiksene fra WordPress 7.1.4, så oppdater Gutenberg-utvidelsen hvis den kjører i produksjon. React 19 er fortsatt på som standard som i 24.2; sjekklisten under gjelder fortsatt.

Gutenberg 24.2 kom 14. oktober 2026. For redaksjoner gir den notater i margen i redigeringsverktøyet, ett felles lenkesøk i menyen og sortering av gallerier. For forfattere av utvidelser og temaer er én endring viktigere: Gutenberg-utvidelsen laster nå React 19 som standard i stedet for React 18. Har du egne blokker eller innstillingssider skrevet i React på nettstedet, bør de sjekkes nå, før React 19 kommer inn i selve WordPress.

Denne artikkelen bygger på det offisielle innlegget om versjon 24.2, endringslisten i Gutenberg-kodelageret, to innlegg på Make WordPress Core om React 19 og migreringsveiledningen for React 19.

#Hva er nytt i Gutenberg 24.2?

Versjonen har fem hovedendringer:

• notater flyttet ut i margen ved siden av innholdet,
• ett søk for alle typer lenker i navigasjonsblokken,
• sortering og felles duotone-filter i galleriblokken,
• flere blokker med de samme designverktøyene (rundt 80 kodeendringer),
• React 19 slått på som standard og to tillegg i Interactivity API.

I tillegg kommer over 60 feilrettinger og endringer i tilgjengelighet og ytelse. Noen mindre endringer betyr mye i det daglige arbeidet. Glidebryteren for antall kolonner i kolonneblokken er borte: en kolonne legges til med plussknappen ved siden av blokknappen i verktøylinjen og fjernes som en hvilken som helst annen blokk. Etter beskjæring av et bilde kan bilderedigeringen gå tilbake til originalen uten at man må inn i mediebiblioteket. Forfatterfeltet for innlegg har alltid søk og leter etter brukere på serversiden, så på nettsteder med mange kontoer dukker riktig person opp i listen.

Gutenberg 24.2 retter også adressene til nye innlegg. Til nå kunne et nytt innlegg bli publisert med kortnavnet auto-draft hvis noen klikket i kortnavnfeltet før publisering. I 24.2 skjer ikke det lenger. Har du sett innlegg med en slik adresse på et nettsted med Gutenberg-utvidelsen, var dette årsaken.

Paneler som utvidelser legger til, er flyttet til en undermeny for paneler i alternativmenyen i redigeringsverktøyet, ved siden av de nye undermenyene for utseende og notater. Festede knapper for disse panelene i verktøylinjen blir der de var. Forfattere av utvidelser med eget sidepanel bør sjekke om brukerveiledningene fortsatt beskriver riktig sted.

#Er React 19 allerede i WordPress?

Nei. WordPress 7.1 kjører på React 18.3. I juli 2026 forklarte Jarda Snajdr på Make WordPress Core hvorfor overgangen til React 19 ble tatt ut av 7.1: etter en kort aktivering i Gutenberg-utvidelsen dukket det opp uventede uforenligheter mellom den gamle og den nye React-versjonen og i måten utvidelser bruker React på, og endringen måtte trekkes tilbake.

«Det vil trengs en lengre testperiode der vi retter og finpusser kompatibilitetslaget som gjør at eksisterende utvidelser fortsetter å virke uten problemer.»

Kilde: Jarda Snajdr, Make WordPress Core, 24. juli 2026, egen oversettelse

Fra versjon 23.4 hadde Gutenberg-utvidelsen et React 19-eksperiment som måtte slås på manuelt. Gutenberg 24.2 snur denne innstillingen: eksperimentet er slått på som standard. WordPress selv, uten Gutenberg-utvidelsen, laster fortsatt React 18.3.

Utgivelsesplanen for WordPress 7.2 sikter mot lansering i begynnelsen av desember 2026. Om React 19 står det at typer, avhengigheter og gjengivelsesrettinger i Gutenberg stort sett er klare, men at en full overgang i 7.2 er lite sannsynlig. For team som drifter nettsteder betyr det at React 19 i Gutenberg-utvidelsen nå er en testperiode, ikke en lanseringsdato i WordPress. Bakgrunnen for beslutningen i sommer beskriver vi i artikkelen om planen for WordPress 7.1.

#Når lar Gutenberg 24.2 nettstedet bli på React 18?

Ifølge innlegget om versjonen laster nettsteder med utvidelsen React 19 for skriptene react og react-dom, med mindre et aktivt tema eller en aktiv utvidelse er kjent for kompatibilitetsproblemer. Da blir nettstedet på React 18. Listen over slike temaer og utvidelser startet med problemer som ble observert på WordPress.com, og ble utvidet i denne versjonen (endring #84607).

Det gir to praktiske følger. For det første kan samme Gutenberg-versjon laste ulike React-versjoner på to nettsteder, avhengig av hvilke utvidelser som er installert. Når du tester en blokk, sjekk hvilken versjon redigeringsverktøyet faktisk fikk. I nettleserkonsollen på redigeringsskjermen holder det å skrive React.version, fordi WordPress gjør React tilgjengelig som en global variabel. For det andre beviser fravær av problemer på et nettsted som havnet på unntakslisten, ingenting. Blokken ble da testet på React 18.

Unntakslisten er en midlertidig løsning. Står utvidelsen din på den, kommer problemet tilbake den dagen React 19 kommer inn i WordPress.

#Hvordan slår man av React 19 i Gutenberg?

Gutenberg-teamet skriver rett ut hva man skal gjøre når noe slutter å virke:

«Vedlikeholder du en utvidelse eller et tema som bruker React, test det med Gutenberg 24.2 og meld fra om alle problemer du finner. Hvis noe slutter å virke på nettstedet, slå av React 19 under Gutenberg > Experiments.»

Kilde: What’s new in Gutenberg 24.2, Make WordPress Core, 14. oktober 2026, egen oversettelse

I WordPress-panelet er det menyen Gutenberg, siden for eksperimenter, avkrysningsboksen ved React 19. Innlegget om eksperimentet fra juli beskrev den samme siden som tilgjengelig under Gutenberg-innstillingene. Avslåingen gjelder hele nettstedet, så det er en nødløsning for produksjon, ikke en måte å reparere en blokk på. En blokk som bare virker med React 19 slått av, må rettes før WordPress kommer med React 19.

Den andre muligheten er å la være å installere Gutenberg-utvidelsen i produksjon. Et nettsted uten denne utvidelsen får React fra WordPress, altså 18.3 i dag. Gutenberg-utvidelsen installeres i produksjon når kunden trenger funksjoner som ennå ikke finnes i WordPress. Trengs den ikke, test React 19 på en kopi av nettstedet.

#Hvilke API-er fjernet React 19, og hva ødelegger det i WordPress-blokker?

Innlegget på Make WordPress Core fra juli nevner to typiske kilder til feil i utvidelser. Den andre er gamle React-funksjoner som har vært utdatert i minst seks år og er fjernet i React 19. Kompatibilitetslaget i Gutenberg fyller inn noen av dem, men ikke alle. Migreringsveiledningen for React 19 gir hele listen, med datoen hvert API ble utdatert:

Klassekomponenter beholder defaultProps, fordi det ikke finnes noe tilsvarende for klasser i ES6-syntaksen. Også react-dom/test-utils og react-test-renderer/shallow er fjernet, noe som gjelder enhetstester, ikke selve blokken.

I WordPress-kode møter man oftest render som monterer en innstillingsside eller en widget i administrasjonspanelet. Eldre utvidelser importerer den fra @wordpress/element, som i bakgrunnen kaller ReactDOM.render. Nyere versjoner av pakken eksporterer createRoot, og det er den som må brukes:

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

const container = document.getElementById( 'my-plugin-settings' );
if ( container ) {
	createRoot( container ).render( <SettingsPage /> );
}

Det andre vanlige tilfellet er defaultProps på en funksjonskomponent i blokkredigeringen. I React 19 blir standardverdiene rett og slett ikke satt, så komponenten får undefined og kaster som regel ingen feil, men viser et tomt panel eller regner ut feil verdi. En slik feil er lett å overse, fordi konsollen er stille.

Veiledningen har et ferdig sett med automatiske rettinger: npx codemod@latest react/19/migration-recipe. Kjør det på en egen gren og les hver endring, for det kjenner ikke særtrekkene ved @wordpress/*-pakkene.

React 18.3, som WordPress 7.1 kjører på, er ifølge React-teamet identisk med 18.2, men legger til advarsler om utdaterte API-er og andre endringer som trengs for React 19. Ser du advarsler med navnet på utvidelsen din i konsollen i redigeringsverktøyet på vanlig WordPress 7.1, har du en ferdig liste over hva som må rettes.

#Hvordan sjekker man om en utvidelse har med sin egen kopi av React?

Den første feilkilden fra innlegget i juli er vanligere og vanskeligere å se i kildekoden, fordi den først vises i den ferdigbygde JavaScript-filen.

«Hvis alle bygde JavaScript-koden sin riktig, ville de fleste kompatibilitetsproblemene ikke oppstått i det hele tatt.»

Kilde: Jarda Snajdr, Make WordPress Core, 24. juli 2026, egen oversettelse

Det handler om kode fra react/jsx-runtime som er bygget rett inn i utvidelsens fil i stedet for skriptet react-jsx-runtime som WordPress leverer. Da kjører React 18 fra utvidelsens pakke og React 19 fra WordPress side om side på nettstedet, og datastrukturer laget av den gamle versjonen havner i den nye. Komponenten ser riktig ut i koden, men i redigeringsverktøyet monteres den ikke, eller den kaster en feil om et ugyldig element.

Sjekken tar noen minutter per utvidelse:

1. Åpne filen *.asset.php ved siden av det ferdigbygde skriptet (for eksempel build/index.asset.php). Bruker koden JSX, skal react-jsx-runtime stå på listen over avhengigheter.
2. Søk i de ferdigbygde filene etter kode fra selve React, for eksempel grep -l "react.element" build/*.js. Et treff i utvidelsens fil tyder på at en del av React ligger i pakken. Det er grunn til å sjekke byggeoppsettet, ikke en dom.
3. Sjekk at byggeoppsettet ikke går utenom mekanismen som bytter ut importer av react og @wordpress/* med WordPress-skriptene. Det skjer oftest med egen webpack eller Vite i stedet for @wordpress/scripts.
4. For utvidelser kjøpt fra en ekstern leverandør, uten tilgang til kildekoden, gjenstår testen i redigeringsverktøyet fra neste avsnitt og en feilmelding til forfatteren.

Gutenberg-teamet jobber med automatisk oppdagelse av disse problemene i utvidelsen Plugin Check. Inntil det fungerer, ligger sjekken hos forfatteren av utvidelsen.

#Hvordan tester man egne blokker med React 19 på en kopi av nettstedet?

Innlegget fra juli definerer kompatibilitetstesten enkelt: bruk alle delene av utvidelsen som bruker React, vanligvis blokker, utvidelser av redigeringsverktøyet og egne sider i administrasjonspanelet, og sjekk at grensesnittet ikke er ødelagt og at det ikke er feil i nettleserkonsollen. På en testkopi av nettstedet gjøres det slik:

1. Lag en kopi av nettstedet med samme versjon av PHP, WordPress og utvidelser som produksjonen. Inneholder kopien kundedata fra nettbutikken, anonymiser dem før kopieringen.
2. Installer Gutenberg i versjonen fra utgivelsen: wp plugin install gutenberg --version=24.2.0 --activate.
3. Sett define( 'SCRIPT_DEBUG', true ); i wp-config.php på kopien. WordPress laster da ukomprimerte versjoner av skriptene, også utviklerversjonen av React, som viser fullstendige advarsler i stedet for forkortede feilkoder.
4. Skriv React.version i konsollen i redigeringsverktøyet og kontroller at det er 19. Ser du 18, står en av de aktive utvidelsene på unntakslisten, og testen må gjentas uten den.
5. Sett inn hver egen blokk i et nytt innlegg, endre hver innstilling i blokkpanelet, lagre, last inn redigeringsverktøyet på nytt og sjekk at blokken ikke viser en melding om ugyldig innhold.
6. Åpne hver innstillingsside i utvidelsen og hvert sidepanel utvidelsen legger til i redigeringsverktøyet. Etter 24.2 ligger disse panelene i undermenyen for paneler i alternativmenyen.
7. Se til slutt på de lagrede innleggene på nettstedet. Dynamiske blokker gjengis av PHP, så der spiller React ingen rolle, men blokker med Interactivity API og skript på siden må klikkes gjennom.

Listen til punkt 5 bør dekke blokkene kunden faktisk bruker, ikke bare dem som er registrert. Har nettstedet et bibliotek med flere titalls blokker, start med dem på forsiden, produktsiden og i skjemaene. De generelle prinsippene for arbeid på en testkopi beskriver vi i veiledningen om å rulle ut endringer via en kopi av nettstedet, og for en rask sjekk av én blokk på en ren installasjon holder WordPress Playground.

Meld fra om hvert problem du finner, med Gutenberg-versjonen, React-versjonen fra konsollen og feilmeldingen. Teamet ber om feilmeldinger i Gutenberg-kodelageret på GitHub, og for eksterne utvidelser hos forfatterne deres.

#Hvordan fungerer notatene i margen i redigeringsverktøyet?

Til nå kunne flytende notater og innstillingspanelet ikke være åpne samtidig, og notatkolonnen tok plass fra innholdet. I 24.2 setter redigeringsverktøyet av en marg ved siden av redigeringsområdet og viser notatene der, så de forblir synlige når man bytter blokk og endrer innleggsinnstillinger.

I et smalere vindu foldes hver tråd sammen til forfatterens avatar, og et klikk på avataren folder den ut igjen. Den nye undermenyen for notater i alternativmenyen lar dem foldes ut, minimeres eller skjules, og redigeringsverktøyet husker valget. Tre endringer reduserer risikoen for å miste arbeid: sletting av et notat kan angres, et notat eller svar som ikke er sendt, forsvinner ikke når man markerer en annen blokk, og notatene ruller sammen med innholdet.

For en redaksjon som diskuterer tekster i redigeringsverktøyet, betyr dette mindre veksling mellom paneler. For blokkforfattere er det én praktisk følge: redigeringsområdet har nå mindre plass når notatene vises. Blokker med fast bredde eller eget oppsett i redigeringsverktøyet bør ses over med notatene åpne.

Planen for WordPress 7.2 varsler flere endringer i notatene: en forslagsmodus der en foreslått tekstendring kan godtas eller avvises, emoji-reaksjoner og en egen knapp for å legge til notat i blokkens verktøylinje.

#Hva er endret i navigasjonsblokken og i galleriet?

Å legge til noe annet enn en side i menyen krevde før at man visste hvilken blokk man skulle bruke, for eksempel lenke til kategori eller lenke til stikkord, og først der kunne man søke. Nå søker lenkesøket i navigasjonsblokken i alle innholdstyper samtidig og viser typen ved hvert resultat. En eksisterende lenke kan endres fra kategori til side uten å slette den og legge den til på nytt. Det samme søket viser også blokker menyen godtar, så å skrive Home finner blokken for lenke til forsiden.

Resultatene sorteres nå etter type: innlegg og sider før kategorier, stikkord og medier. Denne rekkefølgen gjelder i alle lenkesøk i redigeringsverktøyet, ikke bare i menyen. På store nettsteder slutter stikkord og vedlegg å skyve det ønskede innlegget ut av resultatlisten. For forfattere av utvidelser som legger egne innholdstyper inn i lenkesøket, er det en grunn til å sjekke hvor resultatene deres havner.

Global Styles kan nå style tilstandene til navigasjonslenker (peker over, fokus, synlig fokus, aktiv), foreløpig bare typografi. Temaer som gjorde dette med egen CSS, kan flytte noen av reglene til theme.json, men det lønner seg å sjekke først hvilken regel som vinner.

I galleriblokken virker sorteringen nå også for gallerier med håndplukkede bilder. Sortering fra nyeste, fra eldste og alfabetisk begge veier ordner bildene én gang, og etterpå kan de fortsatt dras rundt. Det tilfeldige valget ligger på samme sted og stokker bildene ved hver innlasting av siden. For nettsteder med hurtigbuffer for hele sider er det viktig: den tilfeldige rekkefølgen endres først når bufferen fornyes, ikke ved hvert besøk.

Galleriet har også fått støtte for duotone. Ett filter farger alle bildene i galleriet, satt i blokken eller for alle gallerier på nettstedet i Global Styles. Duotone satt på et enkelt bilde går foran galleriinnstillingen. Duotone har også kommet til blokkene media og tekst og video. Ved produktbilder, sjekk at et filter satt globalt ikke endrer farger der kunden ikke vil det.

#Hva er nytt i Interactivity API?

Det nye direktivet data-wp-html viser HTML fra tilstanden, slik data-wp-text viser tekst. Det godtar bare verdier merket som betrodd med asDangerousHTML(). Eksempel fra innlegget om versjonen:

import { asDangerousHTML, store } from '@wordpress/interactivity';

store( 'myPlugin', {
	state: {
		get description() {
			return asDangerousHTML(
				'<p>A <strong>formatted</strong> description.</p>'
			);
		},
	},
} );

<div data-wp-interactive="myPlugin">
	<article data-wp-html="state.description">
		<p>Loading description.</p>
	</article>
</div>

Planen for 7.2 forklarer at den første versjonen bare viser verdier som applikasjonskoden eksplisitt har merket som betrodd, og at støtte for rensede vanlige tekststrenger kommer senere. Ikke send noe til asDangerousHTML() som kommer fra brukeren eller fra blokkattributter uten rensing på PHP-siden. I samme versjon fikk Gutenberg-dokumentasjonen en merknad om at blokkattributter og verdier fra Global Styles må behandles som ikke betrodd i det øyeblikket de gjengis. Gjør du en sikkerhetsgjennomgang av en utvidelse, legg søk etter asDangerousHTML til listen over ting et menneske leser.

Ruteren gjør nå state.navigating og state.initiator tilgjengelig, så blokken vet at en navigasjon på klientsiden pågår, og hvilken blokk som startet den. Ifølge planen for 7.2 erstatter dette det utdaterte paret state.navigation.hasStarted og state.navigation.hasFinished. Blokker med egen lasteindikator ved navigasjon bør skrives om til de nye feltene før de gamle fjernes.

#Fungerer notatene i Gutenberg i sanntid?

Nei. Notatene er kommentarer til blokker, som leses og legges til når som helst. Sanntidssamarbeid står ikke i planen for WordPress 7.2. Planen sier at det, som i 7.1, trengs mer tid til arkitekturbeslutninger, så temaet er utelatt i stedet for å bli tatt med og så trukket tilbake.

Arbeidet pågår i den eksperimentelle utvidelsen gutenberg-sync-engines, beskrevet i veiledningen om synkroniseringsmotorer fra 14. oktober. Tre motorer testes: yjs-server, DE-RTC og intent-log. Utvidelsen krever WordPress 7.0 eller nyere og utvidelsen Presence API, og den inneholder i tillegg sin egen, litt endrede kopi av Gutenberg. Den virker derfor ikke ved siden av en aktiv Gutenberg-utvidelse, så testen av React 19 og testen av sanntidssamarbeid kan ikke gjøres på samme kopi av nettstedet.

Under veiledningen pekte forfatteren av Yjs-biblioteket, Kevin Jahns, på serverkostnaden:

«Sanntidsredigering lager svært mange små meldinger. Hvis hver av dem må starte en PHP-prosess, laste inn det delte dokumentet, kontrollere det, slå det sammen og skrive det tilbake til databasen, gir det stor ekstrabelastning på kommunikasjon, prosessering og database.»

Kilde: Kevin Jahns’ kommentar under veiledningen om synkroniseringsmotorer, 15. oktober 2026, egen oversettelse

For eiere av nettsteder på billig delt webhotell er det et signal om at sanntidssamarbeid en dag kan kreve et annet webhotell.

Oppdatering, 3. november 2026. Funksjonsutvidelsen Presence API nådde 0.20.0 1. november (WordPress.org-oppføringen; rundt 10 aktive installasjoner). Møtesammendraget fra 26. oktober, publisert 1. november, sier at sjekklisten for merge fortsatt trenger ekstern brukertesting og en sikkerhetsrevisjon utenfor repoet, og at 3. desember er tidligste dato for et første Trac-forslag (åtte uker uten breaking API-endring fra 0.17.0). Versjonene 0.18.4 til 0.20.0 gir en utloggingsfiks for innleggslåser, keepalive/roomChanged-hooks for push-relayer og wp_presence_admin_state(), slik at en relay kan skrive de samme radene som Heartbeat. Presence forblir avhengighet av gutenberg-sync-engines, ikke en erstatning for notater i 24.2/24.3, og leverer fortsatt ikke sanntids co-editing i WordPress 7.2.

#Hvem bør teste blokkene før WordPress 7.2?

Testen gir mening for alle nettsteder med egne blokker, utvidelser av redigeringsverktøyet eller innstillingssider i React, og for forfattere av utvidelser og temaer som har slike elementer. Et nettsted bygget bare av WordPress-blokker og populære utvidelser med aktiv støtte, er avhengig av at forfatterne deres gjør testen. Gutenberg-teamet ber om det nettopp nå.

Har du ingen i teamet som kan gå gjennom de ferdigbygde filene og klikke gjennom blokkene på en kopi av nettstedet, gjør en WordPress-utvikler det som et enkeltoppdrag, og med fast vedlikehold av nettstedet er testing av nye Gutenberg-versjoner før produksjonen oppdateres en del av jobben. Hvorfor en slik gjennomgang krever et menneske, skriver vi også om i artikkelen om rekruttering av utviklere som jobber med AI.

Oppgi i forespørselen versjonen av WordPress og PHP, en liste over utvidelser med egne blokker, om Gutenberg-utvidelsen er i bruk i produksjon, og om du har en testkopi av nettstedet. Prisen settes individuelt etter omfang. Skjemaet finner du på kontaktsiden.