Veikartet for WordPress 7.1

#Innledning

Den 19. juni 2026 publiserte Anne McCarthy fra Automattic veikartet for WordPress 7.1 på Make WordPress Core-bloggen, hennes første syklus som utgivelsesleder. Ordvalget hennes på LinkedIn var typisk varmt: “I am so excited about what’s taking shape.” (Jeg er så begeistret for det som tar form.) Veikartet er virkelig fullpakket, og nøkkelordet er samarbeid, satt opp som den røde tråden som binder utgivelsen sammen.

Det er en spenning verdt å nevne med en gang. Utgivelsen markedsføres med samarbeid som overskrift, men den fremste samarbeidsfunksjonen, sanntidssamarbeid, er det ene som stadig blir utsatt. Den ble trukket fra WordPress 7.0 rundt to uker før den lanseringen. Den vender tilbake i 7.1-veikartet pakket inn i “big, open strategy questions” (store, åpne strategispørsmål) snarere enn en lanseringsdato. Og på WordCamp Europe 2026 stilte core-committere åpent spørsmål ved om hele funksjonen i det hele tatt hører hjemme i kjernen. Den ærlige lesningen av 7.1 er altså to utgivelser i én: et solid sett av styling-, media- og plattformforbedringer som faktisk lanseres 19. august, og en samarbeidshistorie det fortsatt diskuteres åpent om.

Oppdatering, 28. juli 2026: to punkter har forlatt denne utgivelsen siden veikartet ble publisert. Oppgraderingen fra React 18 til React 19 er skjøvet forbi 7.1, og støtten for Unicode-e-postadresser er trukket. Beta 3 er ute, med 71 rettelser. Lanseringsdatoen 19. august står uendret. Begge rettelsene er gjennomgått i avsnittene under.

#Kort oppsummert

• Anne McCarthy leder 7.1 for første gang, med lansering satt til 19. august 2026, avslutningsdagen av WordCamp US i Phoenix. Beta 3 er ute med 71 rettelser.
• Utgivelsen er bygd rundt samarbeid, men sanntidssamarbeid (RTC) er fortsatt uavklart etter å ha blitt kuttet fra 7.0.
• De virkelig bekreftede gevinstene er responsiv styling, avvikling av Classic-blokken, samt Guidelines- og KI-arbeidsflytfunksjonene. React 19 stod på den listen og har nå glippet forbi 7.1.
• Støtten for Unicode-e-postadresser ble trukket fra utgivelsen etter Matt Mullenwegs avgjørelse, av sikkerhetshensyn, seks uker etter at den ble slått sammen med kjernen.
• Core-committere lanserte en canary-distribusjonsmodell i Chrome-stil, et signal om at de mener selve test- og tilbakemeldingsprosessen trenger nytenkning.
• Med et så kort stabiliseringsvindu må man forvente at flere veikartpunkter glipper eller lanseres bak flagg. To har allerede gjort det.

#Hva som faktisk lanseres, ordnet etter hvem det angår

Veikartet lister opp mye. For en nettstedseier eller et byrå er det nyttige spørsmålet ikke “hva står på listen”, men “hva endrer arbeidet mitt”. Her er fordelingen.

Mønsteret er tydelig. Punktene med høy tillit er infrastrukturelle eller rettet mot byggere. Samarbeidshistorien, den utgivelsen er oppkalt etter, ligger i middels-til-lav-sjiktet.

Midten av den tabellen ble spikret av Gutenberg 23.6, siste funksjonsutgivelse inn mot 7.1. Den løfter blokkene Playlist og Tabs fra eksperimentelle til stabile, legger til notater ved tekstmarkering med @omtale-autofullføring, en Dynamic Gallery-variant som viser alle medier knyttet til et innlegg, et API for ikonregistrering for utvidelser og temaer, og justerbare visningsbredder i theme.json, altså responsiv styling som slutter å være spikret til tre bruddpunkter noen andre har valgt.

#Responsiv styling: den stille hovedsaken

Bygger du nettsteder for kunder, er det mest nyttige i 7.1 ikke samarbeid, det er responsiv styling. Frem til nå har det å styre hvordan en blokk ser ut ved ulike skjermstørrelser betydd egendefinert CSS, et plugin, eller kamp med editoren. Veikartet bringer blokkstyling per bruddpunkt rett inn i editoren, sammen med styling for interaktive tilstander for hover, fokus og aktiv, og en “display inherited styles”-visning (visning av arvede stiler) slik at du ser hvor en stil faktisk kommer fra.

Dette er lite glamorøst og betyr mer enn de fleste av de mer prangende punktene. Responsiv kontroll er et daglig friksjonspunkt i ekte kundearbeid, og å flytte det inn i kjernen reduserer antall plugins og den egendefinerte CSS-en hvert nettsted ellers samler opp. Det er den typen plattformmodenhet som ikke lager overskrifter, men i det stille fjerner en hel kategori av supporthenvendelser.

#React 19 glipper, avviklingen av Classic-blokken består: under panseret

To punkter på veikartet er usynlige for sluttbrukere og viktige for utviklere. Det ene har nå forlatt utgivelsen. Oppgraderingen av editoren fra React 18 til React 19 lander ikke i 7.1: kompatibilitetsproblemer med utvidelser viste seg mer seiglivede enn ventet, og den Automattic-sponsede bidragsyteren Jarda Snajdr sa at oppgraderingen trenger «en betydelig testperiode» før den kan lanseres.

Det er riktig avgjørelse og en ubehagelig en. React 19 var ett av få punkter på dette veikartet med høy tillit, og samtidig det punktet som lettest kunne knekke tredjepartskode. Utsettelsen gjør 7.1 til en mindre utgivelse enn veikartet lovet, og skyver kompatibilitetsarbeidet inn i en senere syklus. For utviklere er den praktiske virkningen en utsettelse, ikke en avlysning: oppgraderingen kommer fortsatt, så å teste egendefinerte blokker og editorgrensesnitt mot React 19 i Gutenberg-pluginet er fortsatt verdt tiden, bare uten en augustfrist hengende over seg.

Classic-blokken er det mer interessante tilfellet, for her endret planen seg midt i syklusen. Opprinnelig skulle den skjules fra blokkinnsetteren i 7.1 og fases gradvis ut, siden den drar med seg TinyMCE, en tung editor. Reaksjonen i miljøet kom umiddelbart: noen, som Seth Rubenstein (Pew Research Center), kvitterte med et enkelt «bra», mens erfarne bloggere som Jeff Chandler så bråket komme: «Herregud. Jeg så ikke denne komme. Jeg vet nøyaktig hva dette kommer til å gjøre.»

Oppdatering: denne planen om å skjule blokken fra innsetteren ble reversert. Ifølge kjernediskusjonen blir Classic-blokken værende i innsetteren i 7.1, akkurat som i dag, og Automattics engineering-direktør Marin Atanasov bemerket at den opprinnelige tilnærmingen «hadde ting stort sett bak-fram», og at å tvinge brukere bort fra den uten et bedre alternativ bare gjør opplevelsen dårligere uten noen direkte gevinst. Ytelsesargumentet står fortsatt, for å forsinkelseslaste TinyMCE bort fra sider som aldri bruker den er en reell gevinst for WooCommerce-butikker der hver kilobyte av editorvekt måles, men migreringsklokken som noen allerede hadde startet, er satt på pause. Vedlikeholder du Classic-blokk-innhold, tvinges du ikke til noe i 7.1.

Oppdatering: også støtten for Unicode-e-postadresser er ute av 7.1. Den ble slått sammen med kjernen seks uker tidligere, etter elleve års utvikling, og Matt Mullenweg tok avgjørelsen om å trekke den av sikkerhetshensyn. Elleve år frem til sammenslåing og seks uker til reversering er et hardt utfall for bidragsyterne som stod bak, og det bør leses ved siden av canary-debatten lenger nede: en endring som klarer gjennomgang, blir slått sammen og så trukket sent på en sikkerhetsvurdering, er nøyaktig den svikten i tilbakemeldingssløyfen committerne prøver å sette ord på. Regnet du med e-postadresser utenfor ASCII i 7.1, planlegg videre med dagens oppførsel.

To utviklernære endringer kom som merge-forslag etter veikartet og er verdt å følge med på. Design-system-theming innfører et kjerneregistrert wp-theme-stilark pluss en React-ThemeProvider, grunnlaget for den lenge lovede admin-redesignen, med brukerens fargeskjemaer i nettstedsredigereren som første synlige resultat. Og Abilities API fikk tre foreslåtte skrivebeskyttede abilities (core/read-settings, core/read-content, core/read-users) som lar agenter og KI-verktøy lese grunnleggende nettstedsdata bak tillatelsessjekker, selv om en Abilities-vedlikeholder allerede har innvendt at de ikke er klare for kjernen. Begge er den typen rørlegging som avgjør om KI- og admin-historien lander rent eller glipper til 7.2.

#Guidelines og KI: arbeidsflytveddemålet

Veikartet satser på KI, men på en mer disiplinert måte enn “legg til en chatboks”. Det fremste er Guidelines, en funksjon som lar et nettsted definere redaksjonelle regler og merkevarestemme på ett sted, som så mater editorens KI-verktøy slik at generert innhold følger disse reglene. Det er også en AI Client-iterasjon som legger til generasjonsstrømming og embeddings, og en Connectors-iterasjon som flytter autentisering forbi rene API-nøkler.

Denne funksjonen tok et konkret skritt fremover da den Automattic-sponsede kjerne-committeren Greg Ziółkowski publiserte et formelt merge-forslag for å bringe den nye egendefinerte innleggstypen wp_knowledge og AI-retningslinjene inn i kjernen. Mottakelsen har imidlertid vært svært splittet:

• George Stephanis (Bethink Studios) ønsket funksjonen velkommen, og bemerket at den løser utfordringer med redaksjonelle retningslinjer som utvidelser har måttet omgå i årevis.
• Aaron Jorbin (uavhengig kjerne-committer) var enig i at fundamentet er solid, men mente at implementeringen i nåværende form er ufullstendig.
• Jon Brown (9seeds) var mer kontant og foreslo at det «bør utvikles som et kjerne-plugin i ett eller to år, og så kanskje likevel aldri slås sammen med kjernen.»
• Search Engine Journal fanget opp motstanden blant utviklere, og rapporterte at mange føler funksjonen er løsrevet fra brukernes faktiske behov.

Dette er den rette formen for KI i et CMS. Risikoen med KI-skrivehjelp er ensformig, merkevarefremmed output, akkurat det slop-problemet hvert innholdsteam nå kjemper mot. Et Guidelines-lag som begrenser generering til et nettsteds standarder er en gardering mot det, forutsatt at det lanseres i brukbar stand. Det er vurdert til middels tillit her nettopp fordi funksjonsambisjon og et fire-ukers stabiliseringsvindu sjelden lar seg forene.

#RTC-sagaen, og hvorfor den stadig stopper opp

Sanntidssamarbeid er funksjonen WordPress stadig nesten lanserer. Den ble kuttet fra 7.0 to uker før. I 7.1-veikartet rammer McCarthy den inn ærlig, med “big, open strategy questions” (store, åpne strategispørsmål) fortsatt åpne: hva som faktisk skal lanseres, og hvilken lagringsmekanisme som skal brukes. Vi dekket detaljene i dette andre forsøket i artikkelen vår om WordPress 7.1 real-time collaboration, og veikartet løser ikke spørsmålene som ble reist der så mye som det gjentar dem.

Den mer avslørende utviklingen kom fra core-committerne. På samlingen deres på WordCamp Europe 2026 vokste det frem en “strong opinion, loosely held” (sterk mening, løst holdt) om at hele RTC-funksjonssettet ikke bør ligge i kjernen i det hele tatt, bare den underliggende arkitekturen, mens det rike funksjonslaget overlates til plugins eller verter. Det er en betydelig splittelse. Holder den, kan 7.1 levere det tekniske grunnlaget for samarbeid uten den synlige funksjonen, noe som ville gjøre innrammingen “samarbeid som en rød tråd” mer til ambisjon enn levering for denne syklusen.

#Canary-debatten: et prosessproblem i forkledning

Det mest interessante committerne diskuterte på WordCamp Europe var ingen funksjon i det hele tatt. De lanserte å flytte WordPress til en canary-distribusjonsmodell i Chrome-stil med funksjonsflagg, en fundamentalt annerledes måte å bygge, teste og lansere kjernen på. Gruppen selv erkjente at det trolig var “a technical solution to a communications problem” (en teknisk løsning på et kommunikasjonsproblem), og reiste opplagte spørsmål, som hvordan canary-bygg ville skille seg fra det Gutenberg-pluginet allerede tilbyr, og om det i det hele tatt fortsatt bør finnes et Gutenberg-plugin.

Dette ligger et godt stykke fram i tid. Men at committere i det hele tatt tar det opp, sier noe om hvor de mener den nåværende modellen kommer til kort, særlig rundt testing og tilbakemelding. De gjentatte RTC-utsettelsene på overtid er symptomet: at en stor funksjon når to uker fra lansering før den trekkes er en svikt i tilbakemeldingssløyfen, ikke bare en funksjon som ikke var klar. Canary-ideen er et forsøk på å fange det opp tidligere. Enten den lander eller ikke, så er det at den er på bordet den ærligste innrømmelsen i hele syklusen om at byggeprosessen, ikke funksjonsetterslepet, er den reelle begrensningen.

#Tidslinjeproblemet

Her er det harde tallet. Beta 1 var planlagt til 15. juli, lansering er 19. august, og Beta 3 har nå 71 rettelser bak seg. Det er under fire uker til å låse ned et veikart så stort. McCarthy arvet en ambisiøs liste og kort tid til rådighet, og det realistiske utfallet var hele veien at noen punkter lanseres, noen glipper til 7.2, og noen ankommer bak funksjonsflagg i en delvis tilstand. Det er ingen kritikk av utgivelseslederen, det er den strukturelle realiteten av en fast dato satt for å sammenfalle med WordCamp US. React 19 og Unicode-e-post er de to første navnene på den listen, og de falt ut før Beta 3, ikke etter.

For nettstedseiere er den praktiske lærdommen å lese veikartet som en intensjonserklæring, ikke en garanti. Planlegg rundt det som nå faktisk er bekreftet, responsiv styling og blokkarbeidet fra Gutenberg 23.6, og følg med på punktene med middels tillit (Guidelines, theming-grunnlaget for admin-redesignen) i stedet for å bygge planer på dem. Ikke lov en kunde en funksjon som fortsatt bærer “big, open strategy questions” (store, åpne strategispørsmål) seks uker før lansering, og ikke regn en sammenslått funksjon som en lansert funksjon.

#Den 24-timers oppdateringsforsinkelsen: sikkerhet vs. hastighet

Parallelt med debattene om kjerne-lanseringen, implementerte WordPress.org sitt plugin-team en stor infrastrukturendring: en 24-timers ventetid (cooldown) for alle oppdateringer av utvidelser og temaer. Selv om kunngjøringen rammet inn denne ventetiden rundt automatiske oppdateringer for å forhindre angrep på forsyningskjeden, viste det seg at forsinkelsen gjelder alle oppdateringsveier, inkludert manuelle installasjoner fra kontrollpanelet.

Dette har møtt kraftig motstand fra utviklere og byråer:

• Miriam Schwab (Elementor) påpekte at dette skaper et farlig «sårbarhetsvindu». I det øyeblikket en sikkerhetsutgivelse publiseres, blir koden til feilrettingen offentlig tilgjengelig, slik at roboter kan analysere den for å lage angrep. Samtidig hindres nettstedadministratorer fra å installere oppdateringen i opptil 24 timer.
• Pavel Ciorici (temautvikler) påpekte at dersom en utvikler sender ut en rask feilretting under cooldown-perioden, nullstilles 24-timersmåleren, noe som forlenger ventetiden.
• Steve Burge (PublishPress) ga et motargument og berømmet prosessen for å ha fanget opp mindre sikkerhetsprobleme allerede i den første uken.
• Francisco Torres (co-rep for plugin-teamet) erkjente friksjonen og bekreftet at teamet aktivt vurderer tilbakemeldingene, og at det er sannsynlig med endringer i reglene.

For byråer og ytelsesfokuserte WordPress-sider endrer denne infrastrukturendringen rytmen for utgivelser og sikkerhetsoppdateringer. Dette forsterker behovet for distribusjon utenom det offisielle depotet, eller grundig testing i testmiljøer før oppdateringer rulles ut offentlig.

#Hva du bør gjøre før 19. august

• Utviklere: React 19 kommer ikke i 7.1, så det er fristen som har flyttet seg, ikke arbeidet. Fortsett å teste egendefinerte blokker og editorutvidelser mot den i Gutenberg-pluginet, for det var nettopp kompatibilitet med utvidelser som utsatte den.
• Eldre nettsteder: kartlegg hvor du fortsatt er avhengig av Classic-blokken eller -editoren og start en migreringsplan, for utfasingen er nå formelt i gang.
• Ytelsessensitive prosjekter: endringen med forsinkelseslastet TinyMCE er gratis ytelse når du har gått bort fra Classic-blokken, verdt å ta med i en WooCommerce-ytelsesgjennomgang.
• Redaksjonsteam: følg med på Guidelines og KI-verktøyene, men ikke redesign arbeidsflyten rundt en funksjon med middels tillit før den faktisk lanseres.
• Alle: test mot Beta 3, som er ute nå med 71 rettelser bak seg. Et kort stabiliseringsvindu betyr at fellesskapstesting teller mer enn vanlig denne syklusen.

#Konklusjon

WordPress 7.1 er en sterk utgivelse med et litt misvisende navn. Samarbeidsprofilen er ekte intensjon, men samarbeidsfunksjonen er fortsatt uavklart, og committerne debatterer åpent om den hører hjemme i kjernen og om hele byggeprosessen trenger nytenkning. Skreller du bort innrammingen, er det du får 19. august en mindre, men fortsatt nyttig plattformutgivelse: responsiv styling som fjerner daglig friksjon, blokkene Playlist og Tabs som kommer stabile med Gutenberg 23.6, en avvikling av Classic-blokken som hjelper ytelsen, og et disiplinert første steg innen KI gjennom Guidelines. React 19-moderniseringen og støtten for Unicode-e-post er begge ute av denne syklusen, det tydeligste beviset så langt på hvor stort gapet mellom et publisert veikart og en lansert versjon kan bli.

Den dypere historien er canary-debatten. Et prosjekt som er villig til å stille spørsmål ved sin egen distribusjonsmodell offentlig er et prosjekt som vet at tilbakemeldingssløyfene strammer seg, den samme uroen som ligger bak det stadig tilbakevendende spørsmålet om WordPress mister markedsandeler. Følg den samtalen, for den vil forme WordPress-utgivelser lenge etter at 7.1 er lansert. For nå, planlegg rundt det som er bekreftet, test tidlig, og les resten av veikartet som en intensjonserklæring snarere enn et leveringsløfte.

Sist oppdatert: 28. juli 2026.