Fremtiden til WordPress: veikart for 2026-2030 og fremover

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.

#Har WordPress sanntidssamarbeid i 2026

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.

#Når får WordPress flerspråklig støtte i kjernen

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_NO blir ugyldig innhold den dagen oversettelseslaget flytter seg.
• Behandle WPML og Polylang som langsiktige avhengigheter, ikke stopgap. De vil overleve dette veikartpunktet.

#Kan Data Liberation migrere et nettsted til WordPress

Prosjektsiden på wordpress.org/data-liberation ble publisert 6. desember 2023 og navngir fem faser eksplisitt:

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.

#Hva er endret i adminpanelet i WordPress 7.1

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 en ThemeProvider-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:

1. Propen __next40pxDefaultSize er 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.
2. wp_get_tooltip() og wp_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.
3. 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 en WordPress-utvikler lære i 2026

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. Det kjernen ikke har, er sidegenerering fra en beskrivelse, innholdsoptimalisering eller prediktive oppdateringer. Det er fortsatt plugin-territorium.

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, og valget er fortsatt en arkitekturbeslutning du må ta selv.

#Hvordan WordPress-veikartet påvirker plugins

Veikartet berører ikke bare kjernen, det endrer hvordan plugins lener seg på plattformen. Det lønner seg å skille det som allerede krever handling fra det som fortsatt er betinget.

#Må plugins tilpasses sanntidssamarbeid

Så lenge samtidig redigering ikke er tilbake i kjernen, tvinger ingenting deg til å bygge om en plugin. Det du kan gjøre i dag, fordi det lønner seg også uten samarbeid, er å la tabellredigerere, skjemabyggere og SEO-verktøy holde tilstanden sin i blokkattributter i stedet for i lokal React-tilstand. Det er samme krav som testkallet for 7.0 Beta 1 stilte, og det er også det som får angre og revisjoner til å oppføre seg riktig.

#Må plugins tilpasses flerspråklighet i kjernen

Her er det ingenting å forberede mot en API, fordi det ikke finnes noen API. Det eneste konkrete steget er å ikke låse seg: hold oversettelsesidentitet i meta eller en taksonomi, og hold språkstrenger ute av blokkattributter. Enhver liste over standardiserte oversettelses-API-er i kjernen er per i dag oppdiktet.

#Hva skjedde med sanntidssamarbeid etter WordPress 7.0

Fjerningen avsluttet ikke arbeidet, den flyttet det ut av utgivelsesgrenen. 3. juni 2026 kunngjorde kjerneteamet et testprogram for samarbeidsredigering i 7.1: tidlige brukere kjører siste versjon av Gutenberg-pluginen, slår på samarbeid under Innstillinger > Skriving og rapporterer i Slack-kanalen #collaborative-editing-outreach gjennom 7.1-syklusen, minst til 18. august 2026. Innlegget fra Hosting-teamet samme dag ba webhoteller invitere sine egne kunder, slik at funksjonen blir testet på mange serveroppsett i stedet for ett. Det henger sammen med grunnene til at den ble fjernet: serverbelastning og minneeffektivitet avhenger av hostingen.

To repositorier viser hvor utviklingen gikk videre. Gutenberg Sync Engines, opprettet 10. august 2026, beskriver seg som en sammenligning av mulige synkmotorer og transporter for sanntidssamarbeid i Gutenberg. Feature-pluginen Presence API, oppført på wordpress.org siden 21. juli 2026 og med krav om WordPress 7.0, sporer hvilke brukere som er innlogget, hvilken admin-skjerm de er på og hvilke innlegg de redigerer. Dataene går gjennom Heartbeat API til en egen tabell, wp_presence, med 150 sekunders TTL, og innleggslåser lagres der i stedet for i post meta, så en holdt lås gjør ikke lenger hurtigbufrede innleggsspørringer utdaterte. Versjon 0.18.1 kom 13. oktober 2026.

Møtereferatet for Presence API 12. oktober 2026 setter listen for et kjerneforslag: tre eksterne prosjekter som bruker API-et og åtte uker uten en bakoverinkompatibel endring, regnet fra versjon 0.17.0, som gir 3. desember som tidligste dato. Innleggslåser er den første brukeren, og Gutenberg Sync Engines er det første eksterne prosjektet. Ingen WordPress-versjon er nevnt som mål. Hvis pluginen din leser eller skriver post meta _edit_lock, er dette arbeidet du bør følge, fordi innleggslåser er nettopp det pluginen flytter.

#Når kommer WordPress 7.2

Kallet etter frivillige 12. august 2026, publisert av Jeffrey Paul, foreslår 9. desember 2026 som endelig utgivelsesdato og kaller den fleksibel. Alfa-utviklingen startet 10. august 2026. De foreslåtte milepælene går i ukessteg:

Veikartsiden, sist endret 20. august 2026, oppgir 10. desember 2026 for 7.2 og skriver at de anslåtte datoene bare er til grov planlegging. Den sier også at nye funksjoner fryses en måned før en utgivelse. Kallet navngir roller (release lead, utgivelseskoordinering, tech leads, triage lead, test lead), men ingen funksjoner. Per midten av oktober finnes det ikke noe publisert omfang for 7.2, så alt som presenteres som nytt i 7.2 før Beta 1, er gjetning. For planlegging i et byrå er release candidates de nyttige datoene: test kundenettsteder og egne blokker mot RC1 i uken fra 17. november, ikke på utgivelsesdagen.

#Hvordan forberede plugins og blokker for WordPress 7.1

Uten å gjette på fremtiden er dette det du kan gjøre med det som er publisert:

1. Deklarer blokkattributter i block.json med type, og skriv dem med setAttributes. Det er betingelsen testkallet selv satte for at en blokk skal synkronisere.
2. Registrer funksjonene dine med Abilities API i stedet for å finne opp et eget REST-endepunkt for en agent å kalle, og la show_in_rest stå på false til du vet hvem som bruker den abilityen.
3. Bruk --wpds--tokenene i egne admin-skjermer, i stedet for å hardkode farger og radier som vil drive fra hverandre i neste utgivelse.
4. Sjekk avstandene i admin-skjermene dine mot 40px-kontrollene, fordi __next40pxDefaultSize ikke lenger endrer noe.

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.