Fremtiden for WordPress 2027: Datafrigjøring og det nye admin-panelet

WordPress 7.0 “Armstrong” kom 20. mai 2026, og WordPress 7.1 “Mary Lou” 19. august 2026. Det offisielle veikartet planlegger 7.2 til 10. desember 2026 og sier at datoene “bare er ment for grov planlegging” (egen oversettelse). En prognose for 2027 kan dermed bygge på et år med faktiske utgivelser: det som kom, det som ble trukket i siste liten, og det som ikke har noen dato.

Denne artikkelen holder de tre tingene fra hverandre. Hver prognose under er meningen til vårt WordPress-utviklingsteam, og hver av dem viser til kunngjøringen eller Core-innlegget den bygger på. Der prosjektet ikke har publisert noe, sier vi det i stedet for å fylle hullet.

#Hva WordPress 7.0 og 7.1 leverte i 2026

To hovedutgivelser kom i år. Tabellen viser det som betyr noe for 2027, basert på kunngjøringen av 7.0 og WordPress 7.1 Field Guide.

Field Guide for 7.1 teller mer enn 310 Core Trac-saker, over 100 av dem forbedringer og mer enn 180 feilrettinger. Fonthåndteringen i 7.0 fungerer med blokk-, hybrid- og klassiske temaer, noe som betyr noe for temadelen lenger ned.

#Hva som ikke kom: sanntidssamarbeid og React 19

Veikartet beskriver Gutenberg fase 3 som “sentrert rundt samarbeidsredigering og arbeidsflyter” og lover “sanntidssamarbeid og smidigere publiseringsprosesser” (egen oversettelse, WordPress-veikartet). Det er hovedfunksjonen i fasen, og den har bommet på to utgivelser på rad.

• 7.0: kunngjøringen nevner ikke sanntidssamarbeid.
• 7.1: innlegget Roadmap to 7.1 hadde fortsatt åpne spørsmål om omfang (full funksjon eller bare den underliggende arkitekturen) og om lagringsmekanismen. En rekrutteringsinnsats for samarbeidsredigering skaffet testere via Gutenberg-utvidelsen. Field Guide sier etterpå at funksjonen “ble grundig testet og fikk mange tilbakemeldinger i WordPress 7.1-syklusen, men er ikke slått på i den endelige utgivelsen” (egen oversettelse).
• React 19: oppgraderingen fra React 18 ble også utsatt til etter 7.1 og fortsetter som et eksperiment i Gutenberg-utvidelsen.

Utgivelseslederne for 7.1 var åpne om avveiningen. Field Guide siterer Anne McCarthy: “noen ganger er det vi ikke legger til, mer verdifullt enn det vi legger til” (egen oversettelse).

Vår prognose: samtidig redigering i sanntid kommer i kjernen i løpet av 2027, etter minst én syklus til i Gutenberg-utvidelsen. Inntil da gjelder innleggslåsen, så to personer kan ikke redigere samme innlegg samtidig. Team som trenger samtidig redigering i dag, kan teste det i utvidelsen på et staging-nettsted, aldri i produksjon.

#Vil det nye WordPress-adminpanelet erstatte wp-admin

Venstremenyen i wp-admin har vært med oss siden WordPress 2.7 (2008). Oppsummeringen av State of the Word 2023 sa at redesignet av admin “vil hente ideer fra Site Editor og etter hvert la brukerne forme adminopplevelsen etter egne behov” (egen oversettelse). Det er den uttalte retningen, og den har ingen dato.

Det som faktisk er levert, kommer gradvis. 7.0 ga et oppfrisket dashbord og Command Palette. Innlegget Roadmap to 7.1 lister en Design- og Identity-skjerm for nettstedets identitetsinnstillinger, en Site Editor som følger fargeskjemaet i admin, finpuss av adminlinjen og arbeid med å flytte DataViews over på nye byggeklosser fra Design System.

#Dashbord og Site Editor i ett grensesnitt

Vi forventer at skillet mellom “Dashbordet” og “Site Editor” fortsetter å viskes ut, skjerm for skjerm, etter hvert som DataViews erstatter de gamle listetabellene. Dette er en prognose, ikke en kunngjort funksjon:

• Kontekstuell redigering: du går ikke til “Innstillinger” for å endre nettstedets tittel. Den planlagte Identity-skjermen er et første steg: den samler identitetsinnstillingene på ett sted.
• JavaScript først: vi forventer at flere adminskjermer oppfører seg som en Single Page Application, med umiddelbare overganger og uten full omlasting ved lagring. Site Editor fikk allerede ruting og en wordpress/boot-pakke i 7.0 for utvidelser som bygger egne Site Editor-sider.
• Tilpasning: byråer kan kuratere adminopplevelsen innebygd, låse bestemte blokker og merkevaretilpasse grensesnittet uten å hacke functions.php. For team som overleverer nettsteder til ikke-tekniske redaktører, er det den delen som teller i hverdagen.

Vårt veddemål for 2027: den klassiske sidemenyen finnes fortsatt ved årsslutt, bare med færre skjermer bak seg som rendres på den gamle måten.

#React- og REST API-ferdigheter for WordPress-utviklere

Utviklere som har bygget karrieren på PHP-hooks for admintilpasning, trenger en bredere verktøykasse. React og WordPress REST API går fra “kjekt å ha” til grunnleggende. PHP-siden beholder verdien: 7.0 la til registrering av blokker og mønstre kun med PHP, så serverutviklere kan levere blokker uten et byggesteg for JavaScript.

Les mer om profesjonell WordPress-utvikling hos WPPoland.

#Hva WordPress Data Liberation-prosjektet betyr

På State of the Word 2023 i Madrid 11. desember 2023 presenterte Matt Mullenweg Data Liberation som et ekstra fokus for 2024, “med mål om å gjøre import fra andre plattformer til WordPress så friksjonsfri som mulig” (egen oversettelse, offisiell oppsummering). Oppsummeringen legger til at initiativet “skal jobbe med migrering med ett klikk og eksportformatet fra WordPress” (egen oversettelse).

Data Liberation-siden beskriver nå fem faser:

Fase 4 i Data Liberation (synkronisering av nettsteder) er noe annet enn fase 4 i Gutenberg (flerspråklighet). De to veikartene nummererer fasene hver for seg.

For fase 3 nevner siden Studio fra WordPress.com og den åpne agent-utvidelsen for datafrigjøring, med egne verktøy for GoDaddy Websites & Marketing, Hostinger Website Builder, HubSpot, Shopify, Squarespace, Webflow, Weebly og Wix.

#Hvordan WordPress unngår innlåsing hos leverandøren

SaaS-plattformer har lenge gjort det tungvint å ta med seg innholdet. Data Liberation går motsatt vei:

• Eksportformat: fase 2 er arbeidet med strukturert import og eksport. Vår prognose er at innen utgangen av 2027 blir flytting av et helt nettsted (innhold, medier og design) mellom WordPress-verter et rutinesteg, i stedet for oppstykkede WXR-filer som mister bilder og metadata.
• Import fra hvor som helst: Data Liberation handler ikke bare om å dra. Verktøyene i fase 3 retter seg mot flytting til WordPress fra lukkede nettstedsbyggere.
• Hvorfor: ved å gjøre det enkelt å dra, gir WordPress folk en grunn til å stole på det og bli.

#Data Liberation og WordPress i store virksomheter

For store organisasjoner fjerner en dokumentert vei ut en av standardinnvendingene mot WordPress: risikoen for innlåsing. En CTO eller virksomhetsarkitekt kan godkjenne WordPress vel vitende om at en ren utgang finnes. Vår mening er at dette hjelper bruken i virksomheter mer enn det skader den.

#Vil blokktemaer erstatte klassiske WordPress-temaer

Hva er et tema i 2027? For nye prosjekter nesten helt sikkert et blokktema. For eksisterende nettsteder tvinger ikke prosjektet frem byttet: fonthåndteringen i 7.0 støtter klassiske temaer, og Field Guide noterer at forslaget om å skjule Classic-blokken fra innsetteren i 7.1 ble reversert, så Classic-blokken er fortsatt tilgjengelig.

#theme.json, globale stiler og blokkmønstre

• Globale stiler: den visuelle identiteten til et nettsted defineres i theme.json. Farger, typografi, avstander og skygger ligger i én deklarativ konfigurasjonsfil. 7.1 la til responsive stiler per skjermstørrelse, i Global Styles og på enkeltblokker, så en vanlig grunn til egen CSS forsvinner.
• Mønsterbiblioteker: et “tema” blir i økende grad en kuratert samling av blokkmønstre. 7.0 lar deg også koble et mønster fra originalen og redigere det isolert.
• Færre barnetemaer: barnetemaer trengs ikke lenger for å overstyre stiler. Du bruker Global Styles-grensesnittet og eksporterer endringene som en variasjon, noe som også fjerner en vanlig feilkilde: konflikter mellom foreldre- og barnetema.

Vår prognose: klassiske PHP-temaer fortsetter å fungere hele 2027, og nye byråprosjekter starter som blokktemaer som standard.

#Hvordan byråer tjener penger uten premiumtemaer

Byråer som solgte ferdigpakkede premiumtemaer, trenger en annen forretningsmodell. Vi forventer at verdien flytter seg til:

1. Designsystemer: konsistente, skalerbare mønsterbiblioteker bygget for en bestemt merkevare.
2. Merkevareoversettelse: å gjøre en merkevareidentitet om til en egen theme.json-konfigurasjon.
3. Migrering og optimalisering: å flytte kunder fra eldre PHP-temaer til moderne blokkarkitektur.

#KI-funksjoner som allerede er i WordPress-kjernen

KI er ikke lenger bare utvidelsesterritorium. Veikartet har et mål for 2026 om å “bevisst bygge KI inn i hele WordPress-opplevelsen for å forenkle produksjon, arbeidsflyter og bidrag”, med “retningslinjer for hele prosjektet som ivaretar åpenhet, brukerkontroll og WordPress sine verdier” (egen oversettelse, veikartet).

Dette finnes i kjernen i dag:

• Abilities API: introdusert i WordPress 6.9. Field Guide sier at 7.1 gjør abilities “enklere å oppdage, eksponere, validere og integrere med eksterne klienter” (egen oversettelse), med filtrering i wp_get_abilities(), hooks for kjørelivssyklusen og ett felles flagg for offentlig eksponering.
• AI Client: 7.0 la til en AI Client som lar WordPress kommunisere med generative KI-modeller. Tilkoblinger til eksterne leverandører styres på Connectors-skjermen, som har tre forhåndsoppsett og lar deg legge til egne.
• Client-Side Abilities: JavaScript-motstykket til Abilities API, med eget grensesnitt og kobling til Command Palette.

Skrivefunksjonene folk forbinder med “KI i WordPress”, ligger i en valgfri KI-utvidelse, ikke i kjernen. Ifølge kunngjøringen av 7.0 gir den bildegenerering og bilderedigering, forslag til titler og utdrag og forslag til alternativ tekst. Forslag til alternativ tekst hjelper tilgjengeligheten bare hvis en redaktør går gjennom dem, så behandle dem som utkast.

#Hva KI-veikartet peker mot i 2027

Innlegget Roadmap to 7.1 listet strømming av generering og embeddings for AI Client, og beskrev embeddings som en måte å representere innhold “som vektorer for å muliggjøre betydningsbasert søk på tvers av nettstedet” (egen oversettelse). Det listet også Guidelines (redaksjonelle regler koblet til KI-verktøyene, med import og eksport mellom nettsteder) og autentisering for Connectors utover API-nøkler.

Vår prognose: betydningsbasert nettstedssøk bygget på embeddings blir i 2027 den første KI-funksjonen vanlige besøkende legger merke til. Modelleverandørene forblir eksterne, så leverandørens regning og databehandleravtalen blir en del av omfanget i hvert KI-prosjekt.

#KI-assistert oversettelse i blokkredigereren

Hvis Gutenberg fase 4 (flerspråklighet) en dag møter AI Client, er assistert oversettelse i redigereren det åpenbare bruksområdet: en redaktør skriver på ett språk og får utkast på andre som trenger menneskelig gjennomgang. Ingen utgivelse i 2026 leverer dette, så det er fortsatt en prognose.

#Innebygd flerspråklighet i WordPress-kjernen uten WPML

I mange år har vi trengt WPML eller Polylang. Veikartet har flerspråklighet som Gutenberg fase 4, beskrevet bare som “kjerneimplementering for flerspråklige nettsteder” (egen oversettelse). Siden i utviklerhåndboken om flerspråklig WordPress sier fortsatt: “WordPress støtter i dag ikke en tospråklig eller flerspråklig blogg uten tillegg” (egen oversettelse).

Verken 7.0 eller 7.1 inneholder arbeid med flerspråklighet i kjernen. Det nærmeste i Roadmap to 7.1 er bredere Unicode-støtte for e-postadresser.

#Oversettelser i databaseskjemaet til kjernen

Vi forventer at fase 4 starter først når samarbeidet fra fase 3 er på plass, noe som legger innebygd flerspråklighet etter 2027. Når det kommer:

• Standardisert databaseskjema: kjernen vil støtte oversettelser offisielt, uten utvidelsestabeller som WPML sin wp_icl_translations hengt på ved siden av.
• Ytelse: innebygd spørringsstøtte vil fjerne de ekstra spørringene og joinene som oversettelsesutvidelser legger til i dag.
• Virkning: et stort segment av utvidelsesmarkedet vil krympe. For norske virksomheter som publiserer på bokmål, nynorsk og engelsk, vil ett oppsett støttet av kjernen være en reell forenkling.

#Flerspråklig innholdsstrategi på ett WordPress-nettsted

Inntil da er det praktiske valget fortsatt en utvidelse eller et Multisite-nettverk med ett nettsted per språk. Ett WordPress-nettsted kan i dag levere flere språk med rene URL-er og hreflang, men via en utvidelse. Hvis synlighet i søk på flere markeder er viktig for deg, se vår tjeneste for GEO- og LLMO-optimalisering.

#Hvordan WordPress-byråer og utvidelser endrer seg innen 2027

#Hva WordPress-byråer vil tilby i 2027

“Installer WordPress og velg et tema” slutter å være en tjeneste noen betaler for. Vi forventer at vellykkede byråer konsentrerer seg om:

• Løsningsarkitektur: å velge riktig blanding av kjerne, utvidelser og eksterne tjenester for hver forretningssak.
• KI-integrasjon: å registrere abilities, konfigurere Connectors og skrive Guidelines for kundens egen redaksjonelle arbeidsflyt.
• Global innholdsstrategi: å drive flerspråklige nettsteder med dagens utvidelser og samtidig planlegge for en kjerneløsning senere.
• Ytelse i skala: å holde store nettsteder innenfor gode Core Web Vitals under høy last.

#Hvilke WordPress-utvidelser mister betydning

Først mister utvidelser betydning som dupliserer det som har flyttet inn i kjernen: ikonsett (SVG Icon API i 7.1), fonthåndterere (fonthåndteringen i 7.0), tillegg for å vise eller skjule blokker per enhet og enkle KI-koblinger. De som trolig klarer seg godt, tilbyr virkelig spesialisert funksjonalitet: CRM-integrasjoner, egen forretningslogikk og nisjeverktøy kjernen aldri vil dekke. Flerspråklige utvidelser forblir nødvendige hele 2027.

#Hvordan forberede WordPress-nettstedet ditt på 2027

Ingenting av dette krever at du venter på en utgivelse. Disse stegene lønner seg uansett hvordan veikartet ender:

1. Bruk blokktemaer i nye prosjekter: hvis du fortsatt kjører et klassisk PHP-tema, planlegg overgangen til et blokktema (FSE). Jo lenger du venter, jo mer egen kode må du ta med.
2. Test iframe-redigereren: 7.1 gjorde innleggsredigereren iframe-basert på alle nettsteder, også de som registrerer eldre metabokser. Sjekk egne redigeringsstiler og metaboks-utvidelser på staging.
3. Ta i bruk theme.json og responsive stiler: definer stilene til nettstedet i theme.json i stedet for egen CSS.
4. Registrer abilities for egne funksjoner: hvis du vedlikeholder en utvidelse som tilbyr handlinger, er Abilities API veien KI-klienter og Command Palette vil nå dem.
5. Planlegg for flerspråklighet: strukturer innholdet med tanke på oversettelse, så en senere overgang fra WPML eller Polylang til en kjerneløsning blir enklere.
6. Prøv sanntidssamarbeid i Gutenberg-utvidelsen på staging: da vet du før utgivelsen om det passer den redaksjonelle arbeidsflyten din.

#Hvor du følger WordPress-veikartet

Tre kilder svarer på de fleste spørsmål før de blir til rykter. Make WordPress Core-bloggen publiserer et “Roadmap to”-innlegg ved starten av hver syklus og en Field Guide ved release candidate, og Field Guide er den autoritative listen over hva som kom og hva som ble trukket. Veikartsiden gir oversikten over fasene og planlagte datoer. Foredrag fra WordCamp Europe og WordCamp US publiseres på WordPress.tv, og de er en gratis måte å følge hvor kjernebidragsyterne tar disse prosjektene.

#Konklusjon

I 2027 forventer vi at WordPress er mindre et “bloggverktøy” og mer et operativsystem for nettet: grunnlaget for dataeierskap, brukerhåndtering, abilities og blokkrendering som alt annet bygges på.

For utviklere er den praktiske konsekvensen å bygge blokk-først: egne blokker registrert via block.json eller ren PHP-registrering, blokktemaer med theme.json, handlinger eksponert som abilities og innhold lagret i strukturer som importørene og eksportørene i Data Liberation kan lese. Kode bygget rundt den klassiske redigereren og kortkoder er den delen som mest sannsynlig må skrives om, selv om kjernen fortsatt støtter den.

Fremtiden er åpen. Er du klar? Les mer om profesjonell WordPress-utvikling hos WPPoland.