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 ble solgt på samarbeid, 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 vendte 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 landet 19. august, og en samarbeidshistorie det fortsatt diskuteres åpent om.

Oppdatering, 20. august 2026: WordPress 7.1 Mary Lou ble lansert 19. august, på dato. Oppgraderingen fra React 18 til React 19, Unicode-e-post, Guidelines / wp_knowledge, sanntidssamarbeid og utfasingen av Classic-blokken forlot alle utgivelsen. Det som landet er responsiv styling, klientsidig media, en vedvarende administrasjonslinje, innleggseditoren alltid i iframe, Playlist og Tabs, og rikere Notes. Notatet fra 28. juli om Beta 3 står fortsatt for de to punktene som falt ut først.

#Kort oppsummert

• Anne McCarthy ledet 7.1 for første gang. WordPress 7.1 Mary Lou ble lansert 19. august 2026, avslutningsdagen av WordCamp US i Phoenix.
• Utgivelsen var bygd rundt samarbeid, men sanntidssamarbeid (RTC) ble skjøvet ut igjen etter å ha blitt kuttet fra 7.0.
• Det som faktisk landet: responsiv styling, klientsidig media, vedvarende administrasjonslinje, innleggseditoren alltid i iframe, Playlist og Tabs. Guidelines og avvikling av Classic-blokken kom ikke. React 19 glapp 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.
• Det korte stabiliseringsvinduet gjorde som det alltid gjør: junilisten var intensjon. Zip-filen fra 19. august er leveransen.

#Hva som faktisk landet, 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. Det som landet er infrastrukturelt eller rettet mot byggere. Samarbeidshistorien, den utgivelsen er oppkalt etter, ble liggende i middels-til-lav-sjiktet og utenfor zip-filen.

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. 7.1 legger blokkstyling per bruddpunkt rett inn i editoren, sammen med styling for interaktive tilstander for hover, fokus og aktiv. Temautviklere setter egne bruddpunkter i theme.json. Beta 4 la inn en opt-out etter UX-klager, så dette er ikke tvunget på hvert nettsted.

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, Classic-blokken blir: under panseret

To punkter på veikartet er usynlige for sluttbrukere og viktige for utviklere. Det ene har 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. Classic-blokken blir værende i innsetteren i 7.1, akkurat som i 7.0, 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, startet aldri. 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

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. Det kom ikke. Matt Mullenweg nedla veto mot sammenslåingen i juli, og sa at KI-funksjoner trenger reell adopsjon med imponerende vekst uke for uke før de lander i kjernen. Eksperimentet blir i Gutenberg og hos Automattic. Behandle det som et forslag, ikke som en 7.1-kapasitet. Vi dekket merge-debatten i WordPress 7.1: AI-retningslinjer og den nye innleggstypen wp_knowledge.

#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 rammet 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 sanntidssamarbeid i WordPress 7.1, og veikartet løste ikke spørsmålene som ble reist der så mye som det gjentok 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. Den splittelsen holdt i denne syklusen. 7.1 leverte verken rørleggingen eller den synlige funksjonen. Samarbeid som rød tråd ble stående som ambisjon. 7.2 er foreløpig satt til 9. desember 2026. Ikke selg en kunde live flerbrukerredigering på den datoen heller, før en field guide sier at det er lansert.

#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 15. juli, lansering 19. august, og Beta 3 bar 71 rettelser. 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 falt ut før Beta 3. Guidelines, RTC og utfasingen av Classic-blokken falt ut rundt den. Zip-filen som kom, er den kortere listen.

For nettstedseiere er den praktiske lærdommen uendret: les veikartet som en intensjonserklæring, ikke en garanti. Planlegg rundt det som faktisk landet, responsiv styling, klientsidig media, Playlist og Tabs, og iframe-editoren. Ikke lov en kunde en funksjon som fortsatt bar “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. Unicode-e-post ble slått sammen og så trukket. Det er den samme lærdommen.

#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 sikkerhetsproblemer 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 nå

• Utviklere: innleggseditoren er alltid i iframe. Blokker på API v2 eller lavere trenger en v3-runde. Detaljene står i noten om innleggseditoren i iframe. React 19 er fortsatt ikke i kjernen. Fortsett å teste mot den i Gutenberg-pluginet.
• Nettsteder på WP Rocket: en typefeil i Cloudflare-kompatibilitetsmodulen tar nettsteder offline på 7.1 (wp-media/wp-rocket#8596). Staging først, deretter produksjon. Drifter du butikker, er dette en WooCommerce-sjekk av ytelse og pålitelighet, ikke en kosmetikkrunde.
• Eldre nettsteder: Classic-blokken er fortsatt i innsetteren. Det er ingen tvungen migrering i 7.1. Gå gjennom den når du likevel rører innholdet, ikke fordi denne utgivelsen startet en klokke.
• Redaksjonsteam: Guidelines kom ikke. Ikke redesign arbeidsflyten rundt et Gutenberg-eksperiment.
• Alle: automatiske oppdateringer til 7.1 ruller. Test på staging, særlig om du kjører object cache, et sidecache-plugin eller egendefinert editor-JavaScript.

#Konklusjon

WordPress 7.1 Mary Lou er en nyttig plattformutgivelse med et litt misvisende navn. Samarbeidsprofilen var ekte intensjon. Samarbeidsfunksjonen kom ikke, andre syklus på rad. Skreller du bort innrammingen, er det du fikk 19. august mindre og fortsatt verdt å ta: responsiv styling som fjerner daglig friksjon, klientsidig media som stopper HEIC-opplastinger fra å treffe PHP-minnegrensen, Playlist og Tabs som stabile blokker, en vedvarende administrasjonslinje, og innleggseditoren alltid i iframe. Guidelines landet ikke. Avviklingen av Classic-blokken landet ikke. React 19 og Unicode-e-post ble værende ute. Gapet mellom juni-veikartet og august-zipen er nå målt, ikke spådd.

Den dypere historien er fortsatt 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 utgivelser lenge etter denne. Planlegg rundt det som landet. Test staging. Les neste veikart slik dette fortjente å leses: intensjon, inntil zip-filen finnes.

Sist oppdatert: 20. august 2026.