WordPress 7.1 real-time collaboration: druga próba, program outreach w stylu FSE i ośmiotygodniowy deadline

Real-time collaboration dostaje drugą szansę w corze WordPressa. Dwa tygodnie przed wydaniem WordPress 7.0 zespół kontrybutorów wycofał to, co miało być headline feature wydania. Powodem podanym wtedy były problemy wydajnościowe bazy danych, których zespół nie mógł zobowiązać się naprawić w oknie release. Sześć tygodni później ta sama funkcja wraca na roadmap WordPress 7.1, z programem outreach w stylu FSE w starcie i datą release 19 sierpnia kotwiczącą kalendarz.

Dla agencji prowadzących workflowy redakcyjne na WordPressie ma to konkretne znaczenie. Edycja wieloautorska to największa zmiana workflowowa wprowadzona do corze od ponad dekady. Zmienia powierzchnię konfliktu na długich tekstach, redefiniuje, co oznacza lock na wpisie, i przesuwa to, czym jest block editor. Próba 7.1 sygnalizuje również, jak zmienia się kształt kontrybucji do WordPressa: program outreach dla czegoś, co fundamentalnie jest pytaniem o architekturę bazy danych, to nowy kształt dla projektu.

Obejrzeliśmy ogłoszenie, przeczytaliśmy wątki na make.wordpress.org/core i byliśmy w dwóch wczesnych rozmowach outreachowych. Poniżej to, co agencje powinny wiedzieć na początku cyklu 7.1.

#Co zostało wycofane z 7.0 i dlaczego

Real-time collaboration w block editorze potrzebuje trzech rzeczy, by działało na skalę: kanału obecności i kursorów o niskim latency, bezkonfliktowej strategii mergowania zmian bloków oraz warstwy magazynowania, która utrzyma zmergowaną historię bez łamania istniejącego modelu wp_posts i wp_postmeta.

Kanał obecności i kursorów został rozwiązany w cyklu 6.x, używając kombinacji long-polling i opcjonalnego transportu WebSocket dla stron gotowych uruchomić infrastructure. Bezkonfliktowa strategia mergowania wlądowała do wtyczki Gutenberg pod koniec 2025 z podejściem opartym na CRDT. Trzeci element, warstwa storage, to miejsce gdzie 7.0 się złamało.

Implementacja 7.0 persystowała stan kolaboracji w nowej tabeli związanej z revisions wpisu. Na mniejszych instalacjach to działało. W skali środowiska testowego Automattic z 50000+ współbieżnych edycji zapisy do nowej tabeli tworzyły replication lag i lock contention na tyle poważne, że zespół zgłosił to jako blocker release. Decyzja o wycofaniu została podjęta w połowie kwietnia, dwa tygodnie przed datą GA 7.0.

Ogłoszenie Anne McCarthy o nowym programie outreach przyznaje, że architektura bazy danych nadal jest otwartym pytaniem: zespół ma hipotezy, jak ją naprawić, ale nie ma zatwierdzonej implementacji w momencie startu cyklu 7.1. To nietypowe dla funkcji celowanej na release.

#Problem jajka i kury

Co-rep Hosting Team Amy Kamala podsumowała sytuację w jednym zdaniu: “Need testing to make decision, need decision to do testing.”

Wybory architektoniczne dla warstwy storage mają bardzo różne profile kosztów dla różnych środowisk hostingowych. Rozwiązanie działające dobrze na instalacji single-server może nie przeżyć setupu load-balanced z replikami read. Rozwiązanie pasujące single-tenant managed-hosting może nie zadziałać na multisite w skali, w jakiej działa WordPress.com.

Cykl 7.0 próbował podjąć decyzję architektoniczną z góry i potem ją testować. Ta kolejność zawiodła, bo wyniki testów unieważniły decyzję, a nie było czasu na kurs korekcyjny. Cykl 7.1 próbuje odwrócić kolejność: wybrać scenariusze testowe pierwsze, zwalidować, które warianty architektoniczne je przeżyją, i niech wariant który przeżyje określi implementację.

To ten sam wzorzec, którego zespół Full-Site Editing użył w cyklu 5.8 do 6.0, gdy luka między środowiskiem kontrybutorów a realnymi środowiskami hostingowymi produkowała powtarzalne regresje. Program outreach FSE stworzył rekrutowaną populację testerów uruchamiających realne strony z realnymi wtyczkami i wypływał bugi, których zespół kontrybutorów nie złapałby w izolacji.

Zastosowanie tego samego wzorca do real-time collaboration to nowy strukturalny ruch. To też powód, dla którego hostingi są proszone o pomoc w rekrutacji testerów ze swojej bazy klientów zarządzanych.

#Kształt programu outreach

Anne McCarthy w ogłoszeniu pozycjonuje populację testową w trzech warstwach:

1. Testowanie zorientowane na deweloperów. Istniejący cykl testów. Wtyczki, motywy, powierzchnia REST API, regresje wydajności. Prowadzone przez kontrybutorów i na infrastrukturze Automattic.
2. Testowanie enterprise i deterministyczne. Prowadzone z partnerami hostingowymi na środowiskach zarządzanych klientów z kontrolowanym obciążeniem. Zaprojektowane, by zwalidować, że architektura storage przeżyje scenariusze kontencji bazy danych.
3. Passionate real-world early adopters. Nowa warstwa. Rekrutowani z agencji, wydawców i zespołów treści uruchamiających produkcyjne strony WordPressa z kolaboracją redakcyjną jako realnym wymogiem workflowu.

Trzecia warstwa to skąd pójdzie większość nowej przepustowości testów. Outreach jawnie prosi o strony, na których real-time collaboration rozwiązuje realny problem, a nie o syntetyczne instalacje testowe.

O co prosi się testerów:

• Aktywne workflowy redakcyjne z więcej niż jednym autorem pracującym jednocześnie na długich tekstach
• Gotowość do uruchomienia builda release-candidate wobec środowisk staging
• Cykl raportowania: cotygodniowy check-in ze strukturalnym formularzem feedbacku
• Zgłoszenia bugów łapiące zachowanie edytora i metryki bazy danych z warstwy hostingowej

Co dostają testerzy:

• Bezpośredni kontakt z zespołem kontrybutorów prowadzącym funkcję
• Wgląd w decyzje architektoniczne w trakcie ich podejmowania
• Uznanie sponsoringowe dla stron prowadzących dłuższe cykle testów
• Najwcześniejszy możliwy pogląd na to, co real-time collaboration będzie znaczyć dla ich procesu redakcyjnego

Dla agencji z klientami wydawniczymi to najbardziej bezpośredni sposób, by być w pokoju, gdy funkcja jest finalizowana. Korzyść agencyjna to nie uznanie. To engineering preview.

#Data 19 sierpnia i dlaczego ma znaczenie

WordPress 7.1 jest zaplanowany na 19 sierpnia. Ta data nie jest arbitralna. Pokrywa się z WordCamp US w Phoenix, gdzie release będzie celebrowane jako część programu konferencji. Data release też kotwiczy cały kalendarz testów 7.1.

Pracując wstecz od 19 sierpnia:

• Koniec lipca: Release Candidate 1. Feature freeze. RTC musi być stabilne na tyle, by szeroka publika testowa. Decyzja architektoniczna bazy danych musi być zamknięta.
• Połowa lipca: Beta 3. Ostatnia możliwość zmian zachowań. Dane z programu outreach powinny informować decyzje, nie je inicjować.
• Początek lipca: Beta 2. Ostatnia możliwość nietrywialnych zmian architektonicznych. Dane testowe partnerów hostingowych powinny być w.
• Koniec czerwca: Beta 1. Pierwszy szeroko testowany build. Architektura storage powinna być już zatwierdzona.
• Połowa czerwca: ramp programu outreach. Rekrutowani testerzy uruchamiają buildy staging. Pierwszy cykl feedbacku.
• Teraz (początek czerwca): rekrutacja. Hostingi rekrutują testerów, zespół kontrybutorów scopuje materiał outreachowy.

Osiem tygodni to wystarczająco. Nie wystarczająco na restart architektoniczny. Implikacja dla agencji śledzących to: załóż, że decyzja architektoniczna zostanie podjęta do końca czerwca. Jeśli masz mocną opinię lub dane produkcyjne, które mogłyby ją informować, daj to zespołowi kontrybutorów w następnych trzech tygodniach.

#Co real-time collaboration zmienia w workflowach agencyjnych

Odłóżmy pytanie o bazę danych na chwilę. Jak WordPress z real-time collaboration faktycznie wygląda dla agencji?

Trzy konkretne zmiany workflowowe, które przychodzą z funkcją:

• Pętle review redakcyjnego się kompresują. Obecny workflow redakcyjny WordPressa jest sekwencyjny. Autor pisze. Redaktor review po skończeniu autora. Autor adresuje komentarze. Redaktor zatwierdza. Z real-time collaboration autor i redaktor mogą pracować jednocześnie. Dla agencji prowadzących kalendarze redakcyjne dla klientów content to redukcja cyklu per-artykuł i zmiana tego, jak wyglądają billable hours.
• Kompatybilność wtyczek staje się żywym problemem. Wiele najczęściej instalowanych wtyczek redakcyjnych zakłada edycję jednoautorską. Zapisy pól ACF, analiza Yoast SEO, aktualizacje metabox Rank Math, customowe meta boxy taxonomii i długi ogon wtyczek budowanych agencyjnie, wszystkie wymagają review pod kątem bezpieczeństwa współbieżnego zapisu. Plugin Review Team jasno powiedział, że real-time collaboration wypływa wtyczki z niebezpiecznymi wzorcami zapisu.
• UX “post lock” zostaje zastąpiony. Znajomy modal “ten wpis jest aktualnie edytowany przez…” dostarczany od WordPress 3.6 jest deprecjonowany na rzecz wskaźników obecności. Użytkownicy trenowani na starym zachowaniu przez dekadę będą musieli nauczyć się nowego wzorca. Komunikacja wewnętrzna i materiały szkoleniowe wymagają aktualizacji.

To nie są edge case. To day-one user-facing wpływ release funkcji.

#Pytanie o architekturę bazy danych, uproszczone

Główne wyzwanie inżynierskie jest proste. WordPress przechowuje treść wpisu w wp_posts.post_content jako pojedynczy blob. Revisje tworzą nowe wiersze. Real-time collaboration musi zmergować współbieżne edycje w ten blob bez utraty danych i bez tworzenia runaway wzrostu revisji.

Trzy warianty architektoniczne aktualnie pod dyskusją:

1. Append-only operational log. Nowa tabela przechowuje pojedyncze operacje (insert, delete, zmiana formatowania) z timestampami i ID autorów. Blob post_content jest rekonstruowany z operational log na zapis. Plus: czysta resolucja konfliktów. Minus: duży wolumen zapisu do nowej tabeli.
2. Snapshot-plus-deltas. Periodyczne snapshoty post_content plus rekordy delta między snapshotami. Plus: ograniczony wolumen zapisu. Minus: logika timing snapshotów jest złożona, a recovery z pominiętych snapshotów trudny.
3. In-memory merge z periodyczną persistencją. Stan kolaboracji trzymany w pamięci w warstwie aplikacyjnej, persystowany do post_content i pojedynczego wiersza revisji co interwał lub na jawny zapis. Plus: niski wolumen zapisu do bazy. Minus: wymaga sticky sessions lub wspólnej warstwy cache.

Każdy wariant ma implikacje dla hostingu. Wariant 1 obciąża bazę danych. Wariant 2 obciąża warstwę aplikacyjną z logiką timing. Wariant 3 obciąża infrastructure cache i sesji.

Program outreach 7.1 jest projektowany, by testować wszystkie trzy warianty wobec realistycznych konfiguracji hostingowych. Który wariant przeżyje to decyzja architektoniczna, którą zespół musi podjąć do końca czerwca.

#Co agencje powinny zrobić w tym miesiącu

Trzy konkretne ruchy dla agencji prowadzących WordPressa dla klientów wydawniczych lub redakcyjnych.

1. Zaudytuj swój redakcyjny stack wtyczek. Każda wtyczka podpinająca się pod save_post, wp_insert_post_data lub zapisy meta block editora jest kandydatem do współbieżnego zapisu. Wypisz wtyczki, zapamiętaj autorów i sprawdź, czy autorzy mają publiczne deklaracje o kompatybilności z RTC. Te bez deklaracji to te, wokół których trzeba planować.
2. Zgłoś klienta wydawniczego do programu outreach. Jeśli masz klienta z dwoma lub więcej redaktorami pracującymi na tej samej powierzchni treści, zespół outreach chce ten workflow. Zgłaszanie umieszcza twojego klienta w populacji testowej i umieszcza ciebie w pokoju rozmowy architektonicznej. Zgłoszenie idzie przez post na make.wordpress.org/core z ogłoszenia McCarthy.
3. Przygotuj wewnętrzne szkolenie do zmiany UX post-lock. Nawet jeśli twoi klienci nie korzystają aktywnie z real-time collaboration, widoczna zmiana zachowania “wpis jest zablokowany” zaserwuje tickety supportu w sierpniu. Miej gotowe jednostronicowe wyjaśnienie.

#Większy wzorzec: kształt kontrybucji się zmienia

Za cyklem 7.1 stoi strukturalna historia wykraczająca poza funkcję.

Przez większość swojej historii development corze WordPressa był napędzany decyzjami kontrybutorów testowanymi wobec środowisk kontrybutorów. Program outreach FSE w cyklu 5.8 do 6.0 był pierwszą próbą formalnej integracji testowania real-world w pętlę decyzji corze. Outreach real-time collaboration na 7.1 to drugi.

Wzorzec jest taki, że projekt staje się bardziej zależny od inputu ze środowisk produkcyjnych i mniej zdolny do landowania headline funkcji na środowiskach kontrybutorów samodzielnie. To ta sama zmiana, przez którą przechodzą dojrzałe projekty open source, gdy ich baza instalacji się dywersyfikuje. Zmienia też, kto ma wpływ na kierunek. Agencje uruchamiające realne strony klienckie z realnymi workflowami redakcyjnymi są coraz częściej osobami, których feedback kształtuje corze. To uzasadnione miejsce przy stole, którego nie było cykl lub dwa wcześniej.

Dla polskich i europejskich agencji implikacja jest bezpośrednia: WCEU w Krakowie w tym tygodniu będzie miejscem rozmów o partnerstwie testowym RTC na korytarzach, między sponsorowanymi przerwami i przy kawie. Bywajcie na nich.

#Bottom line

Real-time collaboration nie jest jeszcze wysłaną funkcją. Decyzja architektoniczna bazy danych nie została jeszcze podjęta. Program outreach nadal rekrutuje. Nic z tego nie jest przesądzone.

Co jest zdecydowane: funkcja wróciła na roadmap, data release 19 sierpnia to robocza kotwica, strategia testów została poszerzona poza enterprise i środowiska kontrybutorów, a hostingi są proszone o pomoc w rekrutacji testerów produkcyjnych. Jeśli decyzja architektoniczna ląduje do końca czerwca i dane outreach ją zwalidują, WordPress 7.1 dostarcza funkcję na WordCamp US.

Dla agencji z klientami redakcyjnymi to cykl release, w którym warto uczestniczyć. Kształt edycji wieloautorskiej w WordPressie na resztę dekady jest definiowany w następnych ośmiu tygodniach.

Ogłoszenie na make.wordpress.org/core i szczegóły programu outreach są na Make WordPress Core. Pokrycie kontynuujemy na The Repository i na blogu WPPoland przez cały cykl 7.1.

Ostatnia aktualizacja: 2026-06-06.