Wokół WordPress 7.0 – którego premiera zaplanowana jest na 9 kwietnia 2026 roku – najwięcej mówi się o sztucznej inteligencji. WP AI Client, Abilities API, panel Connectors do zarządzania kluczami API – to właśnie te funkcje trafiają na okładki branżowych portali. Ale jest w tej wersji coś, co w dłuższej perspektywie może zmienić codzienną pracę z WordPressem znacznie bardziej niż jakiekolwiek AI: kolaboracja w czasie rzeczywistym, czyli real-time collaboration (RTC).
Po co w ogóle współedytowanie w WordPressie?
Przez ponad dwadzieścia lat WordPress pozostawał narzędziem zasadniczo jednoosobowym. Gdy dwie osoby otwierały ten sam wpis, system po prostu blokował edycję dla drugiej z nich – mechanizm tzw. post lock. W praktyce oznaczało to, że zespoły redakcyjne musiały sięgać po zewnętrzne narzędzia: pisanie odbywało się w Google Docs, komentarze lądowały na Slacku, zadania trafiały do Trello, a gotowy tekst dopiero na końcu był wklejany do WordPressa. Taki obieg działał, ale generował tarcie – kolejne przeklejenia, utracone formatowanie, brak kontekstu w dyskusjach oderwanych od treści.
WordPress 7.0 to oficjalne wejście w Fazę 3 projektu Gutenberg, której hasłem przewodnim jest właśnie „Collaboration”. Celem nie jest konkurowanie z Google Docs w zakresie edycji tekstu, lecz przeniesienie jak największej części procesu redakcyjnego bezpośrednio do panelu WordPressa – tak, żeby zespół mógł pracować nad treścią wspólnie, bez konieczności wychodzenia z jednego narzędzia.
Jak działa RTC od strony technicznej?
Kolaboracja w czasie rzeczywistym w WordPress 7.0 opiera się na frameworku Yjs – otwartej bibliotece implementującej algorytm CRDT (Conflict-free Replicated Data Type). W dużym uproszczeniu CRDT to sposób na scalanie zmian wprowadzanych jednocześnie przez wielu użytkowników bez ryzyka konfliktu. Gdy dwie osoby edytują ten sam blok, algorytm jest w stanie deterministycznie połączyć ich zmiany – nie ma sytuacji, w której praca jednej osoby nadpisuje pracę drugiej.
Twórcą Yjs jest Kevin Jahns, który był przez pewien czas sponsorowany przez Automattic właśnie po to, żeby opracować podejście do współedytowania w WordPressie. Ten sam typ algorytmu (CRDT) jest wykorzystywany w wielu popularnych narzędziach do pracy zespołowej, choć oczywiście szczegóły implementacji różnią się między platformami.
HTTP polling zamiast WebSocketów
Tu dochodzimy do jednej z kluczowych decyzji architektonicznych, która wzbudza sporo dyskusji. Domyślnym mechanizmem synchronizacji w WordPress 7.0 jest HTTP polling – klienty cyklicznie odpytują serwer o nowe aktualizacje przez endpoint REST API (/wp/v2/sync/updates). To podejście jest znacznie wolniejsze niż WebSockety, ale ma jedną zasadniczą zaletę: działa na każdym hostingu, łącznie z najtańszymi pakietami współdzielonymi opartymi o standardowe PHP.
Wcześniejsze próby bazowały na WebRTC (połączenia peer-to-peer między przeglądarkami), ale okazały się zbyt zawodne w różnych środowiskach hostingowych. HTTP polling to kompromis – mniej spektakularny, za to uniwersalny. W praktyce oznacza to opóźnienie rzędu 1-3 sekund między wprowadzeniem zmiany przez jednego użytkownika a jej pojawieniem się u drugiego. Nie jest to natychmiastowe, ale do pracy redakcyjnej – przeglądu artykułu, nanoszenia poprawek, dyskusji nad fragmentami tekstu – w zupełności wystarcza.
Co ważne, architektura jest zaprojektowana tak, żeby warstwa transportowa mogła być wymieniona. Hostingi, które wspierają WebSockety, mogą dostarczyć własnego providera synchronizacji za pomocą filtra sync.providers, co da znacznie niższe opóźnienia. To trochę jak z resztą WordPressa – rdzeń działa wszędzie, ale lepszy hosting daje lepsze rezultaty.
Limity i wydajność – o czym warto wiedzieć
W obecnej wersji beta WordPress 7.0 domyślnie ogranicza liczbę jednoczesnych współpracowników do dwóch osób na jeden wpis. Limit ten można zmienić za pomocą stałej w wp-config.php, ale warto mieć świadomość konsekwencji.
Temat wydajności budzi uzasadnione obawy. Peter Wilson, jeden z core developerów, zwrócił uwagę, że mechanizm pollingu generuje znaczny ruch sieciowy – przy jednym edytorze to zapytanie co sekundę, przy dwóch współpracownikach interwał skraca się do 500 ms. Przy dwóch edytorach oznacza to mniej więcej 480 zapytań na minutę. Na tanich hostingach współdzielonych to spora obciążenie. Kolejnym problemem jest wpływ na cache – WordPress domyślnie unieważnia cache zapytań o posty przy każdej aktualizacji post_meta, a dane synchronizacji są przechowywane właśnie w metadanych. Przy aktywnej kolaboracji oznacza to ciągłe unieważnianie cache’u, co może negatywnie wpływać na wydajność całej witryny.
W nowszych betach wprowadzono throttling pollingu, gdy zakładka przeglądarki jest nieaktywna – to pomaga, ale nie rozwiązuje problemu architektonicznie. Częstotliwość pollingu ma być też konfigurowalna za pomocą filtrów, co daje hostingom i administratorom większą kontrolę. Warto dodać, że na moment pisania tego tekstu (marzec 2026) decyzja o tym, czy RTC będzie domyślnie włączone w wersji finalnej, miała zostać podjęta w okolicach RC2.
Notes – komentarze redakcyjne wprost w edytorze
Równolegle z RTC w WordPressie rozwija się system Notes – komentarzy redakcyjnych widocznych wyłącznie wewnątrz edytora, niewidocznych dla odwiedzających stronę. Funkcja ta pojawiła się po raz pierwszy w WordPress 6.9, ale w dość podstawowej formie – można było dodawać notatki wyłącznie na poziomie całego bloku.
WordPress 7.0 rozwija ten mechanizm o kilka istotnych usprawnień. Przede wszystkim planowane jest wsparcie dla komentarzy na poziomie fragmentów tekstu (tzw. fragment-level notes) – zamiast komentować cały akapit, redaktor będzie mógł zaznaczyć konkretne zdanie lub słowo i zostawić uwagę dokładnie w tym miejscu. To zbliża Notes do tego, jak działają komentarze w Google Docs.
Poprawione zostały też powiadomienia – autor wpisu otrzymuje teraz email, gdy ktoś doda notatkę do jego tekstu, co ułatwia asynchroniczną pracę, gdy współpracownicy nie są zalogowani jednocześnie. Naprawiono również błędy, przez które notatki niepoprawnie inkrementowały licznik komentarzy do wpisu lub pojawiały się na ekranie zarządzania komentarzami w panelu administracyjnym.
Notes to w gruncie rzeczy oddzielna, ale komplementarna warstwa kolaboracji. RTC jest synchroniczne – wspólna praca w tym samym momencie. Notes jest asynchroniczne – „zostaw komentarz, wrócę do niego za godzinę”. Razem tworzą zestaw narzędzi, który po raz pierwszy w historii WordPressa daje zespołom redakcyjnym kompletny obieg pracy bez wychodzenia z CMS-a.
Rewizje w nowej odsłonie
Kolejna zmiana powiązana z kolaboracją dotyczy sposobu wyświetlania rewizji. Zamiast klasycznego ekranu porównania, w którym dwie wersje treści pokazywane są obok siebie, WordPress 7.0 wprowadza rewizje wyświetlane bezpośrednio w edytorze, z podświetleniem zmian na poziomie poszczególnych bloków (styl diff z kolorowym oznaczeniem dodanego i usuniętego tekstu). To może wydawać się drobnostką, ale w kontekście pracy zespołowej znacznie ułatwia przeglądanie historii zmian – widać dokładnie, co się zmieniło i gdzie.
Co z page builderami i wtyczkami?
RTC w WordPress 7.0 działa na poziomie bloków Gutenberga. To oznacza, że page buildery, które korzystają z własnych edytorów wizualnych – jak Elementor, Divi czy Beaver Builder – nie będą automatycznie obsługiwać współedytowania. Ich twórcy musieliby dostosować swój kod do mechanizmu synchronizacji opartego na Yjs, a to nie jest trywialne zadanie. Na chwilę obecną żaden z tych builderów nie ogłosił pełnego wsparcia dla RTC.
Jest jeszcze jedna istotna kwestia: wtyczki korzystające z klasycznych meta boxów powodują automatyczne wyłączenie kolaboracji. To decyzja celowa – klasyczne meta boxy działają poza systemem bloków i nie mogą być synchronizowane przez CRDT, więc ich obecność mogłaby prowadzić do niespójności danych.
Deweloperzy wtyczek i bloków niestandardowych powinni zwrócić uwagę na kilka rzeczy. Po pierwsze, wszelkie dane przechowywane w post_meta muszą być odczytywane z magazynu danych WordPressa przez useSelect, a nie z lokalnego stanu komponentu. Po drugie, pola formularzy powinny używać value zamiast defaultValue, aby zawsze odzwierciedlać bieżący stan współdzielony. To drobne, ale istotne zmiany – bez nich wtyczka może zachowywać się nieprzewidywalnie, gdy dwóch użytkowników edytuje jednocześnie.
Jak przetestować RTC przed premierą?
Kolaboracja w czasie rzeczywistym jest aktywnie testowana od momentu wydania WordPress 7.0 Beta 1. W fazie beta funkcja jest domyślnie opcjonalna – żeby ją włączyć, należy przejść do Ustawienia > Pisanie i zaznaczyć opcję „Enable real-time collaboration”. Następnie wystarczy otworzyć dowolny wpis do edycji i poprosić drugą osobę (lub siebie w drugiej zakładce, zalogowanego jako inny użytkownik), żeby otworzyła ten sam wpis.
Testować można na kilka sposobów: przez zainstalowanie wtyczki WordPress Beta Tester i wybranie kanału „Bleeding edge”, przez pobranie pliku ZIP z wersją beta, przez komendę WP-CLI (wp core update --version=7.0-beta1) albo – co chyba najwygodniejsze – przez WordPress Playground, czyli środowisko testowe działające bezpośrednio w przeglądarce, bez konieczności konfigurowania czegokolwiek na serwerze.
Zespół WordPressa aktywnie zachęca do zgłaszania błędów i uwag w kanale #feature-realtime-collaboration na WordPressowym Slacku oraz na GitHubie.
Co to oznacza dla właścicieli stron?
Jeśli prowadzisz bloga samodzielnie, RTC raczej nie zmieni Twojej codziennej pracy. Ale jeśli zarządzasz serwisem, przy którym pracuje kilka osób – redaktorzy, autorzy, korektorzy – to WordPress 7.0 oferuje realne uproszczenie procesu. Zamiast „napisz w Docsach, wrzuć link na Slacka, wklej do WordPressa, a potem napisz na mailu, że jest gotowe do publikacji”, pojawia się perspektywa „otwórz wpis w WordPressie, napisz, poproś o feedback w Notes, poprawcie razem w RTC, opublikuj”.
Nie będzie to od razu doświadczenie identyczne z Google Docs – limit dwóch współpracowników, opóźnienia przy HTTP pollingu, brak wsparcia dla page builderów – ale to pierwszy krok w kierunku, na który społeczność WordPressa czekała od lat. WordPress VIP już oferuje własną implementację opartą na WebSocketach dla klientów enterprise, a z czasem można się spodziewać, że ekosystem wtyczek i hostingów rozbuduje domyślne możliwości rdzenia.
Faza 3 Gutenberga dopiero się rozpoczyna. WordPress 7.1 zaplanowany jest wstępnie na sierpień 2026, a 7.2 na grudzień – oba mają kontynuować pracę nad kolaboracją. Obecna wersja to fundament, na którym będzie budowane wszystko, co przyjdzie później.
TL;DR: WordPress 7.0 (premiera 9 kwietnia 2026) wprowadza współedytowanie w czasie rzeczywistym oparte na frameworku Yjs/CRDT, z domyślnym transportem HTTP polling działającym na każdym hostingu. Limit to na razie 2 współpracowników na wpis, opóźnienie 1-3 sekundy. Uzupełnieniem jest rozbudowany system Notes do asynchronicznych komentarzy redakcyjnych. Nie działa z page builderami ani klasycznymi meta boxami. Funkcja dostępna do testów w wersji beta – warto sprawdzić przed aktualizacją produkcyjnej strony.
