I 2015 handlet WordPress-samtalen om REST API. I september 2026, med 7.1.1 som stabil utgivelse, handler den om hvem som får redigere samme innlegg samtidig, hva en KI-agent får kalle, og om du kan hente innholdet ut av en lukket bygger uten å kopiere for hånd.
To tall rammer inn resten. W3Techs målte WordPress til 40,2 % av alle nettsteder og 58,8 % av nettsteder med kjent CMS 20. september 2026, ned fra 43,2 % av alle nettsteder i desember 2025. Veikartet er et svar på den skråningen, ikke en seiersrunde. Lanseringen av Cloudflares EmDash CMS er ett synlig stykke av samme press - i norske anbud dukker spørsmålet opp når en offentlig etat eller en nettbutikk vurderer «moderne» alternativer.
Det som følger er veikartet sjekket mot kjernen, utgivelse for utgivelse. Der en funksjon er ekte, får du funksjonsnavnet. Der den fortsatt er diskusjon, står det.
Fase 3: samarbeid, hva som ble levert og hva som ikke ble
Veikartet på wordpress.org navngir fire Gutenberg-faser: Easier Editing, Customization, Collaboration, Multilingual. Fase 3 er den aktive, og den er delvis levert.
Notes ble levert. Kommentarer på blokknivå lander i WordPress 6.9 2. desember 2025, etter en eksperimentell runde i Gutenberg-pluginen. Omdøpt fra «block comments» til Notes for å holde dem atskilt fra wp_comments som lesere bruker. Første utgivelse dekker å legge til, tråde, løse og slette notater på hele blokken, ikke på et utvalg inni. Å se eller opprette krever capability edit_post, fordi notater bare finnes i innleggseditoren.
WordPress 7.1 utvidet dem heller enn å erstatte dem: e-postvarsler for omtaler i Notes, delbare revisjonslenker, og en fiks slik at Notes ikke lenger lekker inn i kommentar-feed-spørringer. Det siste er verd å vite før du filer en bug: en tilpasset kommentar-feed bygget på 6.9 kunne se note-poster den aldri ba om.
Sanntidssamarbeid ble ikke levert. Det nådde kjernen som beta og ble deretter trukket. Testkallet 11. mars 2026 ba folk om å installere WordPress 7.0 Beta 1 på en server andre kunne nå, slå på «Enable real-time collaboration» under Innstillinger > Skriving, og åpne samme innlegg fra to kontoer. 8. mai 2026 ble det fjernet fra 7.0; årsakene er den nyttige delen: overflateareal, race conditions, serverbelastning, minneeffektivitet og bugs som fortsatte å dukke opp under fuzz-testing. Det er heller ikke aktivert i 7.1. Synklagret bygger på Yjs, og core/freeform (Classic) er listet som inkompatibel. For utgivelse-for-utgivelse-blikket, se WordPress 7.1-veikartet.
Delen som treffer koden din. Testkallet sier det rett ut: blokker synkroniserer gjennom attributtene sine, så de fleste støtter samarbeid som standard, og de som knekker er de som holder editor-tilstand et annet sted. Deklarer feltet i block.json med type, les fra attributes, skriv med setAttributes ved endring - i stedet for å parkere det i en React-useState inne i edit() til blur. Det lønner seg allerede i angre, revisjoner og autosave, og det avgjør om blokken din overlever hvis samarbeid kommer tilbake.
Fase 4: flerspråklig, fortsatt et navn på en liste
Veikartet beskriver fase 4 i én linje: kjerneimplementering for flerspråklige nettsteder. Det finnes ingen skjema, ingen API, ingen dev-note og ingen dato. Advanced Administration Handbook dokumenterer fortsatt flerspråklig WordPress som noe du løser med plugin.
Rekkefølgen er den interessante delen, og den står åpent i fase 3-oppdateringene: samarbeidsinfrastrukturen må være på plass før flerspråklighet kan designes, fordi begge trenger samme svar på hvordan ett logisk innhold mapper til flere lagrede versjoner. Å gjøre det motsatt ville bety å løse det to ganger. Fase 4 er altså ikke blokkert av manglende interesse, men av at fase 3 ligger én utgivelsessyklus bak egen beta.
For norske og nordiske flerspråklige nettsteder (bokmål/nynorsk, eller nb/en/sv) er det fornuftig å gjøre mens du venter:
- Hold oversettelsesidentitet i post meta eller en taksonomi, ikke bakt inn i mal-logikk.
- Ikke lagre en locale-streng inne i blokkattributter. En blokk som hardkoder
nb_NOblir ugyldig innhold den dagen oversettelseslaget flytter seg. - Behandle WPML og Polylang som langsiktige avhengigheter, ikke stopgap. De vil overleve dette veikartpunktet.
Data Liberation: fem faser og verktøyene som finnes nå
Prosjektsiden på wordpress.org/data-liberation ble publisert 6. desember 2023 og navngir fem faser eksplisitt:
| Fase | Navn | Status |
|---|---|---|
| 1 | Migration Guides | Pågående |
| 2 | Importing and Exporting Structured Data | Pågående |
| 3 | Liberating Data From Closed Platforms | Startet |
| 4 | Direct WordPress-to-WordPress Synchronization | Fremtid |
| 5 | Content Creation Powerhouse | Fremtid |
Fase 4 og 5 - det folk mener med «ettklikksmigrering» - er ikke startet.
Det som finnes er snevrere og mer nyttig enn slagordet. Data liberation agent-pluginen, open source fra Studio by WordPress.com, leverer formålbygde ekstraktorer for navngitte plattformer: GoDaddy Websites and Marketing, Hostinger Website Builder, HubSpot, Shopify, Squarespace, Webflow, Weebly og Wix. Det er scrapere for konkrete lukkede byggere, ikke et universelt format. Parallelt bygger Playground-teamet nye PHP-importører som streaming-parsere, og Playground-blueprintsteget importWxr kan nå gå via Data Liberation-importøren i stedet for den gamle.
Praktisk for byrå: for de åtte plattformene på listen finnes reelt verktøy verdt å teste før du priser manuell innholdsmigrering. For alt annet er WXR fortsatt kjerneformatet for eksport - og WXR bærer fortsatt ikke mediefiler, plugin-innstillinger eller blokkmønsterbiblioteket. Budsjetter deretter, særlig når en norsk nettbutikk skal ut av Shopify eller Webflow.
Admin-redesignet: hva 7.1 faktisk ga deg
Først en rettelse som sirkulerer mye. MP6 lander ikke i 2012. Det var en feature-plugin foreslått i oktober 2013 og mergert inn i WordPress 3.8, utgitt 12. desember 2013. Og admin har ikke stått stille siden: 7.1 endret den.
Det som ble levert i WordPress 7.1 19. august 2026 er et designsystem-fundament, beskrevet i core-dev-noten 31. juli 2026. To ressurser er nå registrert som standard:
- Et
wp-theme-stilark med semantiske designtokens som CSS custom properties, navngitt etter mønsteret--wpds-color-background-surface-neutral-strong,--wpds-border-radius-lg,--wpds-dimension-padding-2xl. - Et
wp-theme-scripthåndtak som eksporterer enThemeProvider-React-komponent fra@wordpress/theme.
ThemeProvider tar fem props: color.primary og color.background som seed-farger, cursor.control, cornerRadius med presetene none, subtle, moderate og pronounced, og isRoot for theming på dokumentroten.
Tre flere 7.1-admin-endringer som dukker opp i sakssystemet før de dukker opp i et blogginnlegg:
- Propen
__next40pxDefaultSizeer ferdig med reisen: fra 7.1 er den en no-op, fortsatt godtatt og ignorert heller enn fjernet. Skjemakontroller rendres på 40px uansett, så admin-skjermer som var avstemt mot gammel default forskyves. wp_get_tooltip()ogwp_get_toggletip()gir tilgjengelige verktøytips som kjernefunksjon i stedet for en plugin-reimplementering - relevant når du jobber mot WCAG-krav i offentlig sektor.- Radhodet i innleggslisten flyttet fra avkrysningskolonnen til tittelkolonnen, en tilgjengelighetsfiks som endrer hva skjermlesere kunngjør per rad.
Hva 7.1 ikke er: en erstatning for wp-admin, et kundedashboard eller en white-label-overlevering. Tokens og en provider er åpningen, ikke ferdig redesign. Planlegg kundevendt admin ut fra at du fortsatt eier det laget.
Hva bør du lære
Tre ting er konkrete nok til å forsvare studietid, og én vanlig påstand er det ikke.
Abilities API, levert i 6.9. Registryet som lar plugins, kjerne og eksterne agenter oppdage hva et nettsted kan. Hook wp_abilities_api_init, kall wp_register_ability() med et namespaced navn som my-plugin/my-ability, og lever execute-callback pluss permission-callback med typede input- og output-skjemaer. Abilities er private som standard: show_in_rest er false med mindre du setter den. WordPress 7.0 la til klientside-motparten. Kjernen registrerer tre skrivebeskyttede abilities i wp-includes/abilities.php: core/get-site-info, core/get-user-info og core/get-environment-info. Sjekk navnene i trunk før du koder mot dem.
AI Client, mergert inn i 7.0. Provider-agnostisk infrastruktur: PHP-promptbygger, provider- og modellabstraksjon, delt credential-lagring, REST og JavaScript-API. SDK-en ligger i wp-includes/php-ai-client/; WordPress-limet i wp-includes/ai-client/. Connectors-skjermen: wp-admin/options-connectors.php. Praktisk konsekvens: du bundler ikke lenger API-nøkkel og HTTP-klient i hver plugin som vil snakke med en modell.
React, spesielt editor-datalaget. JSX er den enkle halvdelen. Halvdelen som avgjør om blokken din overlever samarbeid og den nye admin, er @wordpress/data, attributtskjemaer i block.json, og nå @wordpress/ui og @wordpress/theme for admin-flater som følger kjerne-tokens.
Og påstanden du bør droppe: det finnes ingen «kanonisk API» som gjør headless WordPress enkelt. Det finnes REST API, WPGraphQL som plugin, og nå Abilities API for agentvendte kall. Tre ulike kontrakter med tre ulike vedlikeholdshistorier - valget er fortsatt en arkitekturbeslutning du må ta selv.
WordPress bremser ikke, men sprinter heller ikke: én samarbeidsfunksjon levert, én utsatt, admin-redesign på token-stadiet, og en flerspråklig fase som ikke er begynt. Hvis du vil ha den lesningen anvendt på en konkret stack, gjør vi nettopp slike revisjoner som WordPress-utvikler.
