WordPress 7.1 sanntidssamarbeid: det andre forsøket, FSE-stil outreach-programmet og åtteukersfristen

Sanntidssamarbeid får et nytt forsøk i WordPress-kjernen. To uker før WordPress 7.0 ble lansert, trakk bidragsyterteamet ut det som skulle være hovedfunksjonen i utgivelsen. Begrunnelsen den gangen var ytelsesproblemer med databasen som teamet ikke kunne love å fikse innenfor lanseringsvinduet. Seks uker senere er den samme funksjonen tilbake på veikartet for WordPress 7.1, med et FSE-stil outreach-program i oppstart og lanseringsdatoen 19. august som forankrer kalenderen.

For byråer som driver redaksjonelle arbeidsflyter på WordPress, har dette konkrete konsekvenser. Flerforfatterredigering er den største arbeidsflytendringen i kjernen på over et tiår. Den endrer konfliktoverflaten på lange tekster, redefinerer hva en “lås” på et innlegg betyr, og forskyver hva blokkredaktøren faktisk er til for. 7.1-forsøket signaliserer også hvordan formen på WordPress-bidrag er i endring: Et outreach-program for noe som i bunn og grunn er et spørsmål om databasearkitektur, er et nytt format for prosjektet.

Vi har sett kunngjøringen, lest trådene på make.wordpress.org/core og deltatt i to tidlige outreach-samtaler. Det som følger er det byråene bør vite ved starten av 7.1-syklusen. I Norge merkes spenningen tydelig: NRK og Aftenposten kjører redaksjonelle arbeidsflyter med flere skribenter og desk-redaktører som tar tak i samme sak innenfor minutter, og det er nettopp slike miljøer som vil avgjøre om funksjonen tåler skalaen.

#Hva som ble trukket ut av 7.0 og hvorfor

Sanntidssamarbeid i blokkredaktøren trenger tre ting for å fungere i skala: en tilstedeværelses- og markørkanal med lav latens, en konfliktfri sammenslåingsstrategi for blokkendringer, og et lagringslag som kan holde den sammenslåtte historikken uten å ødelegge den eksisterende modellen med wp_posts og wp_postmeta.

Tilstedeværelses- og markørkanalen ble løst i 6.x-syklusen, med en kombinasjon av long-polling og en valgfri WebSocket-transport for nettsteder som er villige til å kjøre infrastrukturen. Den konfliktfrie sammenslåingsstrategien landet i Gutenberg-pluginet sent i 2025 med en CRDT-basert tilnærming. Den tredje brikken, lagringslaget, er der 7.0 brakk.

7.0-implementasjonen persisterte samarbeidstilstanden i en ny tabell knyttet til innleggsrevisjoner. På mindre installasjoner fungerte dette. I skalaen til et Automattic-testmiljø med 50 000+ samtidige redigeringer skapte skrivingene til den nye tabellen replikeringsetterslep og lock contention så alvorlig at teamet flagget det som lanseringsblokker. Beslutningen om å trekke funksjonen ble tatt i midten av april, to uker før GA-datoen for 7.0.

Anne McCarthys kunngjøring av det nye outreach-programmet erkjenner at databasearkitekturen fortsatt er det åpne spørsmålet: Teamet har hypoteser om hvordan det kan fikses, men ingen vedtatt implementasjon ved starten av 7.1-syklusen. Det er uvanlig for en funksjon som er målrettet mot en lansering.

#Høna-og-egget-problemet

Amy Kamala, co-representant for Hosting-teamet, oppsummerte situasjonen i én setning: “Need testing to make decision, need decision to do testing.”

De arkitektoniske valgene for lagringslaget har svært forskjellige kostnadsprofiler for ulike hostingmiljøer. En løsning som fungerer bra på en single-server-installasjon, overlever kanskje ikke et load-balansert oppsett med leserepliker. En løsning som passer i et single-tenant managed-hosting-miljø, fungerer kanskje ikke på multisite i den skalaen WordPress.com kjører.

7.0-syklusen prøvde å ta den arkitektoniske beslutningen på forhånd og deretter teste den. Den rekkefølgen sviktet, fordi testresultatene gjorde beslutningen ugyldig og det ikke var tid til å korrigere kursen. 7.1-syklusen forsøker å snu rekkefølgen: velg testscenariene først, valider hvilke arkitektoniske varianter som overlever dem, og la den overlevende varianten bestemme implementasjonen.

Dette er det samme mønsteret Full-Site Editing-teamet brukte i syklusen fra 5.8 til 6.0, da gapet mellom bidragsytermiljø og reelle hostingmiljøer produserte gjentatte regresjoner. FSE-outreach-programmet skapte en rekruttert testerpopulasjon som kjørte ekte nettsteder med ekte plugins, og programmet avslørte feil som bidragsyterteamet ikke ville fanget i isolasjon.

Å bruke det samme mønsteret på sanntidssamarbeid er det nye strukturelle grepet. Det er også grunnen til at hostingselskaper blir bedt om å hjelpe med å rekruttere testere fra sin managed-kundebase.

#Formen på outreach-programmet

Anne McCarthys kunngjøring posisjonerer testerpopulasjonen i tre lag:

1. Utviklerorientert testing. Den eksisterende testsyklusen. Plugins, temaer, REST API-overflate, ytelsesregresjoner. Drevet av bidragsytere og på Automattic-infrastruktur.
2. Enterprise- og deterministisk testing. Drevet med hostingpartnere på managed-kundemiljøer med kontrollert belastning. Designet for å validere at lagringsarkitekturen overlever scenarier med databasekontensjon.
3. Passionate real-world early adopters. Det nye laget. Rekruttert fra byråer, utgivere og innholdsteam som driver produksjons-WordPress-nettsteder med redaksjonelt samarbeid som et reelt arbeidsflytkrav.

Det tredje laget er der mesteparten av den nye testkapasiteten vil komme fra. Outreach-programmet ber eksplisitt om nettsteder der sanntidssamarbeid løser et reelt problem, ikke om syntetiske testinstallasjoner.

Det testerne blir bedt om:

• Aktive redaksjonelle arbeidsflyter med mer enn én forfatter som jobber samtidig på lange tekster
• Vilje til å kjøre en release-candidate-build mot staging-miljøer
• Rapporteringssyklus: ukentlige check-ins med et strukturert tilbakemeldingsskjema
• Feilrapporter som fanger både redigeringsoppførsel og databasenivåmetrikker fra hostinglaget

Det testerne får:

• Direkte linje til bidragsyterteamet som driver funksjonen
• Innsyn i de arkitektoniske beslutningene mens de tas
• Sponsoranerkjennelse for nettsteder som kjører forlengede testsykluser
• Den tidligst mulige forhåndsvisningen av hva sanntidssamarbeid vil bety for den redaksjonelle prosessen

For byråer med utgiverkunder er dette den mest direkte måten å være i rommet på når funksjonen ferdigstilles. Byråfordelen er ikke anerkjennelsen. Det er teknisk innsyn på forhånd.

#19. august-datoen og hvorfor den betyr noe

WordPress 7.1 er planlagt til 19. august. Den datoen er ikke tilfeldig. Den sammenfaller med WordCamp US i Phoenix, der lanseringen skal feires som en del av konferanseprogrammet. Lanseringsdatoen forankrer også hele testkalenderen for 7.1.

Regnet bakover fra 19. august:

• Slutten av juli: Release Candidate 1. Feature freeze. RTC må være stabil nok for et bredt testpublikum. Den arkitektoniske beslutningen om databasen må være låst.
• Midten av juli: Beta 3. Siste mulighet for atferdsendringer. Outreach-programdata bør informere beslutninger, ikke starte dem.
• Tidlig juli: Beta 2. Siste mulighet for ikke-trivielle arkitekturendringer. Testdata fra hostingpartnerne bør være inne.
• Slutten av juni: Beta 1. Første bredt testede build. Lagringsarkitekturen bør være vedtatt innen da.
• Midten av juni: oppstart av outreach-programmet. Rekrutterte testere kjører staging-builds. Første tilbakemeldingsrunde.
• Nå (tidlig juni): rekruttering. Hostingselskaper rekrutterer testere, bidragsyterteamet planlegger outreach-materialet.

Åtte uker er nok tid. Det er ikke nok tid til en arkitektonisk restart. Implikasjonen for byråer som følger med: gå ut fra at den arkitektoniske beslutningen tas innen utgangen av juni. Hvis du har en sterk mening eller produksjonsdata som bør informere den, gi det til bidragsyterteamet i de neste tre ukene.

#Det sanntidssamarbeid endrer i byråarbeidsflyter

Legg databasespørsmålet til side et øyeblikk. Hvordan ser WordPress med sanntidssamarbeid faktisk ut for byråer?

Tre konkrete arbeidsflytendringer som følger med funksjonen:

• Redaksjonelle review-løkker kollapser. Den nåværende WordPress-redaksjonsflyten er sekvensiell. Forfatter skriver. Redaktør gjennomgår etter at forfatteren er ferdig. Forfatter adresserer kommentarer. Redaktør godkjenner. Med sanntidssamarbeid kan forfatter og redaktør jobbe samtidig. For byråer som driver redaksjonelle kalendere for innholdskunder, reduserer dette syklustiden per artikkel og endrer hvordan fakturerbare timer ser ut. I norske nyhetsredaksjoner der desk-redaktøren ofte jobber parallelt med skribenten under en time-down, kan funksjonen kutte håndoverlag som i dag spiser opp produksjonstid.
• Plugin-kompatibilitet blir et levende problem. Mange av de mest installerte redaksjons-pluginene antar enkeltforfatterredigering. ACF-feltlagringer, Yoast SEO-analyse, Rank Math-metabox-oppdateringer, egendefinerte taksonomi-metabokser og en lang hale av byråbygde plugins må alle gjennomgås for sikker samtidig skriving. Plugin Review Team har vært tydelige på at sanntidssamarbeid vil avsløre plugins med utrygge skrivemønstre.
• “Post lock”-UX-en byttes ut. Den velkjente “dette innlegget redigeres for øyeblikket av…”-modalen som har vært levert siden WordPress 3.6, fases ut til fordel for tilstedeværelsesindikatorer. Brukere som har vært trent på den gamle oppførselen i et tiår, må lære det nye mønsteret. Intern kommunikasjon og opplæringsmateriale må oppdateres.

Dette er ikke kanttilfeller. Det er dag-én-brukervirkningen av at funksjonen lanseres.

#Spørsmålet om databasearkitektur, forenklet

Den ingeniørtekniske kjerneutfordringen er enkel. WordPress lagrer innleggsinnhold i wp_posts.post_content som en enkelt blob. Revisjoner lager nye rader. Sanntidssamarbeid må slå sammen samtidige redigeringer inn i denne bloben uten å miste data og uten å skape en revisjonsvekst som løper løpsk.

De tre arkitektoniske variantene som diskuteres for øyeblikket:

1. Append-only operasjonslogg. En ny tabell lagrer enkeltoperasjoner (sett inn, slett, formatendring) med tidsstempler og forfatter-ID-er. post_content-bloben rekonstrueres fra operasjonsloggen ved lagring. Pluss: ren konflikthåndtering. Minus: høyt skrivevolum til den nye tabellen.
2. Snapshot pluss deltaer. Periodiske snapshots av post_content pluss delta-poster mellom snapshots. Pluss: begrenset skrivevolum. Minus: timing-logikken for snapshots er kompleks og gjenoppretting etter tapte snapshots vanskelig.
3. In-memory-sammenslåing med periodisk persistering. Samarbeidstilstanden holdes i minnet i applikasjonslaget, persistert til post_content og en enkelt revisjonsrad ved intervaller eller eksplisitt lagring. Pluss: lavt skrivevolum til databasen. Minus: krever sticky sessions eller et delt cache-lag.

Hver variant har implikasjoner for hosting. Variant 1 belaster databasen. Variant 2 belaster applikasjonslaget med timing-logikk. Variant 3 belaster cache- og sesjonsinfrastrukturen, altså typisk Redis eller Memcached og passende konfigurerte PHP-FPM-pools.

Outreach-programmet for 7.1 er designet for å teste alle tre variantene mot realistiske hostingkonfigurasjoner. Hvilken variant som overlever, er den arkitektoniske beslutningen teamet må ta innen utgangen av juni.

#Hva byråer bør gjøre denne måneden

Tre konkrete grep for byråer som driver WordPress for utgiver- eller redaksjonskunder.

1. Revider din redaksjonelle plugin-stack. Hver plugin som kobler seg på save_post, wp_insert_post_data eller block editor-metalagringer, er en kandidat for samtidig skriving. List opp pluginene, noter forfatterne og sjekk om forfatterne har offentlige uttalelser om RTC-kompatibilitet. De uten uttalelser er de man må planlegge rundt.
2. Meld inn en utgiverkunde til outreach-programmet. Hvis du har en kunde med to eller flere redaktører som jobber på samme innholdsflate, vil outreach-teamet ha den arbeidsflyten. Innmeldingen plasserer kunden din i testpopulasjonen og deg i rommet for arkitekturdiskusjonen. Innmeldingen går via make.wordpress.org/core-innlegget som er lenket fra McCarthys kunngjøring.
3. Forbered intern opplæring til post-lock-UX-endringen. Selv om kundene dine ikke aktivt bruker sanntidssamarbeid, vil den synlige endringen i “innlegget er låst”-oppførselen generere supportbilletter i august. Ha en énsiders forklaring klar.

#Det større mønsteret: Bidragsformen er i endring

Bak 7.1-syklusen ligger en strukturell historie som går utover funksjonen.

For det meste av sin historie har WordPress-kjerneutvikling vært drevet av bidragsyterbeslutninger testet mot bidragsytermiljøer. FSE-outreach-programmet i syklusen fra 5.8 til 6.0 var det første forsøket på å formelt inkorporere reell testing i kjernens beslutningssløyfe. Outreach-programmet for sanntidssamarbeid i 7.1 er det andre.

Mønsteret er at prosjektet blir mer avhengig av input fra produksjonsmiljøer og mindre i stand til å lande hovedfunksjoner på bidragsytermiljøer alene. Det er det samme skiftet modne åpen kildekode-prosjekter går gjennom når installasjonsbasen deres diversifiserer seg. Det endrer også hvem som har innflytelse på retningen. Byråer som driver ekte kundenettsteder med ekte redaksjonelle arbeidsflyter, er stadig oftere de personene hvis tilbakemelding former kjernen. Det er en legitim plass ved bordet som ikke fantes en lanseringssyklus eller to tidligere. Nordiske bidragsytere som Birgit Olzem og det norske WordPress-Norge-fellesskapet har lenge etterspurt akkurat denne typen samarbeidsstruktur.

For norske og europeiske byråer er implikasjonen direkte: WCEU i Kraków denne uken kommer til å være vert for samtaler om RTC-testpartnerskap i korridorene, mellom sponsorpausene og over kaffe. Møt opp der.

#Konklusjonen

Sanntidssamarbeid er ennå ikke en lansert funksjon. Beslutningen om databasearkitektur er ennå ikke tatt. Outreach-programmet rekrutterer fortsatt. Ingenting av dette er avgjort.

Det som er avgjort: funksjonen er tilbake på veikartet, lanseringsdatoen 19. august er det arbeidende ankeret, teststrategien er utvidet utover enterprise- og bidragsytermiljøer, og hostingselskaper blir bedt om å hjelpe med å rekruttere produksjonstestere. Hvis den arkitektoniske beslutningen lander innen utgangen av juni og outreach-dataene validerer den, leverer WordPress 7.1 funksjonen på WordCamp US.

For byråer med redaksjonelle kunder er dette lanseringssyklusen man bør delta i. Formen på flerforfatterredigering i WordPress for resten av tiåret blir definert i de neste åtte ukene.

Kunngjøringen på make.wordpress.org/core og detaljene i outreach-programmet finnes på Make WordPress Core. Dekningen fortsetter på The Repository og på WPPoland-bloggen gjennom hele 7.1-syklusen.

Sist oppdatert: 2026-06-06.