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

Reaksjonen i miljøet på at Classic-blokken skjules i 7.1 har vært umiddelbar. Hvis noen, som Seth Rubenstein (Pew Research Center), reagerte med et enkelt «bra», påpekte andre veteran-bloggere som Jeff Chandler potensialet for store forstyrrelser: «Herregud. Jeg så ikke denne komme. Jeg vet nøyaktig hva dette kommer til å gjøre.»

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

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