WordPress 7.0 Armstrong: KI-infrastruktur og Abilities API

Oppdatering, 23. mai 2026: WordPress 7.0 med kodenavnet Armstrong er lansert. Lanseringen lukker Fase 3 av Gutenberg-veikartet med grunnleggende AI-infrastruktur (Abilities API + AI Services Registry + AI Client), et modernisert dashboard, Command Palette overalt, egendefinert CSS på blokk-nivå og Icons-blokken. Sanntidssamarbeid ble tatt ut under RC-testing og er ikke med i 7.0. Denne guiden er oppsummeringen etter lansering; eldre veikartseksjoner nedenfor beholdes som historisk kontekst, ikke som en beskrivelse av hva som er aktivert på en 7.0-installasjon i dag.

WordPress 7.0 "Armstrong" ble lansert i mai 2026 etter en lenger enn vanlig release candidate-syklus. Lanseringen ble bygget av mer enn 900 bidragsytere. Hovedendringen er AI-infrastruktur i kjernen: Abilities API-overflaten for trygge admin-operasjoner, AI Services Registry for integrasjon med vertede modeller og WordPress AI Client som tredjepartsplugins nå standardiserer seg rundt. Et modernisert admin-dashboard, Command Palette overalt i wp-admin, egendefinert CSS på blokk-nivå og Icons-blokken ble også levert. Sanntidssamarbeid ble tatt ut av denne lanseringen under RC-testing og er ikke en del av oppgraderingen.

For en skarpere polemikk om hva 7.0 AI-overflaten betyr konkret for plugin-forfattere, se vårt innlegg om hvorfor en MCP-server i ditt WordPress-plugin er AI-trekket som overlever. For sikkerhetsimplikasjonen etter lansering, les vår analyse av GuardingWP State of WordPress Security 2026-rapporten, som setter den nye AI-nøkkeloverflaten i kontekst med 53-prosent-baseline for ikke-patchede CVE-er.

Følg make.wordpress.org/core og den offisielle wordpress.org/news-feeden for oppfølgende patch-utgivelser.

Lær mer om profesjonell WordPress-utvikling hos WPPoland.

#Lanseringsdato og kodenavn for WordPress 7.0

WordPress 7.0 med kodenavnet Armstrong ble lansert i mai 2026 etter en uvanlig lang release candidate-syklus (RC4 kom 14. mai 2026, endelig lansering fulgte kort etterpå). Navnet “Armstrong” fører videre WordPress-tradisjonen med å navngi store utgivelser etter jazzmusikere.

Hvis du planlegger en produksjonsoppgradering, er det tryggeste vinduet fortsatt to til fire uker etter endelig lansering, når den første patch-syklusen fanger kompatibilitetsproblemer rapportert av tidlige brukere.

#Hva som faktisk ble levert i 7.0 Armstrong

Dette er den bekreftede funksjonslisten fra wordpress.org-lanseringskunngjøringen, ikke den tidligere veikartintensjonen. Alt fra det eldre veikartet som mangler her, ble ikke levert i 7.0.

• AI-infrastruktur i kjernen. Abilities API for trygge admin-operasjoner via strukturerte intensjoner, AI Services Registry for tilkobling av vertede modell-leverandører (Anthropic, OpenAI, Vercel AI Gateway, selvhostet) og WordPress AI Client som tredjepartsplugins nå bygger mot. Dette er plattformendringen som definerer lanseringen.
• Command Palette overalt. Cmd-K / Ctrl-K åpner Command Palette på hver wp-admin-skjerm, ikke bare i blokkredigereren. Tastetrykk-overflaten for power-brukere er nå førsteklasses.
• Egendefinert CSS på blokk-nivå. Hver blokk kan bære sin egen CSS, begrenset til den blokken. Fjerner en langvarig grunn til å gå ned til et custom-tema.
• Icons-blokk. En innebygd blokk for innebygging av SVG-ikoner fra et kuratert bibliotek, med temabevisste fargetokens.
• Modernisert dashboard. Oppfriskede admin-landingsoverflater, med de agentic-AI-eksperimentene synlige bak et feature flag.
• PHP 7.4 som minimum kjøretid. Sider som fortsatt kjører eldre PHP må oppgradere servermiljøet sitt før de oppdaterer til 7.0.
• Mer enn 900 bidragsytere. WP Charitable Product Manager David Bisset takket bidragsyterne og “ektefellene, partnerne, familiene, kjæledyrene, mestringsmekanismene og veilederne deres som støttet dem”, som er den ærligste linjen som er skrevet om en stor WordPress-lansering på flere år.

Hva som ikke ble levert og ikke lenger forventes på 7.0-linjen:

• Sanntidssamarbeid ble tatt ut av denne lanseringen etter release candidate-testing. Den tidligere veikart-beskrivelsen lenger ned i denne guiden beholdes som historisk kontekst.

#Sikkerhet: beskytt AI-leverandorens API-nokler fra dag en

Patchstack-grunnlegger Oliver Sild postet offentlig på X rundt lansering: “there will be an absolute rush by hackers to steal API keys.” Risikoen er konkret. En kompromittert wp-admin-legitimasjon på en 7.0-installasjon lar ikke lenger bare en angriper endre innhold; det lar dem også tømme en fire- eller femsifret månedlig token-regning mot AI-leverandøren din før fakturaen rekker det. Justin Nealey flagget separat at WP AI Client ikke har innebygd throttle, og flere plugins som deler en nøkkel kan blåse gjennom token-grensen på under et minutt.

Kontrolloverflaten som skal brukes er enkel og den samme kontrolloverflaten et finansteam ville brukt på enhver nyutstedt fakturerbar legitimasjon:

• Skoper API-nøkler per connector, ikke per nettsted. En nøkkel per leverandør per connector. Roter i en publisert kadens.
• Bruk rate-limits på gatewayen, ikke i pluginet. Hvis leverandøren din støtter rate-limits per nøkkel (Anthropic, OpenAI, Vercel AI Gateway støtter alle det), sett dem lavt nok til at avvikende forbruk er synlig mot en faktureringssyklus.
• Varsle om avvikende token-forbruk innenfor syklusen, ikke ved månedslutt. De fleste leverandører eksponerer en faktureringsdags-API; koble den til overvåkingen din.
• Audit-logg connector-bruken på WordPress-siden. Abilities API eksponerer operasjons-ID-er; logg dem i en separat strøm fra vanlig wp-admin audit-logg.

NSM har de siste årene flagget tredjeparts-legitimasjonseksponering som en av de mest underestimerte angrepsvektorene mot norske leverandørkjeder; behandle AI-nøkler i wp-admin som tredjeparts-leverandøradgang underlagt sikkerhetsloven og logg deretter. Disse kobles direkte til forsyningskjedekontrollene som allerede er påkrevet av NIS2 artikkel 21 paragraf 2 bokstav d for enheter i virkeområdet. Behandle den nye AI-overflaten som en ny klasse av tredjeparts ICT-avtale, og registrer den deretter.

#WordPress 7.0 veikart

WordPress 7.0 ligger pa slutten av Fase 3 av Gutenberg-prosjektets firefase-plan:

Fase 4 vil bringe innebygde flerspråkelige funksjoner, noe som betyr at WordPress endelig vil håndtere innholdsoversettelse på kjerne-nivået i stedet for å stole på plugins som WPML eller Polylang. For byråer som forvalter flerspråkelige sider i dag, er dette funksjonen å følge med på for post-7.0-veikartet.

#AI i WordPress nå som 7.0 er lansert

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.
• 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 en:

• 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

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:

• 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. Du vil innen en uke vite hvilke av pluginene dine som er testet mot 7.0.

Oppgraderingsstien er 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 i 7.0-lanseringsuken

Med 7.0 levert er det nyttige arbeidet operativt: staging-oppgradering, plugin-kompatibilitetssjekker, WooCommerce- og LMS-flyt-tester, og en tilbakerullingsplan for produksjon.

Følg Make WordPress core-bloggen, Gutenberg-utgivelsesnotater og trac-milepælen for siste field guide-endringer. For et eksisterende prosjekt på 6.x, behold block themes, theme.json og REST API som fremtidskompatibel baseline.

Hvis du ønsker hjelp med å auditere en stack for oppgraderingsklarhet, gjør vårt WordPress-utviklingsteam det arbeidet for produksjonssider hver release-syklus.