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.

Ifølge veikartet skulle redaksjonelle team med Notes i 7.2 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.

Oppdatering, 23. oktober 2026: Kunngjøringen av Beta 1 fra 20. oktober nevner emoji-reaksjoner på notater, et nytt ikon i verktøylinjen, notater i redigeringsflaten og en minimert Notes-modus. Forslagsmodus står ikke på listen, så ikke planlegg redaksjonsarbeid i 7.2 rundt den.

#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.

Oppdatering, 20. oktober 2026: Kunngjøringen av Beta 1 nevner ikke sudo-modus, verken i delen for redaktører eller i delen for utviklere. Kommer den i 7.2, blir det i en senere beta.

#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.

Oppdatering, 18. oktober 2026: Utvidelsen MCP Adapter er i versjon 0.7.1 fra 15. oktober 2026. Den begrenser lagrede data for øktinitialisering til 4 KiB (berørte klienter kobler til på nytt én gang), gir tydeligere feilmeldinger for abilities som ikke er tilgjengelige, og har fått en veiledning for nettstedseiere om å koble til en KI-klient med Application Passwords og om feilsøking. Plugin-utviklere bør merke seg en endring fra 0.7.0: å pakke adapteren som bibliotek er utfaset, og nettsteder skal installere utvidelsen i stedet.

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.

Oppdatering, 24. oktober 2026: Gutenberg 24.2, utgitt 14. oktober, slår på React 19-eksperimentet som standard i utvidelsen. Nettsteder med utvidelsen laster React 19 for skriptene react og react-dom, med mindre et tema eller en utvidelse fra listen over kjente inkompatibiliteter er aktiv. Da beholder de React 18. Hvis noe slutter å virke, kan du slå av React 19 under Gutenberg, Experiments. Gutenberg-teamet ber utviklere av utvidelser og temaer som bruker React, om å teste med 24.2 og melde fra om feil, og tilbyr den nye pakken @wordpress/react-inert-value for å sette attributtet inert slik at det virker i begge versjonene. Kunngjøringen av Beta 1 nevner ikke React 19, så test React-koden din mot Gutenberg 24.2 i stedet for å gå ut fra hva WordPress 7.2 selv leverer.

#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.

Oppdatering, 20. oktober 2026: Beta 1 kom etter planen, og kunngjøringen bekrefter 8. desember 2026 som dato for endelig versjon. Secrets API er med i Beta 1 (Trac #66187): kryptering av lagrede data, rotasjon av påloggingsdata og egne lagringsleverandører. Utviklere får også et utvidet Abilities API for å lese og søke i WordPress-data, gjengivelse av klarert HTML og reaktiv navigasjon i Interactivity API, og et adminpanel som laster skript og stilark hver for seg i stedet for i store samlefiler og henter ressursene til neste skjerm på forhånd. Mediebiblioteket skalerer, komprimerer og konverterer bilder i nettleseren før opplasting. Raskeste test er wp core update --version=7.2-beta1 på en stagingkopi.

Oppdatering, 21. oktober 2026: Kunngjøringen av Beta 1 nevner også en On This Day-widget i kontrollpanelet (Trac #65116) som viser innlegg publisert på samme dato tidligere år, en egen adresse som videresender til et tilfeldig valgt innlegg (Trac #64498), tekstskygge med forhåndsinnstillinger i theme.json og ikoner fra WordPress-ikonbiblioteket i stedet for Dashicons i adminlinjen og sidemenyen. Notater flyttes inn på redigeringsflaten og får emoji-reaksjoner og et ikon i verktøylinjen. Kunngjøringen nevner verken sudo-modus eller forslagsmodus for notater, så sjekk Trac-sakene og utviklernotatene før RC1 (17. november) før du planlegger arbeid rundt dem.

Oppdatering, 3. november 2026. Betanummereringen flyttet seg etter sikkerhetsutgivelsen. Beta 2 kom 27. oktober til testing (wp core update --version=7.2-beta2 på staging). 28. oktober noterer WordPress 7.2-siden Beta 3 sammen med WordPress 7.1.4 (pakken wordpress-7.2-beta3.zip har tidsstempel fra den dagen). Partyen 3. november er nå Beta 4, og 10. november er Beta 5; RC1 blir værende 17. november og finalen 8. desember. Da denne oppdateringen ble skrevet, var Beta 4-zipen ennå ikke publisert - vent på ZIP-lenken på make.wordpress.org/core/7-2 eller nyhetssaken på WordPress.org før du løfter staging forbi beta3. Hold produksjon på 7.1.4.

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å.

Oppdatering, 24. oktober 2026: En kjerne-commit fra 19. oktober 2026 av Weston Ruter (r64585) avvikler sammenslåingen av skript og stilark i administrasjonspanelet og på innloggingssiden. wp-admin/load-scripts.php og wp-admin/load-styles.php svarer nå på hver forespørsel med 410 Gone og en forklaring på én linje i ren tekst, uten å laste WordPress. Konstanten CONCATENATE_SCRIPTS leses ikke lenger og vises ikke lenger i Nettstedshelse. Kompatibilitetsgjennomgangen i pull request 14463 søkte gjennom katalogene for utvidelser og temaer: ingen temaer der bruker den fjernede koden, og rundt 45 utvidelser kaller de to lasterne direkte, som regel fra egne dialoger, forhåndsvisninger eller oppsettsider. Blant vedlikeholdte utvidelser nevner gjennomgangen Ad Inserter (kontrollene i forhåndsvisningsvinduet virker trolig ikke), CartFlows (en mislykket forespørsel på hver adminside, uten synlige følger), Modula (gallerivinduet i den klassiske editoren setter ikke inn noe) og UiPress Lite (en verktøylinje uten stiler på dens egne sider).

Dette bør du sjekke på en testkopi med Beta 1:

• Nettstedseier: åpne dialoger, forhåndsvisninger og oppsettsider i utvidelsene dine, og se i nettverksfanen i nettleseren etter forespørsler til load-scripts.php eller load-styles.php som returnerer 410. Det synlige tegnet er en side uten stiler eller en knapp som ikke gjør noe. Denne testen er vårt forslag og kommer ikke fra kildene.
• Utvikler: bytt ut hardkodede adresser til lasterne med ressurser lagt i kø, eller med wp_print_scripts() og wp_print_styles() på en frittstående side, slik gjennomgangen anbefaler.
• Utvikler: kode som setter do_concat til true, eller returnerer false fra print_head_scripts, print_footer_scripts, print_admin_styles eller print_late_styles for å holde tilbake utskriften, virker ikke lenger, fordi hvert element skrives ut med en gang som egen tagg.
• Utvikler: _print_scripts(), _print_styles(), script_concat_settings(), in_default_dir() og WP_Dependencies::get_etag() er utfaset, og de fire utskriftsfiltrene gir nå et varsel om utfasing når du kobler deg på dem. De utfasede egenskapene i WP_Scripts og WP_Styles er fortsatt deklarert og gir ikke noe varsel.

Å teste utvidelser på en testkopi før en stor utgivelse er en del av vårt vedlikehold av WordPress-nettsider.

Jeg er allerede i gang med å klargjøre mine 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.