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.

#Kort oppsummert

• Anne McCarthy leder 7.1 for første gang, med lansering satt til 19. august 2026, avslutningsdagen av WordCamp US i Phoenix, og Beta 1 den 15. juli.
• 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, React 19, avvikling av Classic-blokken, samt Guidelines- og KI-arbeidsflytfunksjonene.
• Core-committere lanserte en canary-distribusjonsmodell i Chrome-stil, et signal om at de mener selve test- og tilbakemeldingsprosessen trenger nytenkning.
• Med under fire uker fra Beta 1 til lansering må man forvente at noen veikartpunkter glipper eller lanseres bak flagg.

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

#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 og avvikling av Classic-blokken: under panseret

To punkter på veikartet er usynlige for sluttbrukere og viktige for utviklere. WordPress oppgraderer editoren fra React 18 til React 19, som først lander i Gutenberg-pluginet før en eventuell vei inn i kjernen. For de fleste nettsteder endrer dette ingenting synlig. For alle som vedlikeholder egendefinerte blokker eller editorgrensesnitt, er det en grunn til å teste mot React 19 før august i stedet for etterpå.

Avvikling av Classic-blokken er den mer interessante, fordi det er en ytelsesbeslutning forkledd som rutineopprydding. Classic-blokken bærer med seg TinyMCE, en tung editor, og planen er å forsinkelseslaste den og fase ut blokken. Eksisterende innhold bryter ikke, men nettsteder som fortsatt lener seg på Classic-editoren eller Classic-blokken bør se på dette som startskuddet for en migrering. For ytelsessensitive prosjekter, særlig WooCommerce-butikker der hver kilobyte av editor- og frontvekt måles, er det en reell gevinst å kvitte seg med TinyMCE fra sider som aldri trengte den.

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

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 er planlagt til 15. juli, og lansering er 19. august. Det er under fire uker til å låse ned et veikart så stort. McCarthy arver en ambisiøs liste og kort tid til rådighet, og det realistiske utfallet er 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.

For nettstedseiere er den praktiske lærdommen å lese veikartet som en intensjonserklæring, ikke en garanti. Planlegg rundt punktene med høy tillit, responsiv styling, React 19, utfasingen av Classic-blokken, og følg med på de med middels tillit 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.

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

• Utviklere: test egendefinerte blokker og editorutvidelser mot React 19 nå, ved hjelp av Gutenberg-pluginet, ikke etter kjernelanseringen.
• 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 1 fra 15. juli. 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 virkelig nyttig plattformutgivelse: responsiv styling som fjerner daglig friksjon, en React 19-modernisering, en avvikling av Classic-blokken som hjelper ytelsen, og et disiplinert første steg innen KI gjennom Guidelines.

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. 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: 20. juni 2026.