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 pa blokk-niva 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 pa 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 na standardiserer seg rundt. Et modernisert admin-dashboard, Command Palette overalt i wp-admin, egendefinert CSS pa blokk-niva og Icons-blokken ble ogsa 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 vart innlegg om hvorfor en MCP-server i ditt WordPress-plugin er AI-trekket som overlever. For sikkerhetsimplikasjonen etter lansering, les var analyse av GuardingWP State of WordPress Security 2026-rapporten, som setter den nye AI-nokkeloverflaten i kontekst med 53-prosent-baseline for ikke-patchede CVE-er.

Folg make.wordpress.org/core og den offisielle wordpress.org/news-feeden for oppfolgende patch-utgivelser.

Lar 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 etterpa). Navnet “Armstrong” forer videre WordPress-tradisjonen med a navngi store utgivelser etter jazzmusikere.

Hvis du planlegger en produksjonsoppgradering, er det tryggeste vinduet fortsatt to til fire uker etter endelig lansering, nar den forste 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-lanseringskunngjoringen, 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-leverandorer (Anthropic, OpenAI, Vercel AI Gateway, selvhostet) og WordPress AI Client som tredjepartsplugins na bygger mot. Dette er plattformendringen som definerer lanseringen.
• Command Palette overalt. Cmd-K / Ctrl-K apner Command Palette pa hver wp-admin-skjerm, ikke bare i blokkredigereren. Tastetrykk-overflaten for power-brukere er na forsteklasses.
• Egendefinert CSS pa blokk-niva. Hver blokk kan baere sin egen CSS, begrenset til den blokken. Fjerner en langvarig grunn til a ga 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 kjoretid. Sider som fortsatt kjorer eldre PHP ma oppgradere servermiljoet sitt for de oppdaterer til 7.0.
• Mer enn 900 bidragsytere. WP Charitable Product Manager David Bisset takket bidragsyterne og “ektefellene, partnerne, familiene, kjaeledyrene, mestringsmekanismene og veilederne deres som stottet dem” - som er den arligste linjen som er skrevet om en stor WordPress-lansering pa flere ar.

Hva som ikke ble levert og ikke lenger forventes pa 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 pa X rundt lansering: “there will be an absolute rush by hackers to steal API keys.” Risikoen er konkret. En kompromittert wp-admin-legitimasjon pa en 7.0-installasjon lar ikke lenger bare en angriper endre innhold; det lar dem ogsa tomme en fire- eller femsifret manedlig token-regning mot AI-leverandoren din for fakturaen rekker det. Justin Nealey flagget separat at WP AI Client ikke har innebygd throttle, og flere plugins som deler en nokkel kan blase gjennom token-grensen pa under et minutt.

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

• Skoper API-nokler per connector, ikke per nettsted. En nokkel per leverandor per connector. Roter i en publisert kadens.
• Bruk rate-limits pa gatewayen, ikke i pluginet. Hvis leverandoren din stotter rate-limits per nokkel (Anthropic, OpenAI, Vercel AI Gateway stotter alle det), sett dem lavt nok til at avvikende forbruk er synlig mot en faktureringssyklus.
• Varsle om avvikende token-forbruk innenfor syklusen, ikke ved manedslutt. De fleste leverandorer eksponerer en faktureringsdags-API; koble den til overvakingen din.
• Audit-logg connector-bruken pa WordPress-siden. Abilities API eksponerer operasjons-ID-er; logg dem i en separat strom fra vanlig wp-admin audit-logg.

NSM har de siste arene flagget tredjeparts-legitimasjonseksponering som en av de mest underestimerte angrepsvektorene mot norske leverandorkjeder; behandle AI-nokler i wp-admin som tredjeparts-leverandoradgang underlagt sikkerhetsloven og logg deretter. Disse kobles direkte til forsyningskjedekontrollene som allerede er pakrevet av NIS2 artikkel 21 paragraf 2 bokstav d for enheter i virkeomradet. 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 flersprakelige funksjoner, noe som betyr at WordPress endelig vil handtere innholdsoversettelse pa kjerne-nivaet i stedet for a stole pa plugins som WPML eller Polylang. For byraer som forvalter flersprakelige sider i dag, er dette funksjonen a folge med pa for post-7.0-veikartet.

#AI i WordPress na som 7.0 er lansert

Den arlige versjonen av “AI-funksjoner i WordPress 7.0” begynner med det som allerede fungerer i 6.x, fordi det er det ekte sider kjorer.

Tilgjengelig i dag, i produksjons-WordPress:

• Yoast og Rank Math leverer begge AI-assisterte skrivehjelpere (titler, metabeskrivelser, interne lenkeforslag) bygget pa tredjepartsmodell-API-er.
• Jetpack AI Assistant tilbyr generering i editor, oppsummering og oversettelse. Kvalitet varierer etter sprak og prompt.
• Frittstaende plugins for innholdsgenerering finnes i et bredt kvalitetsspenn; nyttige for utkast, farlige nar koblet rett til publisering uten menneskelig gjennomgang.
• Automattic og bidragsteam kjorer Fase 3-eksperimenter, inkludert samarbeidsredigering og editorside AI-kall, i Gutenberg-pluginen for enhver merge inn i core.

En pragmatisk arkitektur for a legge til AI pa et WordPress-nettsted i dag, som sannsynligvis vil overleve hva enn 7.0 leverer:

• Eksponer et lite REST API-endepunkt per leverandor (OpenAI, Anthropic, Google, eller en selvhostet modell). Hold leverandorspesifikk kode bak ett grensesnitt slik at bytte av modell er en konfigurasjonsendring, ikke en omskriving.
• Kjor alt langsommere enn et par sekunder gjennom Action Scheduler, ikke en synkron forespørsel. Dette er det samme monsteret WooCommerce bruker; det skalerer.
• Lagre API-nokler som wp-config.php-konstanter eller via en administrert hemmelighetsbutikk lastet ved oppstart. Plasser aldri levende nokler i plugin-alternativer eller .env-filer som er committet til et repo.
• Cache svar med nokkel pa hash av prompt pluss modellversjon. AI-kall er dyre og hyppig gjentatte.

Feilmoduser det er verdt a designe mot fra dag en:

• API-nokkel-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 darlig side i soket er hoyere enn kostnaden av enhver gjennomgangsarbeidsflyt.

Hvis 7.0 introduserer et core abilities- eller connectors-lag, gjelder de samme grensene: API-overflaten endres, feilmodusene gjor ikke. For etikk og redaksjonell ramme, se etikkguiden for AI-innhold for utgivere.

#Hvordan forberede uten a gjette migreringen

Det du kan gjore na er a redusere fremtidig migreringskostnad uavhengig av hvordan 7.0 ser ut. Arbeidet er utakknemlig og lonner 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 arsaken til “vi kan ikke oppgradere”-gjeld.
• Tilpassede REST-endepunkter uten versjonering. Legg til /v1/-namespacing na slik at en fremtidig okning ikke er brytende.

Sett opp den kjedelige infrastrukturen som lar deg oppgradere raskt:

• Et staging-miljo 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 kjores i jevnt tempo, ikke utsatt til neste store. Sider last pa 6.0 er last fordi ingen oppdaterte 6.1 til 6.8.
• En kort liste over plugin-forfattere du stoler pa, 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 storre WordPress-release: kjor pa staging forst, observer feilloggen, vent to til fire uker etter generell tilgjengelighet for du rorer produksjon for kundenettsteder, og les det offisielle field guide-innlegget pa Make WordPress for du antar at noen tredjepartsguide (denne inkludert) reflekterer det som faktisk ble levert.

#Hva man skal gjore 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.

Folg Make WordPress core-bloggen, Gutenberg-utgivelsesnotater og trac-milepalen for siste field guide-endringer. For et eksisterende prosjekt pa 6.x, behold block themes, theme.json og REST API som fremtidskompatibel baseline.

Hvis du onsker hjelp med a auditere en stack for oppgraderingsklarhet, gjor vart WordPress-utviklingsteam det arbeidet for produksjonssider hver release-syklus.