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

Gutenberg 24.2 er en liten produktutgivelse for redaksjoner og et kompatibilitetssignal for blokkforfattere. Marginnotater og ett Navigation-søk reduserer friksjon i content ops. React 19 aktivert som standard i Gutenberg-pluginet flytter testing av egne blokker til staging: en regresjon fanget nå koster mindre enn samme regresjon etter at linjen lander i kjernen. Å vente på kunngjøringen «React 19 i WordPress X.Y» lar feilen bli liggende på kundens produksjonsside.

WordPress 7.1 lot React 19 ligge utenfor zip etter kompatibilitetsproblemer. 24.2 opphever ikke den beslutningen. React 19 har vært et eksperiment man slår på selv i Gutenberg-pluginet siden 23.4; 24.2 slår det på som standard for alle nettsteder med pluginet.

Har dere egne blokker eller en FSE-butikk og vil ikke risikere oppdatering i produksjon? Beskriv stacken (PHP, WP, WooCommerce, liste over editor-plugins) via kontakt. Dere får en staging- og akseptanseplan, ikke bare endringsloggen.

#Hva er nytt i Gutenberg 24.2

#Notes i Gutenberg 24.2-editoren

Notes sitter ved siden av innholdet, ikke bare i sidepanelet. Under review av artikkel eller landing kommenterer redaktøren ved den konkrete blokken. Mindre hopping mellom panel og canvas.

For byråer med content ops med flere personer endrer det rytmen:

• copywriteren legger et notat ved H2, ikke i en Slack-tråd uten kontekst,
• revieweren ser en stabel med merknader ved blokken i andre runde,
• blokkutvikleren ser hvilke UI-steder som skaper mest redaksjonell friksjon (ofte egne blokker med uklar inspector).

Kodeendringer går fortsatt til Linear/Jira. Notes erstatter skjermbilder med rød pil i PDF under innholdsreview.

#Søke etter sider og kategorier i Navigation-menyen

Legg til sider, innlegg, kategorier og stikkord i Navigation via ett søkefelt. Ved ombygging av IA (særlig flerspråklig) synker antall klikk og feil «la til feil side fra listen».

Praktisk staging-test: bygg meny med blanding av page + category + custom link, lagre, oppdater front, sjekk mobil-overlay. Navigation-regresjoner dukker ofte opp først på front, ikke i editoren.

#Gallery i Gutenberg 24.2: sortering og duotone

Order by-kontrollen virker nå også i gallerier med håndplukkede bilder (nyeste, eldste, A til Å, Å til A eller tilfeldig ved hver sidevisning), og ett duotone-filter farger alle bildene i et galleri, fra blokken eller for hele nettstedet via Global Styles. Sjekk:

• custom CSS som antar gammel filter-markup,
• underblokker / Gallery-varianter i child theme,
• lazy load og CLS ved endret bilderekkefølge,
• eksport til AMP eller headless (hvis dere serverer blokker utenfor klassisk tema).

Duotone ser kosmetisk ut til det ødelegger kontrast på produktbilder. I butikk: sjekk Gallery på produktkortet, ikke bare på bloggen.

#React 19 i Gutenberg 24.2 (som standard)

Dette er hovedsignalet for utviklerstacken. Nettsteder med pluginet laster nå React 19 for skriptene react og react-dom, med mindre et tema eller en plugin med kjente kompatibilitetsproblemer er aktiv; da blir nettstedet på React 18. Hvis noe brekker, kan React 19 slås av under Gutenberg > Experiments. For attributtet inert finnes den nye pakken @wordpress/react-inert-value, som fungerer med både React 18 og 19 (lanseringsinnlegget for 24.2).

Plugins og temaer med React i editoren skal teste og rapportere. Vent ikke på dato i kjernen: Roadmap to 7.2 anser full landing i 7.2 som lite sannsynlig, så regresjoner dukker opp i pluginet først.

Typiske bruddsteder etter React-oppgradering:

• react/jsx-runtime bygget inn i plugin-bundelen i stedet for det eksterne skriptet WordPress leverer (da kjører React 18 og 19 side om side),
• API-er fjernet i React 19: string refs, default props på funksjonskomponenter, legacy context,
• egne blokker med utdatert @wordpress/scripts / gammel webpack,
• slot fills og plugin-sidebarer som antar gamle lifecycles,
• React 18-peers i kundens plugin-package.json,
• Playwright/Cypress E2E som låste timing fra 18.

Hvis dere vedlikeholder et blokkbibliotek for flere kunder, er ett staging med 24.2 på et representativt prosjekt billigere enn fem hotfixes etter kjerne.

#Gutenberg 24.2, WordPress 7.1 og React 19 i core

I 7.1 kom ikke React 19 inn i kjernen. Beslutningen var riktig for økosystemstabilitet og ubehagelig for team som allerede hadde forberedt oppgraderingen. Gutenberg 24.2 er det offisielle stedet der økosystemet kan kjenne React 19 uten å tvinge det på hver installasjon uten Gutenberg-plugin.

For byråer betyr det tre spor:

1. Kunde uten Gutenberg-plugin i produksjon - blir på core-React foreløpig (7.1-linjen). Planlegg tester; ikke installer Gutenberg-pluginet «fordi 24.2 kom».
2. Kunde med Gutenberg-plugin (early features) - 24.2 er obligatorisk staging før oppdatering.
3. Egne produkter / blokker solgt til mange kunder - CI mot Gutenberg 24.2 + PHP/WP-matrise.

Bland ikke denne meldingen med WordPress.com Agent: annet produkt, annet spor (Agent og MCP write). Agenten tester ikke blokkene deres under React 19.

#Sjekkliste for Gutenberg 24.2-tester på staging

1. Installer Gutenberg 24.2 på en produksjonskopi (ikke live hos kunden). Under Gutenberg > Experiments, bekreft at React 19 er aktiv: med en plugin fra inkompatibilitetslisten blir nettstedet på React 18, og testen sier ingenting om 19.
2. Åpne innlegg med egne blokker: insert, duplicate, move, save, preview, undo.
3. Sjekk Navigation: søk side og kategori, lagre meny, oppdater front og mobil.
4. Gallery med duotone: skru på filter, endre rekkefølge, lagre, sjekk front.
5. Notes: legg merknad ved blokk, last editor på nytt, bekreft persistens, slett.
6. WooCommerce-smoke (hvis butikk): produkt, handlekurv, checkout, e-post.
7. Hvis noe feiler: minimal reproduksjon + PHP-/WP-/Gutenberg-/plugin-versjoner i issue tracker.

Utvidelse for blokkbibliotek (2-4 timer):

• unit-/integrasjonstester for pakken,
• ren asset-build (npm ci + build),
• sjekk React peerDependencies,
• sammenlign bundle size før/etter (regresjon går ofte med dobbel React).

#Hva unngå ved oppdatering av Gutenberg 24.2

• Ikke aktiver Gutenberg-pluginet i live WooCommerce-butikk uten rollback-plan og vedlikeholdsvindu.
• Ikke lov kunden «React 19 i kjernen i morgen». 24.2 er et plugin.
• Ikke behandle Notes som ticketsystem for utviklere.
• Ikke oppdater ti kunder samme dag «fordi 24.2 kom». Ett representativt staging, deretter bølgen.

#Gutenberg 24.2 i vedlikeholdsretainer

Kunde på retainer «WordPress-oppdateringer» bør få egen linje i månedsrapporten: test Gutenberg 24.2 / React 19-spor. Det er en blokkkompatibilitetsøkt, skilt fra vanlig core-bump.

Hvis retaineren ikke dekker editortester, legg inn change request før Gutenberg-oppdatering på staging. Billig én gang. Dyrt når editoren dør på kampanjepubliseringsdagen.

#Notes og Navigation-søk i daglig redaksjon

Notes

• ett notat = én beslutning (copy / layout / legal),
• ingen filosofitråder i margen,
• etter merge til final: slett eller arkiver notes, så canvas ikke ser ut som graffiti.

Navigation-søk

• sidenavn i admin må være unike og lesbare (duplikat «Tilbud» på to språk uten locale-prefiks forvirrer søk),
• etter menyombygging: eksporter struktur til IA-dokument (også Markdown-tabell) som sannhetskilde utenfor WordPress.

#Teste Gutenberg 24.2 på WooCommerce og membership

Er siden butikk eller membership, ikke blogg, er den generelle sjekklisten for kort. Legg til:

• redigering av Single Product-mal i site editor (ikke bare klassisk produkt),
• handlekurv-/checkout-blokker (Woo-blokker vs legacy shortcode),
• restricted content-blokker (membership, paywall),
• preview som innlogget vs gjest,
• lagre produktdraft med Gallery + duotone (om butikkfront arver filter på grid-miniatyrer).

En React-regresjon i produkt-Inspector kan blokkere Black Friday-kampanje hardere enn regresjon på blogginnlegg. Prioriter butikk-staging foran firmabloggen.

#Gutenberg 24.2, child theme, FSE og theme.json

Byråer holder ofte «noen linjer» i theme.json og child theme style.css. Etter 24.2 sjekk:

• Gallery- og duotone-overrides i theme.json,
• CSS som treffer klasser Notes eller ny Navigation-UI kan ha endret,
• synkede patterns som antar gammel markup.

FSE fritar ikke for tester. Jo mer UI i JSON og patterns, desto flere steder React 19 i editoren kan vise tomt panel eller uendelig spinner. Bakgrunn om blokker, mønstre og nettstedsredigereren: Gutenberg-blokker og full site editing.

#Hvordan rapportere Gutenberg 24.2-testresultater til kunden

Tre avsnitt i e-post etter staging-test holder:

1. Hva vi testet (blokkliste + Navigation + Gallery + Notes).
2. Hva vi fant (konkret: «Inspector for blokk X mister focus», ikke «editoren oppfører seg rart»).
3. Beslutning: oppdater Gutenberg / vent på upstream-fix / bli på core uten plugin til dato Y.

Kunder godtar forsinket oppdatering når de ser en testliste. De godtar ikke «det falt bare sammen etter oppdatering» uten den listen.

#Hvordan rapportere en bug i Gutenberg 24.2

Issue i plugin-repo eller på Gutenberg GitHub bør ha:

• versjoner: WP, PHP, Gutenberg, nettleser,
• reproduksjonssteg på fem linjer,
• forventet vs faktisk,
• om det feiler bare med deres blokk, eller på Twenty Twenty-Five + core-blokker.

«Det fungerer ikke hos oss» uten reproduksjon lander i limbo. Én god reproduksjon på rent miljø akselererer fix mer enn ti «+1»-kommentarer.

#React 19-testmatrise for et blokkbibliotek

Ett staging hos én kunde holder ikke hvis dere selger blokker til mange merker. Minimal matrise:

Automatisering: én CI-workflow som installerer Gutenberg 24.2, bygger blokker, kjører Playwright-smoke på insert/save. La Navigation, Gallery-duotone og Notes være manuelle - E2E er skjør på UI-marginer.

Matrisekostnaden betaler seg ved andre kunde med samme blokkbibliotek. For én statisk landing holder 15-30-minutters sjekklisten.

#Typiske regresjoner etter React 19 i Gutenberg

Fra React-oppgraderinger i WordPress-økosystemet (ikke bare 24.2) dukker ofte opp:

• dobbel React i bundlen (symptom: rare console-advarsler, inkonsekvent state),
• Inspector-kontroller som «mister» focus ved hvert keystroke,
• dynamiske SSR vs client-blokker: hydrate mismatch etter Gallery-markup-endring,
• eldre @wordpress/components-peers inkompatible med ny React,
• E2E som venter på selektorer Notes eller nytt Navigation-søk flyttet i DOM.

Logg hver regresjon med Gutenberg-versjon i issue-tittel. «Editoren er ødelagt» uten versjonsnummer er ubrukelig for bisect.

#Gutenberg Notes og sanntidssamarbeid

Samme uke publiserte Make WordPress Core en guide til synkroniseringsmotorene som vurderes for sanntidssamarbeid. I en kommentar under innlegget advarte Yjs-forfatteren Kevin Jahns om at sanntidsredigering gir svært mange små meldinger, og at en PHP-worker per melding gir mye overhead. Det er ikke changelog for 24.2, men kontekst for tech leads: spor for flersamarbeid og spor for React 19 er separate risikoer. Marginnotater løser asynkron review. De løser ikke konflikt mellom to markører i samme blokk.

Ikke selg kunden «real-time collaboration» fordi 24.2 kom. Selg bedre review og testede blokker.

#Når rulle ut Gutenberg 24.2 i produksjon

1. Staging grønn på sjekkliste og WooCommerce-smoke.
2. Avtalt vedlikeholdsvindu (ikke fredag etter 16:00 i butikk).
3. Rollback: forrige Gutenberg-zip + DB-backup fra før oppdatering.
4. Overvåking 24-48 t: JS-feil i editor, publish-tickets, checkout-feil.

Har kunden plugin-auto-update på, skru av auto-update for Gutenberg til staging er grønn. Gutenberg er ikke «bare et SEO-plugin til».

#Release notes for blokkplugin etter Gutenberg 24.2

Hvis dere selger egne blokker som plugin:

• changelog-linje «tested with Gutenberg 24.2 (React 19 default)»,
• i readme: minste @wordpress/scripts / build-toolchain,
• i CI: jobb gutenberg-next ved siden av wordpress-stable,
• i support policy: «rapporter uten Gutenberg-nummer lukkes med forespørsel om utfylling».

Enterprise-kunder leser release notes. Én linje om 24.2 bygger mer tillit enn vagt «improved compatibility».

#Gallery-duotone og merkevare-designsystem

Duotone i Gallery er praktisk for redaksjon og farlig for merkevare med strengt design system. Har kunden definerte filtre og fargetokens:

• skru av duotone i produkt-patterns,
• la det stå på blogg / social proof,
• skriv regelen i content guidelines (ikke forveksle med WordPress.com Agent Guidelines).

Agent og Gutenberg er separate produkter, men samme problem: verktøyet gir redaksjonen makt brand guide ikke planla. Ownership av design system blir hos byrået.

#Hvorfor WordPress 7.1 utsatte React 19

Fakta fra sommeren 2026 (detaljer i 7.1-roadmap): oppgraderingen fra React 18 til 19 falt ut av 7.1 etter at et kort forsøk i Gutenberg viste uventede inkompatibiliteter mellom de to React-versjonene og i måten plugins bruker React på. I Make Core-innlegget fra 24. juli 2026 skrev Jarda Snajdr at det trengs en lengre testperiode for å finjustere kompatibilitetslaget. 24.2 er konsekvensen av den forsiktigheten: Gutenberg-plugin først, deretter eventuelt kjerne.

For leads: dropp narrativet «Automattic er forsinket»; bruk «dere har et testvindu dere må bruke». Byråer som i august la bort forberedelser «fordi 7.1 uten React 19» får en ny sjanse i oktober med 24.2. Et tredje bekvemt vindu før kjerne kan utebli.

#Godkjenne frilansblokker under Gutenberg 24.2

Når en frilans blokkforfatter sier «det funker hos meg på core», spør:

• om de testet Gutenberg 24.2,
• om package.json har React 19-peer eller fortsatt 18,
• om de leverer reproduksjon på rent staging.

Betaling for blokk uten den sjekklisten er kjøp av risiko. I B2B-avtale: aksept på miljø med Gutenberg 24.2 som leveransevilkår.

#Editor-ytelse etter React 19 i Gutenberg

Nyere React forbedrer ofte concurrent features, men på svake redaksjonslaptoper eller VPS med tung admin kan dere se:

• lengre tid til Inspector-interaktivitet,
• jank ved drag-and-drop av stor Gallery,
• høyere minnebruk med mange notes samtidig.

Mål subjektivt på redaktørens maskinvare (ikke bare utviklerens M-series) og objektivt: DevTools Performance-panel ved lagring av innlegg med 40 blokker. Hvis admin-LCP ikke betyr noe for SEO, betyr det noe for retention i content-teamet. Redaktør som venter tre sekunder på hver Inspector-endring går tilbake til Classic Editor eller Google Docs.

#Tilgjengelighet for notater og navigasjon i Gutenberg 24.2

Marginnotater må være tastaturtilgjengelige og lesbare for skjermlesere. Navigation-søk må kunngjøre resultater for AT. Etter 24.2:

• tab gjennom notes og lukking av merknad,
• sjekk focus trap i Navigation-modaler,
• anta ikke «ny Automattic-UI = WCAG automatisk».

For kunder under BFSG / EAA / tilgjengelighetslov er det ikke valgfri test. Det er akseptvilkår for malen.

#Når bli på WordPress core uten Gutenberg-plugin

Bli på core (uten Gutenberg-plugin) når:

• butikken genererer så mange ordrer/dag at dere ikke har vindu for regresjon,
• dere er avhengige av editor-plugins uten maintainere,
• kunden har kontrakt «null admin-UI-endringer i Q4».

Skru likevel på 24.2 på staging, så dere vet hva som kommer. Kunnskapsbaseline er billigere enn overraskelse på core-oppgraderingsdagen.

#Opplæring av redaksjonen i Notes i Gutenberg 24.2

Teknisk grønt lys er halvparten. Den andre halvparten: 30-minutters workshop for redaktører.

Agenda:

1. Hvordan legge til note ved blokk og hvordan løse den.
2. Når note, når ticket i tracker (kodeendring = ticket).
3. Hvordan søke i Navigation uten å lage sidesduplikater.
4. Når ikke røre duotone på produktbilder.

Uten workshop blir notes søppel, og Navigation-søk kilde til dårlige lenker. Før workshop inn i retaineren som 24.2-implementeringslinje.

#Risikoer ved Gutenberg 24.2 for tech leads

Én tabell for prosjektstatus:

For ledelsen: 24.2 er billig på staging og dyrt i produksjon uten sjekkliste.

#Når bestille Gutenberg 24.2-test eksternt

Bestill review når:

• dere vedlikeholder et blokkbibliotek for flere merker,
• butikken genererer salg og dere mangler vindu for Inspector-regresjon,
• en freelancer leverte blokker som «virker på core» uten 24.2-test,
• retaineren «oppdateringer» ennå ikke dekker React 19-sporet.

I forespørselen: staging-URL eller plugin-liste, WooCommerce-versjon, om HPOS er på, deadline for vedlikeholdsvindu. Det holder for å prise smoke versus full matrise.

#Gutenberg 24.2: staging før produksjon

Notes, menysøk og Gallery er redaksjonell gevinst. React 19 i pluginet er staging-plikt for byråer som selger blokker og FSE. Oppdatering uten sjekkliste flytter risikoen til kunden.

Sporet Agent / MCP write og Gutenberg-sporet forblir separate: Agenten tester ikke React, og React 19 i pluginet lukker ikke publish-gate for MCP write.

Blokkreview eller retainer med Gutenberg-sporet: kontakt. Bredere utvikling: WordPress-utvikler.