WordPress 7.1 i współpraca w czasie rzeczywistym: druga próba, testy w stylu FSE i ośmiotygodniowy termin

Współpraca w czasie rzeczywistym dostaje drugą szansę w rdzeniu WordPressa. 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 wraca do planu WordPress 7.1, z programem testów w stylu FSE i datą wydania 19 sierpnia.

Dla agencji prowadzących redakcyjne przepływy pracy na WordPressie ma to konkretne znaczenie. Edycja wieloautorska to największa zmiana w pracy redakcyjnej wprowadzona do rdzenia od ponad dekady. Zmienia miejsca, w których pojawiają się konflikty na długich tekstach, redefiniuje, co oznacza blokada wpisu, i przesuwa to, czym jest edytor blokowy. Próba 7.1 pokazuje również, jak zmienia się udział społeczności w rozwoju WordPressa: program testów dla funkcji, która w dużej mierze jest pytaniem o architekturę bazy danych, to nowy format dla projektu.

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

#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 dlaczego ma znaczenie

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

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.
• Teraz (początek czerwca): rekrutacja. Firmy hostingowe rekrutują testerów, zespół kontrybutorów doprecyzowuje materiały testowe.

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 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 zostaje zastąpiony. Znane okno “ten wpis jest aktualnie edytowany przez…” dostarczane od WordPressa 3.6 jest zastępowane wskaźnikami obecności. Użytkownicy przyzwyczajeni do starego zachowania przez dekadę będą musieli nauczyć się nowego wzorca. Komunikacja wewnętrzna i materiały szkoleniowe wymagają aktualizacji.

To nie są przypadki brzegowe. To wpływ widoczny dla użytkownika od pierwszego dnia po wydaniu 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 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 jest projektowany tak, by sprawdzić wszystkie trzy warianty wobec realistycznych konfiguracji hostingowych. To, który wariant przetrwa, jest decyzją architektoniczną, 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 zestaw wtyczek. 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. 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 testów. Jeśli masz klienta z dwoma lub więcej redaktorami pracującymi na tej samej powierzchni treści, zespół testowy chce ten proces. Zgłoszenie umieszcza twojego klienta w grupie testowej i umieszcza ciebie w rozmowie architektonicznej. Zgłoszenie idzie przez wpis na make.wordpress.org/core z ogłoszenia McCarthy.
3. Przygotuj wewnętrzne szkolenie do zmiany blokady wpisu. Nawet jeśli twoi klienci nie korzystają aktywnie ze współpracy w czasie rzeczywistym, widoczna zmiana zachowania “wpis jest zablokowany” może wygenerować zgłoszenia do wsparcia 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 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 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.

#Wniosek

Współpraca w czasie rzeczywistym nie jest jeszcze dostarczoną funkcją. Decyzja architektoniczna bazy danych nie została jeszcze podjęta. Program testów nadal rekrutuje. Nic z tego nie jest przesądzone.

Co jest zdecydowane: funkcja wróciła do planu, data wydania 19 sierpnia to robocza kotwica, strategia testów została poszerzona poza środowiska korporacyjne i środowiska kontrybutorów, a firmy hostingowe są proszone o pomoc w rekrutacji testerów produkcyjnych. Jeśli decyzja architektoniczna zapadnie do końca czerwca i dane z testów ją potwierdzą, WordPress 7.1 dostarczy funkcję na WordCamp US.

Dla agencji z klientami redakcyjnymi to cykl wydawniczy, 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 testów są na Make WordPress Core. Temat będziemy śledzić na The Repository i na blogu WPPoland przez cały cykl 7.1.

Ostatnia aktualizacja: 2026-06-06.