Sanntidssamarbeid i WordPress

Sanntidssamarbeid fikk et nytt forsøk i WordPress-kjernen, og det bommet igjen. 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 var den samme funksjonen tilbake på veikartet for WordPress 7.1, med et FSE-inspirert testprogram og 19. august som kalenderanker.

WordPress 7.1 Mary Lou ble lansert 19. august 2026 uten live flerbrukerredigering. Det er to major-utgivelser på rad. Resten av denne artikkelen er syklusen slik den sto, pluss det byråene bør gjøre nå som pakken ikke inneholder funksjonen.

For byråer som driver redaksjonelle arbeidsflyter på WordPress, har missen konkrete konsekvenser. Flerforfatterredigering ville fortsatt være den største arbeidsflytendringen i kjernen på over et tiår. Den ville endre konfliktoverflaten på lange tekster, redefinere hva en lås på et innlegg betyr, og forskyve hva blokkredaktøren faktisk er til for. Ingenting av det kom i 7.1. Ikke tren kundene på en erstatning for innleggslåsen som ikke er der.

I Norge merkes spenningen tydelig: NRK og Aftenposten kjører redaksjonelle arbeidsflyter med flere skribenter og deskredaktø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 testprogrammet 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 teamet for full nettstedsredigering brukte i syklusen fra 5.8 til 6.0, da gapet mellom bidragsytermiljø og reelle hostingmiljøer produserte gjentatte regresjoner. FSE-testprogrammet skapte en rekruttert testergruppe 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å testprogrammet

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. Engasjerte brukere fra virkelige miljøer. 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 lanseringskandidat i testmiljø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 hva den faktisk leverte

WordPress 7.1 Mary Lou ble lansert 19. august på WordCamp US i Phoenix. Datoen holdt. Sanntidssamarbeid gjorde det ikke. Testkalenderen under er syklusen slik den var planlagt i juni, beholdt her fordi den viser hvor lite rom en arkitektonisk restart noensinne hadde.

Regnet bakover fra 19. august:

• Slutten av juli: første lanseringskandidat. Funksjonsstopp. 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 bygg. Lagringsarkitekturen bør være vedtatt innen da.
• Midten av juni: oppstart av testprogrammet. Rekrutterte testere kjører bygg i testmiljøer. Første tilbakemeldingsrunde.
• Tidlig juni: rekruttering. Det var planen. Hostingselskaper skulle rekruttere testere. Funksjonen kom likevel ikke med i zip-filen.

Åtte uker var nok tid til en låst arkitektur. Det var ikke nok tid til en arkitektonisk restart. Arkitekturbeslutningen var fortsatt åpen da syklusen startet. 7.1 ble lansert uten funksjonen. 7.2 er foreløpig satt til 9. desember 2026. Behandle det som en planleggingsdato, ikke som RTC.

#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 ville blitt byttet ut. Den velkjente “dette innlegget redigeres for øyeblikket av…”-modalen siden WordPress 3.6 ville vike for tilstedeværelsesindikatorer. Det skjedde ikke i 7.1. Den gamle modalen er fortsatt det brukerne ser.

Dette er ikke kanttilfeller. Det er dag-én-brukervirkningen hvis funksjonen noensinne lanseres. Den ble ikke lansert i 7.1, så ingenting av dette er en supportbillett 19. august. Behold plugin-revisjonen. Ikke skriv om opplæringsmateriale for en UX som ikke ligger i kjernen.

#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 skulle teste disse variantene mot realistiske hostingkonfigurasjoner. Arkitekturbeslutningen skulle lande innen utgangen av juni. Den gjorde det ikke i tide. 7.1 ble lansert uten RTC.

#Hva byråer bør gjøre nå

Tre konkrete grep etter 7.1-missen.

1. Ikke lov kundene live flerbrukerredigering i 7.1. Den er ikke der. Sekvensiell redaksjonsflyt er fortsatt produktet.
2. Revider den redaksjonelle pluginlisten din likevel. Hver plugin som kobler seg på save_post, wp_insert_post_data eller metalagringer i blokkredigereren, er en kandidat for samtidig skriving når RTC kommer tilbake. Listen er nyttig selv om funksjonen er en syklus unna.
3. Ikke skriv om post-lock-opplæringen til august. Modalen “dette innlegget redigeres for øyeblikket av…” er fortsatt 7.1-oppførselen. Spar énsidersforklaringen til en feltguide sier at tilstedeværelsesindikatorer er lansert.

#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-testprogrammet i syklusen fra 5.8 til 6.0 var det første forsøket på å formelt inkorporere reell testing i kjernens beslutningssløyfe. Testprogrammet 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 var korridorsamtalene på WCEU i Kraków i juni rekrutteringen til testpartnerskap. Den rekrutteringen ga ikke en 7.1-lansering. Neste dato i kalenderen er 7.2, foreløpig satt til 9. desember 2026 sammen med State of the Word. Møt opp i de samtalene med produksjonsdata, ikke med et salgslysbilde som sier at RTC ligger i kjernen.

#CRDT mot Operational Transformation (OT): Det matematiske grunnlaget

Utfordringene med å innføre samtidig redigering i WordPress skyldes fundamentale teknologiske valg:

• Conflict-free Replicated Data Types (CRDT): Verktøy som Yjs tillater kollisjonsfri sammenslåing av tekstendringer uten en sentral server. Ulempen er at datastrukturene krever betydelig minne i nettleseren ved store artikler.
• Operational Transformation (OT): Den klassiske metoden fra Google Docs krever en sentral tjener som transformerer operasjoner i sanntid. Dette er mer krevende å drifte på standard delte webhotell.
• Arkitekturlåsen i WordPress: Å forene moderne sanntidsmodeller med WordPress sitt tradisjonelle post_content-felt i MySQL krevde mer tid enn det åtteukers utviklingsløpet ga rom for.

#Utfordringer for driftsmiljøer: WebSockets og PHP-FPM

Klassiske webhotell er ikke bygget for tusenvis av vedvarende tilkoblinger:

• PHP-FPMs begrensninger: PHP er designet for raske, isolerte forespørsler. Å holde forbindelser åpne for sanntidsvisning av markører krever separate hendelsestjenere (som Node.js, Go eller Cloudflare Durable Objects).
• Håndtering av tilstedeværelse (Presence): Å vise hvor andre redaktører til enhver tid har markøren sin genererer en jevn strøm av datapakker som tradisjonelle Apache- og Nginx-oppsett sliter med å håndtere uten dedikert infrastruktur.

#Blokkbaserte rettigheter og revisjonsspor

Flerbrukerredigering krever nye sikkerhetsfunksjoner i publiseringsverktøyet:

• Låsing på blokknivå: I stedet for å låse hele artikkelen må systemet kunne låse enkeltavsnitt midlertidig mens de redigeres.
• Detaljert endringshistorikk: Bedriftskunder krever full sporbarhet for hver endring som utføres underveis.

#Endringer for utvidelser og metadata (ACF og SEO-bokser)

Samtidig redigering krever omfattende oppdateringer fra tredjepartsutviklere:

• Håndtering av kollisjoner i metadata: Når to redaktører oppdaterer en artikkel samtidig, risikerer tradisjonelle metabokser å overskrive hverandres data. Utvidelser må derfor gå over til atomiske feltoppdateringer for å bevare dataintegriteten.
• Beregninger i bakgrunnen med Web Workers: SEO-verktøy som analyserer teksten fortløpende, må flytte tunge beregninger ut av hovedtråden i nettleseren for å forhindre hakking og forsinkelser under skriving.

#Praktiske råd for redaksjoner i påvente av ny funksjonalitet

Frem til samtidig redigering lanseres offisielt, bør byråer og redaksjoner opprettholde ryddige rutiner:

• Tydelig arbeidsflyt: Bevar den etablerte sekvensielle prosessen der forfatter, språkvasker og redaktør arbeider i definerte faser for å unngå redaksjonelle misforståelser.
• Teknisk gjennomgang: Test egne utvidelser for å sikre at de tåler fremtidige oppdateringer i WordPress-kjernen. Profesjonell arbeidsmetodikk sikrer trygg publisering og forutsigbare resultater over tid.

#Veien videre mot WordPress 7.2 og fremtidens publisering

At flerbrukerredigering utsettes til neste store milepæl i utviklingsløpet, vitner om faglig modenhet og ansvarsfølelse:

• Trygghet og stabilitet trumfer raske lanseringer: For profesjonelle publisister og bedrifter er tap av innhold som følge av synkroniseringsfeil helt uakseptabelt. Beslutningen om å bruke nødvendig tid på databasemodellen beskytter millioner av aktive nettsteder mot ustabilitet i drift.
• Gode standarder for det åpne nettet: Innsikten som er høstet gjennom testprogrammene i versjon 7.1 danner et solid grunnlag for en fremtidig løsning som fungerer knirkefritt under reelle driftsforhold. Tålmodig og nøyaktig systemutvikling sikrer at WordPress forblir verdens ledende publiseringssystem i mange år framover.
• Investering i pålitelighet: Å prioritere feilfri funksjonalitet framfor kunstige tidsfrister bygger langsiktig tillit hos både utviklere og bedriftskunder. Grundig ingeniørarbeid er alltid den beste strategien for digital suksess. Kvalitetsbevisst utvikling og ryddige prosesser gir forutsigbarhet for alle parter. Profesjonalisme i alle ledd skaper trygghet for virksomheten.

#Konklusjonen

Sanntidssamarbeid er ikke en lansert funksjon. Den bommet på 7.0 og den bommet på 7.1. Beslutningen om databasearkitektur ble ikke låst i tide. Outreach-programmet fikk ikke funksjonen over streken.

Det som er avgjort: 7.1 Mary Lou ble lansert 19. august uten live flerbrukerredigering. Sekvensiell redaksjonsflyt er fortsatt det du kjører. Følg Make WordPress Core for det 7.2 faktisk lister. Ikke behandle et desembermål som en lanseringsdato.

Trådene på make.wordpress.org/core er fortsatt den primære kilden. Dekningen av det 7.1 faktisk lanserte ligger i veikartnotatet for 7.1.

Sist oppdatert: 2026-06-06.