En merknad først: på skrivetidspunktet (april 2026) er WordPress 7.0 på det offentlige veikartet, men er ikke lansert. Konkrete funksjonslister, skjemaendringer og migreringstidsplaner som sirkulerer på nettet, også i innlegg som markedsfører seg som "komplett guide", er delvis prognose, delvis ønskeliste. Behandle alt som høres definitivt ut om 7.0 som spekulasjon inntil det lander i en release candidate publisert på den offisielle Make WordPress-bloggen og merket i core trac.
Det vi vet fra offentlige Make WordPress-innlegg: Fase 3-arbeidet med samarbeidsredigering pågår, dypere integrasjon mellom blokkredigereren og AI-leverandører diskuteres på core-møter, og Site Editor-malmodellen blir foredlet. Det vi ikke vet ennå: hvilke AI-funksjoner (om noen) lander i core kontra forblir plugins, det endelige PHP-minimumet, eller nøyaktig leveringsdato.
Hvis du planlegger arbeid som vil overlappe med 7.0-syklusen, er det ærlige å følge make.wordpress.org/core og core trac-billetter direkte, framfor å stole på tredjepartsspådommer. Det norske WordPress-miljøet er lite, men aktivt, og følger Make WordPress som kanonisk kilde på samme måte som internasjonale bidragsytere. Dette innlegget er en slik tredjepartsspådom; les det deretter.
Lær mer om profesjonell WordPress-utvikling hos WPPoland.
Hva som faktisk er kjent om 7.0 akkurat nå
Når man fjerner markedsføringsinnpakningen, er bildet smalere enn de fleste “komplett guide”-innlegg antyder.
Bekreftet i offentlig Make WordPress-diskusjon:
- Fase 3 av Gutenberg-veikartet er det røde temaet, med samarbeid og redaksjonell arbeidsflyt som de to områdene som har sett mest offentlige forslag og PR-er.
- AI-integrasjon prototypes i Gutenberg-pluginen og diskuteres på core-møter, men grensen mellom “leveres i core” og “forblir et plugin” er ikke avklart.
- Site Editor og pattern-systemet itereres, med foredlinger av malredigering og blokklåsing som lander først i 6.x-punktreleaser.
Ikke bekreftet, til tross for hyppige påstander:
- En konkret leveringsdato for 7.0. Lanseringsplaner glipper; behandle enhver enkelt dato som et mål, ikke en forpliktelse.
- En definitiv AI-funksjonsliste i core. Flere forslag finnes, inkludert leverandøruavhengige abilities og en connectors-UI, men forslag er ikke releaser.
- PHP-minimumsøkningen og nøyaktige deprecations. Disse avgjøres sent i syklusen.
For byråer og produktteam som leverer i 2026, er det praktiske takeawayet enklere enn enhver funksjonsliste: bygg på WordPress 6.x med fremtidskompatible mønstre (block themes, theme.json, REST API, Action Scheduler for bakgrunnsarbeid) slik at uansett hva 7.0 leverer, blir migreringen inkrementell snarere enn en omskriving.
AI i WordPress i dag, og hvor 7.0 kan gå
Den ærlige versjonen av “AI-funksjoner i WordPress 7.0” begynner med det som allerede fungerer i 6.x, fordi det er det ekte sider kjører.
Tilgjengelig i dag, i produksjons-WordPress:
- Yoast og Rank Math leverer begge AI-assisterte skrivehjelpere (titler, metabeskrivelser, interne lenkeforslag) bygget på tredjepartsmodell-API-er.
- Jetpack AI Assistant tilbyr generering i editor, oppsummering og oversettelse. Kvalitet varierer etter språk og prompt; norsk kvalitet er rimelig for utkast, men krever redaksjonell gjennomgang.
- Frittstående plugins for innholdsgenerering finnes i et bredt kvalitetsspenn; nyttige for utkast, farlige når koblet rett til publisering uten menneskelig gjennomgang.
- Automattic og bidragsteam kjører Fase 3-eksperimenter, inkludert samarbeidsredigering og editorside AI-kall, i Gutenberg-pluginen før enhver merge inn i core.
En pragmatisk arkitektur for å legge til AI på et WordPress-nettsted i dag, som sannsynligvis vil overleve hva enn 7.0 leverer:
- Eksponer et lite REST API-endepunkt per leverandør (OpenAI, Anthropic, Google, eller en selvhostet modell). Hold leverandørspesifikk kode bak ett grensesnitt slik at bytte av modell er en konfigurasjonsendring, ikke en omskriving.
- Kjør alt langsommere enn et par sekunder gjennom Action Scheduler, ikke en synkron forespørsel. Dette er det samme mønsteret WooCommerce bruker; det skalerer.
- Lagre API-nøkler som
wp-config.php-konstanter eller via en administrert hemmelighetsbutikk lastet ved oppstart. Plasser aldri levende nøkler i plugin-alternativer eller.env-filer som er committet til et repo. - Cache svar med nøkkel på hash av prompt pluss modellversjon. AI-kall er dyre og hyppig gjentatte.
Feilmoduser det er verdt å designe mot fra dag én:
- API-nøkkel-lekkasje gjennom plugin auto-oppdateringer eller backuper som inkluderer
wp-content-dumper. - Rate-limit-feil under trafikktopper, som stille degraderer editor-opplevelsen hvis det ikke finnes fallback.
- Hallusinerte fakta, sitater eller produktspesifikasjoner publisert uten et menneskelig gjennomgangstrinn. Kostnaden ved en dårlig side i søket er høyere enn kostnaden av enhver gjennomgangsarbeidsflyt.
Hvis 7.0 introduserer et core abilities- eller connectors-lag, gjelder de samme grensene: API-overflaten endres, feilmodusene gjør ikke. For etikk og redaksjonell ramme, se etikkguiden for AI-innhold for utgivere.
Hvordan forberede uten å gjette migreringen
Å skrive en trinnvis “hvordan migrere til 7.0”-guide før 7.0 er lansert, er uærlig. De versjonsspesifikke kommandoene, databaseoppgraderingsrutinen, de nye admin-innstillingene: ingen av det er endelig. Den som publiserer nøyaktige migreringstrinn i dag, fyller ut blanke felt med antakelser.
Det du kan gjøre nå er å redusere fremtidig migreringskostnad uavhengig av hvordan 7.0 ser ut. Arbeidet er utakknemlig og lønner seg ved hver release, ikke bare denne.
Auditer delene av stacken som mest sannsynlig brytes ved en stor oppgradering:
- Temaer som fortsatt bruker
functions.php-template-tagger i stedet for block themes. Konverter til block themes eller planlegg arbeidet. - Tilpassede Gutenberg-blokker bygget mot tidlige
@wordpress/scripts-versjoner. Pin og test mot siste stabile. - Page builders med eget rendering-lag. Disse er den vanligste årsaken til “vi kan ikke oppgradere”-gjeld.
- Tilpassede REST-endepunkter uten versjonering. Legg til
/v1/-namespacing nå slik at en fremtidig økning ikke er brytende.
Sett opp den kjedelige infrastrukturen som lar deg oppgradere raskt når 7.0 lanseres:
- Et staging-miljø som speiler produksjons-PHP-versjon, plugin-sett og innholdsvolum. Database-paritet betyr mer enn folk forventer.
- Automatiserte backuper med en testet gjenopprettingssti. En utestet backup er teater.
- Plugin- og temaoppdateringer som kjøres i jevnt tempo, ikke utsatt til neste store. Sider låst på 6.0 er låst fordi ingen oppdaterte 6.1 til 6.8.
- En kort liste over plugin-forfattere du stoler på, med e-postkontakter. Når 7.0 lanseres, vil du innen en uke vite hvilke av pluginene dine som er testet mot den.
Når 7.0 faktisk når RC på den offisielle lanseringskalenderen, er oppgraderingsstien den samme som har fungert for hver større WordPress-release: kjør på staging først, observer feilloggen, vent to til fire uker etter generell tilgjengelighet før du rører produksjon for kundenettsteder, og les det offisielle field guide-innlegget på Make WordPress før du antar at noen tredjepartsguide (denne inkludert) reflekterer det som faktisk ble levert.
Hva man skal gjøre inntil 7.0 faktisk lanseres
Inntil WordPress 7.0 når en tagget release på wordpress.org, er det mest nyttige ethvert team kan gjøre å ignorere prediksjonsinnleggene (denne inkludert) og følge primærkildene: Make WordPress core-bloggen, Gutenberg-utgivelsesnotater og trac-milepælen for 7.0.
For et eksisterende prosjekt som leverer i 2026, bygg på en aktuell 6.x-release med block themes, theme.json og REST API. Behandle AI som et integrasjonslag bak dine egne endepunkter, ikke som en funksjon du venter på at core leverer. Når 7.0 lander, blir migreringen et spørsmål om hvilke av dine tilpassede integrasjoner som kan erstattes av et core-API, ikke en omskriving.
Hvis du ønsker hjelp med å auditere en stack for oppgraderingsklarhet, gjør vårt WordPress-utviklingsteam det arbeidet for produksjonssider hver release-syklus.
