Współpraca w czasie rzeczywistym WordPress

Współpraca w czasie rzeczywistym dostała drugą szansę w rdzeniu WordPressa i znowu nie weszła. Dwa tygodnie przed wydaniem WordPress 7.0 zespół kontrybutorów wycofał to, co miało być główną funkcją wydania. Powodem podanym wtedy były problemy wydajnościowe bazy danych, których zespół nie mógł obiecać naprawić w oknie wydawniczym. Sześć tygodni później ta sama funkcja wróciła do planu WordPress 7.1, z programem testów w stylu FSE i 19 sierpnia jako kotwicą kalendarza.

WordPress 7.1 Mary Lou wyszedł 19 sierpnia 2026 bez edycji wieloosobowej na żywo. To dwa kolejne wydania główne. Reszta tego tekstu to cykl taki, jakim był, plus to, co agencje powinny zrobić teraz, gdy w paczce tej funkcji nie ma.

Dla agencji prowadzących redakcyjne przepływy pracy na WordPressie ten brak ma konkretne znaczenie. Edycja wieloautorska nadal byłaby największą zmianą w pracy redakcyjnej wprowadzoną do rdzenia od ponad dekady. Zmieniłaby miejsca, w których pojawiają się konflikty na długich tekstach, zdefiniowałaby na nowo, co oznacza blokada wpisu, i przesunęłaby to, czym jest edytor blokowy. Nic z tego nie weszło w 7.1. Nie szkol klientów na zamiennik blokady wpisu, którego nie ma.

#Co zostało wycofane z 7.0 i dlaczego

Współpraca w czasie rzeczywistym w edytorze blokowym potrzebuje trzech rzeczy, by działała na dużą skalę: kanału obecności i kursorów o niskim opóźnieniu, bezkonfliktowej strategii scalania zmian bloków oraz warstwy zapisu, która utrzyma scaloną historię bez łamania istniejącego modelu wp_posts i wp_postmeta.

Kanał obecności i kursorów został rozwiązany w cyklu 6.x, z użyciem długiego odpytywania i opcjonalnego transportu WebSocket dla stron gotowych uruchomić dodatkową infrastrukturę. Bezkonfliktowa strategia scalania trafiła do wtyczki Gutenberg pod koniec 2025 roku z podejściem opartym na CRDT. Trzeci element, warstwa zapisu, to miejsce, w którym 7.0 się złamało.

Implementacja 7.0 utrwalała stan współpracy w nowej tabeli powiązanej z rewizjami wpisu. Na mniejszych instalacjach to działało. W skali środowiska testowego Automattic z ponad 50000 współbieżnych edycji zapisy do nowej tabeli tworzyły opóźnienie replikacji i konflikt blokad na tyle poważne, że zespół uznał to za przeszkodę blokującą wydanie. Decyzja o wycofaniu została podjęta w połowie kwietnia, dwa tygodnie przed datą ogólnej dostępności 7.0.

Ogłoszenie Anne McCarthy o nowym programie testów 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 planowanej do konkretnego wydania.

#Problem jajka i kury

Współprowadząca zespół hostingowy Amy Kamala podsumowała sytuację jednym zdaniem: “Need testing to make decision, need decision to do testing.”

Wybory architektoniczne dla warstwy zapisu mają bardzo różne profile kosztów dla różnych środowisk hostingowych. Rozwiązanie działające dobrze na instalacji jednoserwerowej może nie przeżyć konfiguracji równoważonej obciążeniowo z replikami tylko do odczytu. Rozwiązanie pasujące do zarządzanego hostingu z jednym klientem na środowisko 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ół pełnej edycji witryny 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 testów FSE stworzył rekrutowaną grupę testerów uruchamiających realne strony z realnymi wtyczkami i ujawniał błędy, których zespół kontrybutorów nie złapałby w izolacji.

Zastosowanie tego samego wzorca do współpracy w czasie rzeczywistym to nowy ruch strukturalny. To też powód, dla którego firmy hostingowe są proszone o pomoc w rekrutacji testerów ze swojej bazy klientów zarządzanych.

#Kształt programu testów

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 korporacyjne i deterministyczne. Prowadzone z partnerami hostingowymi na środowiskach zarządzanych klientów z kontrolowanym obciążeniem. Zaprojektowane, by zwalidować, że architektura zapisu przeżyje scenariusze konfliktu w bazie danych.
3. Zaangażowani użytkownicy produkcyjni. Nowa warstwa. Rekrutowani z agencji, wydawców i zespołów treści uruchamiających produkcyjne strony WordPressa ze współpracą redakcyjną jako realnym wymogiem procesu.

Trzecia warstwa to miejsce, z którego przyjdzie większość nowej przepustowości testów. Program jawnie prosi o strony, na których współpraca w czasie rzeczywistym rozwiązuje realny problem, a nie o syntetyczne instalacje testowe.

O co prosi się testerów:

• Aktywne procesy redakcyjne z więcej niż jednym autorem pracującym jednocześnie na długich tekstach
• Gotowość do uruchomienia wersji kandydującej wobec środowisk testowych
• Cykl raportowania: cotygodniowa kontrola ze strukturalnym formularzem informacji zwrotnej
• Zgłoszenia błędów obejmują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 współpraca w czasie rzeczywistym 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 samo uznanie. To wczesny podgląd decyzji inżynierskich.

#Data 19 sierpnia i co faktycznie dostarczyła

WordPress 7.1 Mary Lou wyszedł 19 sierpnia na WordCamp US w Phoenix. Data się utrzymała. Współpraca w czasie rzeczywistym nie. Kalendarz testów poniżej to cykl zaplanowany w czerwcu, zostawiony tu dlatego, że pokazuje, jak mało miejsca na restart architektury kiedykolwiek było.

Pracując wstecz od 19 sierpnia:

• Koniec lipca: pierwsza wersja kandydująca. Zamrożenie funkcji. RTC musi być stabilne na tyle, by trafić do szerokiego grona testerów. Decyzja architektoniczna bazy danych musi być zamknięta.
• Połowa lipca: Beta 3. Ostatnia możliwość zmian zachowań. Dane z programu testów powinny informować decyzje, nie je inicjować.
• Początek lipca: Beta 2. Ostatnia możliwość nietrywialnych zmian architektonicznych. Dane testowe partnerów hostingowych powinny już być dostępne.
• Koniec czerwca: Beta 1. Pierwsza szeroko testowana kompilacja. Architektura zapisu powinna być już zatwierdzona.
• Połowa czerwca: rozruch programu testów. Rekrutowani testerzy uruchamiają kompilacje na środowiskach testowych. Pierwszy cykl informacji zwrotnej.
• Początek czerwca: rekrutacja. Taki był plan. Firmy hostingowe miały rekrutować testerów. Funkcja i tak nie weszła do paczki.

Osiem tygodni wystarczało na zamkniętą architekturę. Nie wystarczało na restart architektoniczny. Decyzja architektoniczna była nadal otwarta, gdy cykl startował. 7.1 wyszedł bez tej funkcji. 7.2 jest obecnie planowane na 9 grudnia 2026. Traktuj to jako datę planistyczną, nie jako RTC.

#Co współpraca w czasie rzeczywistym zmienia w procesach agencyjnych

Odłóżmy pytanie o bazę danych na chwilę. Jak WordPress ze współpracą w czasie rzeczywistym faktycznie wygląda dla agencji?

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

• Pętle redakcyjnej weryfikacji się skracają. Obecny proces redakcyjny WordPressa jest sekwencyjny. Autor pisze. Redaktor sprawdza tekst po skończeniu pracy autora. Autor odnosi się do komentarzy. Redaktor zatwierdza. Ze współpracą w czasie rzeczywistym autor i redaktor mogą pracować jednocześnie. Dla agencji prowadzących kalendarze redakcyjne dla klientów treściowych to redukcja cyklu na artykuł i zmiana sposobu rozliczania godzin.
• 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ów Rank Math, niestandardowe metaboxy taksonomii i długi ogon wtyczek budowanych agencyjnie, wszystkie wymagają sprawdzenia pod kątem bezpieczeństwa współbieżnego zapisu. Zespół przeglądu wtyczek jasno powiedział, że współpraca w czasie rzeczywistym ujawnia wtyczki z niebezpiecznymi wzorcami zapisu.
• Interfejs blokady wpisu zostałby zastąpiony. Znane okno “ten wpis jest aktualnie edytowany przez…” od WordPressa 3.6 ustąpiłoby wskaźnikom obecności. W 7.1 to się nie stało. Stare okno nadal jest tym, co widzi użytkownik.

To nie są przypadki brzegowe. To wpływ widoczny dla użytkownika od pierwszego dnia, jeśli funkcja w ogóle wejdzie. W 7.1 nie weszła, więc nic z tego nie jest zgłoszeniem do wsparcia z 19 sierpnia. Zostaw audyt wtyczek. Nie przepisuj materiałów szkoleniowych na interfejs, którego nie ma w rdzeniu.

#Pytanie o architekturę bazy danych, uproszczone

Główne wyzwanie inżynierskie jest proste. WordPress przechowuje treść wpisu w wp_posts.post_content jako pojedynczy blok danych. Rewizje tworzą nowe wiersze. Współpraca w czasie rzeczywistym musi scalić współbieżne edycje w ten blok danych bez utraty danych i bez niekontrolowanego wzrostu liczby rewizji.

Trzy warianty architektoniczne aktualnie pod dyskusją:

1. Dopisywany dziennik operacji. Nowa tabela przechowuje pojedyncze operacje, takie jak wstawienie, usunięcie i zmiana formatowania, ze znacznikami czasu i identyfikatorami autorów. post_content jest rekonstruowany z dziennika operacji przy zapisie. Plus: czyste rozwiązywanie konfliktów. Minus: duży wolumen zapisu do nowej tabeli.
2. Migawki plus różnice. Okresowe migawki post_content plus rekordy różnic między migawkami. Plus: ograniczony wolumen zapisu. Minus: logika czasu tworzenia migawek jest złożona, a odtwarzanie po pominiętych migawkach trudne.
3. Scalanie w pamięci z okresowym utrwalaniem. Stan współpracy trzymany w pamięci w warstwie aplikacyjnej, utrwalany do post_content i pojedynczego wiersza rewizji co interwał albo przy jawnym zapisie. Plus: niski wolumen zapisu do bazy. Minus: wymaga stałego przypisania sesji do serwera albo wspólnej warstwy pamięci podręcznej.

Każdy wariant ma implikacje dla hostingu. Wariant 1 obciąża bazę danych. Wariant 2 obciąża warstwę aplikacyjną logiką czasu. Wariant 3 obciąża infrastrukturę pamięci podręcznej i sesji.

Program testów 7.1 miał sprawdzić te warianty wobec realistycznych konfiguracji hostingowych. Decyzja architektoniczna miała zapaść do końca czerwca. Nie zapadła na czas. 7.1 wyszedł bez RTC.

#Co agencje powinny zrobić teraz

Trzy konkretne ruchy po tym, jak 7.1 nie dostarczył funkcji.

1. Nie obiecuj klientom edycji wieloosobowej na żywo w 7.1. Jej tam nie ma. Sekwencyjny proces redakcyjny nadal jest produktem.
2. Zaudytuj swój redakcyjny zestaw wtyczek mimo wszystko. Każda wtyczka podpinająca się pod save_post, wp_insert_post_data lub zapisy metadanych edytora blokowego jest kandydatem do współbieżnego zapisu, gdy RTC wróci. Lista jest użyteczna nawet jeśli funkcja jest cykl dalej.
3. Nie przepisuj szkoleń o blokadzie wpisu pod sierpień. Okno “ten wpis jest aktualnie edytowany przez…” nadal jest zachowaniem 7.1. Zostaw jednostronicowe wyjaśnienie, aż dokumentacja potwierdzi, że wskaźniki obecności weszły.

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

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

Przez większość swojej historii rozwój rdzenia WordPressa był napędzany decyzjami kontrybutorów testowanymi wobec środowisk kontrybutorów. Program testów FSE w cyklu 5.8 do 6.0 był pierwszą próbą formalnej integracji testowania w realnych warunkach z pętlą decyzji rdzenia. Program testów współpracy w czasie rzeczywistym na 7.1 to drugi taki krok.

Wzorzec jest taki, że projekt staje się bardziej zależny od danych ze środowisk produkcyjnych i mniej zdolny do samodzielnego dostarczania głównych funkcji wyłącznie na środowiskach kontrybutorów. 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 procesami redakcyjnymi coraz częściej należą do grupy, której informacje zwrotne kształtują rdzeń. To uzasadnione miejsce przy stole, którego nie było cykl lub dwa wcześniej.

Dla polskich i europejskich agencji czerwcowe rozmowy na korytarzach WCEU w Krakowie miały zwerbować partnerów do testów. Ten nabór nie dał wydania w 7.1. Kolejna data w kalendarzu to 7.2, obecnie planowane na 9 grudnia 2026 razem ze State of the Word. Przychodźcie na te rozmowy z danymi produkcyjnymi, nie ze slajdem sprzedażowym, że RTC jest w rdzeniu.

#CRDT kontra Operational Transformation (OT): Teoretyczne fundamenty RTC

Zrozumienie opóźnień w implementacji współpracy w czasie rzeczywistym wymaga spojrzenia na matematyczne modele synchronizacji danych:

• Conflict-free Replicated Data Types (CRDT): Biblioteki takie jak Yjs czy Automerge operują na bezkonfliktowych strukturach danych, w których każda operacja (wstawienie znaku, usunięcie bloku) posiada unikalny identyfikator logiczny. CRDT pozwala na pełną synchronizację P2P bez centralnego koordynatora, ale generuje znaczny narzut pamięciowy (metadata overhead) przy długich dokumentach.
• Operational Transformation (OT): Model znany z Google Docs wymaga centralnego serwera przekształcającego operacje przed ich rozesłaniem do klientów. Jest lżejszy dla bazy danych, ale wymaga ciągłego, niskopoziomowego połączenia z serwerem i centralnej kolejki zdarzeń.
• Wybór dla WordPressa: Próba wdrożenia CRDT w środowisku przeglądarkowym napotyka na barierę zapisu do monolitycznego pola post_content w bazie MySQL, co wymagało kompromisów architektonicznych, których nie zdołano domknąć przed zamrożeniem kodu 7.1.

#Wyzwania infrastrukturalne: WebSockety i limity serwerów PHP-FPM

Tradycyjna architektura hostingowa WordPressa nie jest przystosowana do utrzymywania stałych połączeń sieciowych:

• Brak natywnej obsługi WebSocket w standardowym LAMP: PHP-FPM działa w modelu synchronicznym „żądanie-odpowiedź”. Utrzymanie tysięcy otwartych połączeń WebSocket z edytorem Gutenberga wymaga zewnętrznych serwerów proxy (np. opartych na Node.js, Go lub Cloudflare Durable Objects).
• Zarządzanie stanem obecności (Presence/Awareness): Wyświetlanie kursorów i zaznaczeń innych redaktorów w czasie rzeczywistym generuje intensywny ruch sieciowy. Bez dedykowanej warstwy brzegowej (Edge Layer) serwery współdzielone uległyby natychmiastowemu przeciążeniu.

#Bezpieczeństwo i uprawnienia na poziomie pojedynczych bloków

Współpraca wieloosobowa rodzi nowe pytania o model uprawnień w CMS:

• Blokowanie kolizji (Block-level Locking): Zamiast blokować cały wpis, nowoczesny edytor musi dynamicznie blokować edycję konkretnego akapitu lub tabeli, gdy pracuje nad nią inny użytkownik.
• Ścieżka audytu (Audit Trail): W wydawnictwach korporacyjnych kluczowa jest precyzyjna informacja, który redaktor wprowadził daną poprawkę, co wymaga szczegółowego logowania operacji w bazie danych.

#Zmiana paradygmatu zapisu dla wtyczek i pól niestandardowych (ACF / Meta Boxes)

Wprowadzenie RTC to rewolucja nie tylko dla samego edytora, ale dla tysięcy wtyczek z ekosystemu:

• Problem wyścigu danych (Race Conditions): Gdy dwóch autorów edytuje jednocześnie wpis posiadający pola ACF lub metaboxy SEO, tradycyjny mechanizm zapisu nadpisuje całą tablicę meta. Konieczne jest wdrożenie atomowych operacji zapisu (Atomic Field Updates) na poziomie bazy danych.
• Dostosowanie wtyczek optymalizacyjnych: Narzędzia analizujące tekst w locie (jak Yoast SEO czy Rank Math) muszą przestać blokować wątek główny przeglądarki i przenieść obliczenia do Web Workerów.

#Praktyczne rekomendacje dla polskich agencji i redakcji

Do czasu oficjalnego debiutu RTC w kolejnych wydaniach WordPressa, zespoły redakcyjne powinny wdrożyć sprawdzone procedury organizacyjne:

• Wyraźny podział ról w procesie wydawniczym: Zachowanie sekwencyjnego obiegu dokumentów (autor -> korektor -> redaktor naczelny) eliminuje ryzyko przypadkowego nadpisania treści.
• Audyt własnych wtyczek: Weryfikacja kodu pod kątem hooków save_post pozwala na wcześniejsze wykrycie potencjalnych konfliktów współbieżności. Świadome zarządzanie procesami redakcyjnymi to gwarancja bezpieczeństwa danych i spokoju operacyjnego zespołu.

#Perspektywy dla WordPressa 7.2 i przyszłości publikowania treści

Przesunięcie wdrożenia edycji wieloosobowej na cykl wydawniczy wersji 7.2 to dowód dojrzałości inżynieryjnej społeczności open source:

• Bezpieczeństwo danych ponad pośpiech marketingowy: W środowiskach korporacyjnych utrata choćby jednego akapitu tekstu w wyniku błędu synchronizacji jest niedopuszczalna. Decyzja o dopracowaniu architektury bazy danych to wyraz odpowiedzialności za miliony działających serwisów.
• Wspólne standardy dla nowoczesnego internetu: Doświadczenia zebrane podczas testów wersji 7.1 pozwolą na stworzenie rozwiązania stabilnego, wydajnego i bezpiecznego dla całego ekosystemu. Cierpliwe budowanie solidnych fundamentów technologicznych to najlepsza gwarancja sukcesu WordPressa w kolejnych dekadach. Profesjonalizm i dyscyplina inżynierska zawsze przynoszą najlepsze owoce w biznesie cyfrowym. Rzetelne podejście do architektury oprogramowania to klucz do trwałego zaufania klientów i stabilnego rozwoju.

#Wniosek

Współpraca w czasie rzeczywistym nie jest dostarczoną funkcją. Nie weszła do 7.0 i nie weszła do 7.1. Decyzja o architekturze bazy danych nie została zamknięta na czas. Program testów nie przeciągnął funkcji przez linię.

Co jest zdecydowane: 7.1 Mary Lou wyszedł 19 sierpnia bez edycji wieloosobowej na żywo. Sekwencyjny proces redakcyjny nadal jest tym, na czym pracujesz. Śledź Make WordPress Core pod kątem tego, co 7.2 faktycznie wpisze. Nie traktuj grudniowego celu jako daty wydania.

Wątki na make.wordpress.org/core pozostają głównym źródłem. Relacja z tego, co 7.1 faktycznie dostarczył, jest w nocie o planie 7.1.

Ostatnia aktualizacja: 2026-06-06.