Planer for WordPress 7.2: sudo-modus, Secrets API, Gutenberg Notes og lanseringsgruppen

#Hvem leder lanseringen av WordPress 7.2

Matt Mullenweg er Release Lead for lanseringsgruppen for WordPress 7.2, ifølge lanseringssiden for 7.2. Den samme siden lister opp resten av gruppen:

Lanseringssyklusen overlapper med en kort lederstrid i Automattic, selskapet Mullenweg leder. 10. september 2026 opplyste Automattic at han var i permisjon, og at finansdirektør Mark Davies skulle lede selskapet som konstituert administrerende direktør. 12. september sa en talsperson for selskapet til CMSWire at Mullenweg var styreleder og administrerende direktør med full støtte fra styret, og Automattic anslo senere fraværet hans til 33 timer og 20 minutter uten å forklare permisjonen. Rollen hans i open source-prosjektet WordPress endret seg ikke i løpet av disse dagene: WordPress’ Executive Director Mary Hubbard uttalte at han fortsatt ledet prosjektet (WebHosting.Today).

Lanseringsteamet tar og kommuniserer beslutninger om utgivelsen og samler inn innspill fra miljøet. Ukentlige utviklerchatter holdes i kanalen #core i Making WordPress-Slack på onsdager kl. 15:00 UTC.

#Gutenberg Notes i WordPress 7.2

Notes finnes allerede i kjernen. WordPress 7.1 leverte innebygde notater på markert tekst, rik tekst i notatene, autofullføring av @-omtaler og e-postvarsler til de som blir nevnt, ifølge issuen for videreutvikling av Notes i 7.2. Veikartet nevner tre tillegg for 7.2.

Med Notes i 7.2 skal redaksjonelle team kunne:

• Foreslå en endring i forslagsmodus, som forfatteren deretter godtar eller avviser.
• Legge til emoji-reaksjoner på notater for rask tilbakemelding.
• Legge til et notat fra blokkverktøylinjen, fordi valget i dag er vanskelig å finne.

Per oppdateringen av issuen 30. september ligger forslagsmodusen bak et eksperiment fordelt på ni pull requests som ennå ikke hadde fått full gjennomgang, emoji-reaksjonene ble overført fra 7.1 og flyttet til en ny emoji-velger, og pull requesten for snarveien i verktøylinjen var godkjent. En egen sporingsissue for 7.3 samler arbeidet som ikke rekker frem, så sjekk utviklernotatene for Beta 1 før du lover forslagsmodus til et redaksjonelt team.

#Samarbeid i sanntid i WordPress 7.2

Samarbeidsredigering i sanntid er ikke en del av 7.2. Veikartet utelater den mens de arkitektoniske beslutningene avklares. Sanntidssamarbeid ble fjernet fra WordPress 7.0, og 18. september 2026 foreslo Chris Zarate en servertilpasset tilnærming. I dag slår nettleserne sammen endringer direkte og sender resultatet når noen lagrer. Etter forslaget går hver oppdatering gjennom WordPress, som registrerer hvem som gjorde den, kontrollerer autorisasjon, slår den sammen og lagrer resultatet, og deretter sender de andre deltakerne endringene de mangler eller melder en konflikt til gjennomgang. Nettleserne ville ikke lenger utveksle oppdateringer seg imellom.

Innlegget sier at utforskningen er på et tidlig stadium og ikke klar for kjernen. Tre kandidater til synkroniseringsmotor (Yjs-server, Distributed Editing og Intent log) ligger i repositoriet gutenberg-sync-engines som en utforskende plugin. Hosting er den åpne kostnaden: sammenslåing på serveren gir ekstra belastning, hyppig polling er dyrere på planer med lite ressurser, og en WebSocket-transport ville kreve en daemon som kjører utenfor PHP-arbeiderpoolen og administreres av hostingleverandøren.

#Hva er sudo-modus i WordPress 7.2

Siden internett i dag preges av automatiserte skanninger og sofistikerte skript for sesjonskapring, er tradisjonell administrator-autentisering ikke lenger tilstrekkelig. Dersom et ondsinnet skript eller en angriper fanger opp informasjonskapslene eller sesjonstokenet til en aktiv administrator, får de ubegrenset tilgang til hele nettstedet.

Veikartet lister opp sudo-modus for 7.2: ny autentisering før svært privilegerte handlinger. Navnet kommer fra Unix-kommandoen sudo. En stjålet sesjonscookie alene ville da ikke være nok til å utføre en privilegert handling, fordi handlingen ber om innloggingsopplysningene på nytt.

Hvilke handlinger som skal beskyttes, er ennå ikke offentlig. Veikartet sier at et forslag og en invitasjon til samarbeid vil komme, og det var ikke publisert noe forslag om sudo-modus på make.wordpress.org/core da vi sjekket 12. oktober 2026. Inntil det kommer, er en oversikt den nyttige forberedelsen: list opp de tilpassede administrasjonsskjermene og REST-endepunktene i dine plugins som endrer brukere, roller og rettigheter, filer eller sikkerhetsinnstillinger, fordi det er foran disse flytene et steg med ny autentisering ville bli plassert.

#Secrets API i WordPress 7.2 for API-nøkler

Lagring av sensitive akkreditiver (som Stripe-API-nøkler, Mailchimp-tokener eller tilpassede databasepålogginger) har historisk sett vært en arkitektonisk sårbarhet i WordPress. I over to tiår har utviklere ikke hatt annet valg enn å hardkode nøkler i wp-config.php eller lagre dem som ukrypterte opsjoner i tabellen wp_options.

Eric Manns forslag til Secrets API fra 25. august 2026 sikter mot 7.2 med et førsteklasses lager for akkreditiver. Problembeskrivelsen er konkret: nøkler i klartekst i opsjonstabellen havner i databasedumper, sikkerhetskopier, staging-kloner og CLI-utdata, og plugins som krypterer sine egne nøkler, gjør det hver på sin måte. KI-integrasjoner gjør en lekket nøkkel enda dyrere.

Den foreslåtte utformingen:

• Kryptering er alltid på. Hver hemmelighet får sin egen datanøkkel, pakket inn av en hovednøkkel, som nettstedsnøkkelen igjen pakker inn (konvoluttkryptering). Det finnes ingen klartekstmodus og ingen konstant som slår av krypteringen. Kryptografien bruker libsodium, med sodium_compat som reserve.
• Standardlageret er opsjonstabellen, som bare inneholder chiffertekst med autoload=no, og som er utelatt fra options.php og REST-endepunktet for innstillinger. En egen konstant er den foretrukne nøkkelkilden; nettsteder uten den faller tilbake på en nøkkel avledet fra de eksisterende saltene.
• Eksterne lagre kobles inn gjennom en drop-in. En secrets.php-drop-in eksponerer to separate utvidelsespunkter: lagring (for eksempel HashiCorp Vault eller AWS Parameter Store) og nøkkelring (en KMS eller HSM).
• Den feiler lukket. Når bakenden ikke kan nås, feiler kallet uten lokal reserve. Verdiene kan bare skrives: det finnes ingen eksport.

#Funksjoner i Secrets API i WordPress 7.2

wp_set_secret( string $name, string $value ): bool|WP_Error
wp_get_secret( string $name, string $version = WP_Secret_Version::CURRENT ): WP_Secret|null|WP_Error
wp_delete_secret( string $name ): bool|WP_Error
wp_import_option_as_secret( string $option, string $name ): bool|WP_Error

wp_get_secret() returnerer et WP_Secret-objekt, ikke en streng. Verdien hentes ut gjennom reveal(), og fingerprint() gir en identifikator som er trygg å logge. Objektet maskerer seg selv i logger, var_dump() og feilutdata, og nekter serialisering. Funksjonen returnerer null når hemmeligheten ikke finnes, og en WP_Error når den finnes, men ikke kan dekrypteres. Navn får etter konvensjon et navnerom i formen plugin-slug/secret-name.

To rettigheter beskytter lageret: manage_secrets og manage_network_secrets. På multisite avleder en rotnøkkel for nettverket undernøkler per nettsted, og hemmeligheter for nettsted og nettverk bruker separate funksjoner uten implisitt reserve mellom dem. Rotasjon styres av operatøren med to versjonsplasser, CURRENT og PREVIOUS, og en hook utløses ved hver skriving med aktøren, tidsstempelet og det gamle og det nye fingeravtrykket.

Det finnes med vilje ikke noe filter på hentestien: et filter ville latt hvilken som helst plugin fange opp akkreditiver, så hostingleverandører kobler seg inn gjennom providere i stedet. Forslaget er også tydelig på sine begrensninger. All kode som kjører inne i WordPress, kan kalle wp_get_secret(), og plugin-sluggen i navnet på en hemmelighet er ikke autentisert, så API-et isolerer ikke én plugins hemmeligheter fra en annens. Det API-et fjerner, er nøkler i klartekst i dumper, sikkerhetskopier og staging-kopier.

For byråer og utviklere som bygger moderne WordPress-integrasjoner (inkludert integrasjoner med KI-agenter, der API-nøkler brukes mye), gir Secrets API et standardisert rammeverk som bringer sikkerheten i WordPress nærmere enterprise-standarder.

#Slik migrerer du API-nøkler i plugins til Secrets API

Forslaget har ingen administrasjonsskjerm i 7.2: en innstillingsskjerm er utsatt til 7.3. Støtte i WP-CLI er med i omfanget for 7.2, slik at akkreditiver slutter å dukke opp i skallhistorikk og prosesslister, men kommandonavnene er ikke bestemt ennå (det er et av de åpne spørsmålene i innlegget). Forslaget planlegger først en funksjonsplugin og deretter en kjernepatch med det samme API-et.

I plugin-koden er migreringen et bevisst steg per opsjon gjennom wp_import_option_as_secret(), ikke en automatisk opprydding. Importerte hemmeligheter merkes for rotasjon, fordi den gamle klartekstverdien allerede har havnet i hver sikkerhetskopi som er tatt så langt. En versjonssikker lesing for en plugin som må kjøre på både 7.1 og 7.2, ser slik ut:

$name = 'my-plugin/stripe-key';

if ( function_exists( 'wp_get_secret' ) ) {
	$secret = wp_get_secret( $name );
	if ( null === $secret && get_option( 'my_plugin_stripe_key' ) ) {
		wp_import_option_as_secret( 'my_plugin_stripe_key', $name );
		$secret = wp_get_secret( $name );
	}
	$key = $secret instanceof WP_Secret ? $secret->reveal() : '';
} else {
	$key = (string) get_option( 'my_plugin_stripe_key', '' );
}

Signaturene kommer fra forslaget og kan endre seg før Beta 1, så behold function_exists()-sjekken og den gamle stien for nettsteder på 7.1. Forslaget sier ikke om importen fjerner den opprinnelige opsjonen, så sjekk utviklernotatet før du sletter noe. Når nøkkelen ligger i Secrets API, roterer du den hos betalings- eller API-leverandøren.

#Hvorfor hostingleverandører protesterer mot forslaget til Secrets API

Kommentartråden under forslaget viser hvor utformingen fortsatt er omstridt. Chris Reynolds fra Pantheon skrev at Pantheon driver et eksternt lager for hemmeligheter der applikasjoner bare har lesetilgang, spurte om skrivebeskyttede providere er med i omfanget og hvordan plugins skal håndtere WP_Error som en skriving da ville returnere, og påpekte at plattformlagre som trenger klartekst, kommer i konflikt med drop-in-modellen. Ryan McCue fra Altis gikk imot forslaget slik det er skrevet, og argumenterte for at WordPress bare bør lese hemmeligheter og overlate krypteringen til eksterne HSM-er.

Eric Mann svarte at en skrivebeskyttet provider kan gjøre setteren til en no-op, og at hostingleverandører vil kunne bytte inn en sterkere provider, med et eksempel for AWS Secrets Manager i repositoriet hans secrets-api. En pull request til wordpress-develop (#13759) tar for seg bekymringene rundt providere fra hostingleverandører. Fem åpne spørsmål gjenstår i innlegget, blant annet om to versjonsplasser er nok og hvilke WP-CLI-kommandoer som kommer først.

For en plugin-forfatter er den praktiske konsekvensen at wp_set_secret() kan feile på en administrert hosting med vilje. Et innstillingsskjema som lagrer en nøkkel, må vise den returnerte feilen i stedet for å anta at lagringen lyktes.

#Endringer i Application Passwords i WordPress 7.2

Sikkerhetsdelen av veikartet lister også opp herding av Application Passwords: forbedringer i brukeropplevelsen, et e-postvarsel når et nytt applikasjonspassord legges til, rettelser i deteksjonen av miljø, tryggere håndtering av default_role og støtte for SameSite-cookies. Arbeidet spores i Trac-sakene #66009, #63927, #57388, #46744 og #37000. Herdet HTML-behandling oppå HTML API fullfører sikkerhetslisten.

Applikasjonspassord er akkreditivet de fleste REST API-integrasjoner bruker, så varselet gir nettstedseieren et signal når noen legger til et uten at eieren vet om det.

#Andre funksjoner på veikartet for WordPress 7.2

Ipsum, det nye standardtemaet, er et minimalistisk bloggtema bygget som et blankt lerret, med prikkede understrekinger, en håndfull skriftsett og stilvarianter som farger om hele siden, bilder inkludert. Hver kombinasjon av farge og stil oppfyller kontrastkravet WCAG AA, ifølge Henrique Iamarinos introduksjonsinnlegg. Temaet avslutter også praksisen med årstallsbaserte navn på standardtemaer. Koden ligger på GitHub for testing, og teamet beskriver tidsplanen som stram.

Arbeidet med KI fortsetter i AI-pluginen, uten garanti for at det havner i kjernen: flere abilities (eksperimentell skrivebeskyttet dekning for media, taksonomier og kommentarer), en MCP Adapter oppdatert til gjeldende MCP-spesifikasjon og distribuert gjennom plugin-katalogen, agentidentiteter med rettigheter som kan revideres, og strømmede svar i PHP AI Client.

Innen blokker og API-er lister veikartet opp en Description list-blokk for <dl>, <dt> og <dd>, søk etter nøkkelord i Icon-blokken, et data-wp-html-direktiv og en router i Interactivity API, samt serverside-rendering for Table of Contents-blokken slik at den kan bli stabil. Oppgraderingen til React 19 er i stor grad på plass i Gutenberg, men kommer neppe fullt ut i 7.2.

I administrasjonspanelet får DataViews og DataForms visninger, felter og handlinger registrert på serveren, og innleggsinspektøren erstattes av et DataForm. Feilmeldinger blir lettere å diagnostisere og får en kopieringsknapp, og et ombygd fundament for Site Editor lar plugins registrere sine egne skjermer. På ytelsessiden erstattes sammenslåing av skript og stiler med prefetching (Trac #57548), sammen med arbeid fra pluginen Enhanced Responsive Images.

#Tidsplan for WordPress 7.2

David Baumwald publiserte tidsplanen for WordPress 7.2 på make.wordpress.org 6. oktober 2026. Hver milepæl starter kl. 15:00 UTC.

Beta 1 er punktet der kjernebidragsyterne går over til testing og feilretting, og der utviklernotatene begynner å komme. RC1 bringer Field Guide, en hard frys av tekststrenger og lanseringsgrenen. Etter funksjonsfrysen committes bare feilrettinger, med regresjoner først.

Installer Beta 1 på en staging-kopi av nettstedet 20. oktober, og kjør testene av utvidelser og tema på nytt med RC1 17. november, slik at konflikter dukker opp på staging før 8. desember.

#Slik tester du betaversjonen av WordPress 7.2

Det finnes to dokumenterte veier. Pluginen WordPress Beta Tester, som du finner under Verktøy, Beta Testing (Innstillinger på multisite), bytter den innebygde oppdateringsfunksjonen fra standardkanalen Point release til Bleeding edge (trunk) eller til beta- og RC-pakker. På kommandolinjen tar wp core update imot --version=nightly eller en sti til en nedlastet zip-fil. Ta en sikkerhetskopi først, og hold betaversjoner unna produksjon.

Hva du bør teste, følger av veikartet: plugins som lagrer API-nøkler i opsjoner, tilpassede administrasjonsflyter som endrer brukere eller filer, redaksjonelle arbeidsflyter som er avhengige av Notes, og child-temaer hvis du planlegger å flytte et nettsted til Ipsum.

#Slik forbereder du nettstedet på WordPress 7.2

WordPress 7.2 representerer en av de mest strukturelt betydningsfulle oppdateringene i 2026. Kombinasjonen av samarbeidsflyter i editoren og skjerpet sikkerhetsarkitektur på backend gjør at byråer og utviklere må begynne forberedelsene allerede nå.

Hos WPPoland er vi allerede i gang med å klargjøre våre headless Astro-installasjoner og serverløse MCP-integrasjoner slik at de kan bruke den nye Secrets API og tilpasse seg re-autentiseringen i sudo-modus.

Ønsker du å sikre ditt enterprise WordPress-system eller migrere dine egne plugins til de nye kjernestandardene for 2026? Kontakt vårt kjerneteam i dag for å utarbeide en tilpasset migreringsplan.