Przyszłość WordPress: mapa drogowa 2026-2030 i co dalej

W 2015 rozmowa o WordPress kręciła się wokół REST API. We wrześniu 2026, przy 7.1.1 jako stabilnym wydaniu, chodzi o to, kto może edytować ten sam wpis naraz, co wolno wywołać agentowi AI i czy treść wyjdzie z zamkniętego buildera bez ręcznego kopiowania.

Dwie liczby ramują resztę. W3Techs zmierzył WordPress na 40,2% wszystkich witryn i 58,8% witryn ze znanym CMS 20 września 2026, w dół z 43,2% wszystkich witryn w grudniu 2025. Mapa drogowa odpowiada na ten spadek, nie świętuje go. Start EmDash CMS Cloudflare to widoczny fragment tej samej presji: w polskich briefach pojawia się już pytanie „a może coś nowocześniejszego niż WP?”, nie tylko w anglojęzycznym Twitterze.

Dalej: mapa drogowa sprawdzona względem rdzenia, wydanie po wydaniu. Gdzie funkcja jest realna, dostajesz nazwę funkcji. Gdzie to nadal dyskusja, jest to napisane.

#Czy WordPress ma współpracę w czasie rzeczywistym

Mapa drogowa na wordpress.org wymienia cztery fazy Gutenberga: Easier Editing, Customization, Collaboration, Multilingual. Faza 3 jest aktywna i częściowo dostarczona.

Notes weszły. Komentarze na poziomie bloku wylądowały w WordPress 6.9 2 grudnia 2025, po eksperymentalnym przebiegu we wtyczce Gutenberg. Przemianowane z „block comments” na Notes, żeby nie mylić ich z wp_comments dla czytelników. Pierwsze wydanie obejmuje dodawanie, wątkowanie, rozwiązywanie i usuwanie notatek na całym bloku, nie na zaznaczeniu wewnątrz. Podgląd lub tworzenie wymaga capability edit_post, bo notatki istnieją tylko w edytorze wpisu.

WordPress 7.1 rozszerzył je, zamiast zastępować: powiadomienia e-mail o wzmiankach w Notes, udostępniane linki do rewizji oraz poprawka, żeby Notes nie wyciekały już do zapytań feedów komentarzy. To ostatnie warto znać przed zgłoszeniem buga: własny feed komentarzy zbudowany na 6.9 mógł widzieć rekordy notatek, o które nikt nie prosił.

Współpraca w czasie rzeczywistym nie weszła. Dotarła do rdzenia jako beta i została wycofana. Wezwanie do testów z 11 marca 2026 prosiło o instalację WordPress 7.0 Beta 1 na serwerze dostępnym dla kogoś innego, włączenie „Enable real-time collaboration” w Ustawienia > Pisanie i otwarcie tego samego wpisu z dwóch kont. 8 maja 2026 usunięto ją z 7.0; powody to użyteczna część: powierzchnia funkcji, race conditions, obciążenie serwera, efektywność pamięci i bugi wychodzące w fuzz testingu. W 7.1 też nie jest włączona. Warstwa synchronizacji buduje na Yjs; core/freeform (Classic) jest oznaczony jako niezgodny. Widok wydanie-po-wydaniu: mapa drogowa WordPress 7.1.

Część, która dotyczy Twojego kodu. Bloki synchronizują się przez atrybuty, więc większość wspiera współpracę domyślnie; łamią się te, które trzymają stan edytora gdzie indziej. Zadeklaruj pole w block.json z typem, czytaj z attributes, zapisuj przez setAttributes przy zmianie, zamiast parkować wartość w React useState w edit() do blur. To już się opłaca w undo, rewizjach i autosave i decyduje, czy blok przeżyje, gdy collaboration wróci.

#Kiedy WordPress dostanie wielojęzyczność w rdzeniu

Mapa drogowa opisuje fazę 4 jednym zdaniem: implementacja w rdzeniu dla witryn wielojęzycznych. Nie ma schematu, API, dev note ani daty. Advanced Administration Handbook nadal dokumentuje wielojęzyczny WordPress jako coś rozwiązywanego wtyczką.

Kolejność jest ciekawa i stoi otwarcie w aktualizacjach fazy 3: infrastruktura współpracy musi być ustalona, zanim da się sensownie zaprojektować wielojęzyczność, bo obie potrzebują tej samej odpowiedzi na mapowanie jednego logicznego contentu na kilka zapisanych wersji. Odwrotna kolejność oznaczałaby rozwiązanie tego dwa razy. Faza 4 nie stoi więc na braku zainteresowania, tylko na tym, że faza 3 jest cykl wydawniczy za własną betą.

W polskich projektach z PL/EN (często WPML albo Polylang) sensowny ruch na czas oczekiwania:

• Trzymaj tożsamość tłumaczenia w post meta lub taksonomii, nie w logice szablonu.
• Nie przechowuj stringa locale w atrybutach bloku. Blok z hardcodowanym pl_PL staje się nieważną treścią w dniu, w którym warstwa tłumaczeń się przesunie.
• Traktuj WPML i Polylang jako zależności długoterminowe, nie prowizorkę. Przeżyją ten punkt mapy drogowej.

#Czy Data Liberation przeniesie stronę na WordPress

Strona projektu na wordpress.org/data-liberation ukazała się 6 grudnia 2023 i wprost nazywa pięć faz:

Fazy 4 i 5, czyli te, które ludzie mają na myśli przy „migracji jednym kliknięciem”, nie wystartowały.

To, co istnieje, jest węższe i bardziej użyteczne niż slogan. Plugin data liberation agent od Studio by WordPress.com dostarcza ekstraktory dla nazwanych platform: GoDaddy Websites and Marketing, Hostinger Website Builder, HubSpot, Shopify, Squarespace, Webflow, Weebly i Wix. To scrapery pod konkretne buildery, nie uniwersalny format. Równolegle zespół Playground buduje importery PHP jako streaming parsery, a krok blueprintu importWxr może iść przez importer Data Liberation zamiast legacy.

Dla agencji: przy ośmiu platformach z listy warto przetestować narzędzie przed wyceną ręcznej migracji treści. Przy wszystkim innym core nadal eksportuje WXR, a WXR nadal nie niesie plików mediów, ustawień wtyczek ani biblioteki wzorców bloków. W wycenie migracji sklepu z Shopify albo Wix do WordPressa budżetuj to wprost.

#Co obejmuje redesign panelu WordPress 7.1 i design tokens

Najpierw korekta, która krąży często. MP6 nie weszło w 2012. Było feature pluginem zaproponowanym w październiku 2013 i włączonym do WordPress 3.8, wydanego 12 grudnia 2013. Panel też nie stał w miejscu: 7.1 go zmienił.

To, co weszło w WordPress 7.1 19 sierpnia 2026, to fundament systemu designu, opisany w dev note core z 31 lipca 2026. Dwa zasoby są domyślnie zarejestrowane:

• Arkusz wp-theme z semantycznymi tokenami designu jako CSS custom properties, w stylu --wpds-color-background-surface-neutral-strong, --wpds-border-radius-lg, --wpds-dimension-padding-2xl.
• Handle skryptu wp-theme eksportujący komponent React ThemeProvider z @wordpress/theme.

ThemeProvider przyjmuje pięć propsów: color.primary i color.background jako kolory seed, cursor.control, cornerRadius z presetami none, subtle, moderate i pronounced, oraz isRoot dla themingu na korzeniu dokumentu.

Trzy kolejne zmiany panelu w 7.1, które zobaczysz w trackerze zanim zobaczysz je na blogu:

1. Prop __next40pxDefaultSize skończył podróż: od 7.1 to no-op, nadal akceptowany i ignorowany zamiast usunięty. Kontrolki formularzy renderują się na 40px niezależnie, więc ekrany admina dostrojone do starego defaultu się przesuwają.
2. wp_get_tooltip() i wp_get_toggletip() dają dostępne tooltipy jako funkcję rdzenia zamiast reinplementacji per wtyczka.
3. Nagłówek wiersza w tabeli wpisów przeniósł się z kolumny checkboxa do kolumny tytułu. To poprawka dostępności, która zmienia to, co screen reader ogłasza w wierszu.

Czym 7.1 nie jest: zamiennikiem wp-admin, panelem klienta ani white-label handover. Tokeny i provider to otwarcie, nie gotowy redesign. Planuj panel pod klienta zakładając, że tę warstwę nadal masz Ty.

#Czego uczyć się jako programista WordPress w 2026

Trzy rzeczy są wystarczająco konkretne, by uzasadnić czas nauki; jedna popularna teza nie.

Abilities API, od 6.9. Rejestr, przez który wtyczki, rdzeń i zewnętrzni agenci odkrywają, co witryna potrafi. Hook wp_abilities_api_init, wywołanie wp_register_ability() z namespaced nazwą w stylu my-plugin/my-ability, callback execute i permission plus typowane schematy wejścia i wyjścia. Abilities są prywatne domyślnie: show_in_rest to false, dopóki nie ustawisz. WordPress 7.0 dodał odpowiednik po stronie klienta. Rdzeń rejestruje trzy abilities tylko do odczytu w wp-includes/abilities.php: core/get-site-info, core/get-user-info, core/get-environment-info. Sprawdź nazwy w trunku przed kodowaniem, bo wcześniejsze drafty miały inne.

AI Client, włączony do 7.0. Infrastruktura niezależna od providera: PHP prompt builder, abstrakcja providera i modelu, wspólne przechowywanie credentiali, REST i JavaScript API. SDK siedzi w wp-includes/php-ai-client/; klej WordPress w wp-includes/ai-client/. Ekran Connectors: wp-admin/options-connectors.php. Skutek praktyczny: nie bundlujesz już klucza API i klienta HTTP w każdej wtyczce, która chce model. Czego w rdzeniu nie ma: generowania stron z opisu, optymalizacji treści ani przewidujących aktualizacji. To nadal teren wtyczek.

React, zwłaszcza warstwa danych edytora. JSX to łatwa połowa. Połowa, która decyduje, czy Twój blok przeżyje collaboration i nowy panel, to @wordpress/data, schematy atrybutów w block.json oraz teraz @wordpress/ui i @wordpress/theme dla powierzchni admina idących za tokenami rdzenia.

I teza do odrzucenia: nie ma „kanonicznego API”, które robi headless WordPress łatwym. Jest REST API, jest WPGraphQL jako wtyczka i jest Abilities API pod wywołania agentów. Trzy różne kontrakty, trzy historie utrzymania, a wybór nadal jest decyzją architektoniczną, którą musisz podjąć sam.

#Jak mapa drogowa WordPress wpływa na wtyczki

Mapa drogowa nie dotyczy tylko rdzenia, zmienia też to, jak wtyczki opierają się na platformie. Warto oddzielić to, co już wymaga działania, od tego, co nadal jest warunkowe.

#Czy wtyczki trzeba dostosować do współpracy w czasie rzeczywistym

Dopóki jednoczesna edycja nie wróci do rdzenia, nic nie zmusza Cię do przebudowy wtyczki. To, co możesz zrobić już dziś, bo opłaca się także bez współpracy, to sprawić, żeby edytory tabel, kreatory formularzy i narzędzia SEO trzymały stan w atrybutach bloku, a nie w lokalnym stanie Reacta. To ten sam wymóg, który postawiło wezwanie do testów 7.0 Beta 1, i to on sprawia, że cofanie zmian i rewizje działają poprawnie.

#Czy wtyczki trzeba dostosować do wielojęzyczności w rdzeniu

Tu nie ma czego przygotowywać pod API, bo API nie ma. Jedyny konkretny krok to nie wiązać sobie rąk: trzymaj tożsamość tłumaczenia w meta albo taksonomii i nie wkładaj stringów językowych do atrybutów bloku. Każda lista ustandaryzowanych API tłumaczeń w rdzeniu jest na dziś zmyślona.

#Co stało się ze współpracą w czasie rzeczywistym po WordPress 7.0

Usunięcie nie zakończyło prac, tylko wyjęło je z gałęzi wydania. 3 czerwca 2026 zespół rdzenia ogłosił program testów edycji współdzielonej dla 7.1: wcześni użytkownicy instalują najnowszą wersję wtyczki Gutenberg, włączają współpracę w Ustawienia > Pisanie i zgłaszają uwagi na kanale Slack #collaborative-editing-outreach przez cały cykl 7.1, co najmniej do 18 sierpnia 2026. Wpis zespołu Hosting z tego samego dnia poprosił firmy hostingowe o zaproszenie własnych klientów, żeby funkcja była testowana na wielu konfiguracjach serwerów, a nie na jednej. To pasuje do powodów wycofania: obciążenie serwera i efektywność pamięci zależą od hostingu.

Dwa repozytoria pokazują, dokąd poszły prace dalej. Gutenberg Sync Engines, utworzone 10 sierpnia 2026, opisuje się jako porównanie możliwych silników synchronizacji i transportów dla współpracy w czasie rzeczywistym w Gutenbergu. Wtyczka funkcyjna (feature plugin) Presence API, dostępna na wordpress.org od 21 lipca 2026 i wymagająca WordPress 7.0, śledzi, którzy użytkownicy są zalogowani, na którym ekranie panelu są i które wpisy edytują. Dane płyną przez Heartbeat API do osobnej tabeli wp_presence z TTL 150 sekund, a blokady wpisów trafiają tam zamiast do post meta, więc trzymanie blokady nie unieważnia już zapytań o wpisy z cache. Wersja 0.18.1 wyszła 13 października 2026.

Podsumowanie spotkania Presence API z 12 października 2026 ustawia poprzeczkę dla propozycji do rdzenia: trzy zewnętrzne projekty korzystające z API i osiem tygodni bez zmiany łamiącej zgodność, liczone od wersji 0.17.0, co daje 3 grudnia jako najwcześniejszą datę. Blokady wpisów są pierwszym konsumentem, a Gutenberg Sync Engines pierwszym zewnętrznym projektem. Żadna wersja WordPress nie jest wskazana jako cel. Jeśli Twoja wtyczka czyta albo zapisuje post meta _edit_lock, to są prace do obserwowania, bo blokady wpisów są dokładnie tym, co wtyczka przenosi.

#Kiedy wyjdzie WordPress 7.2

Wezwanie do wolontariuszy z 12 sierpnia 2026, opublikowane przez Jeffreya Paula, proponuje 9 grudnia 2026 jako datę wydania finalnego i nazywa ją elastyczną. Prace w fazie alfa ruszyły 10 sierpnia 2026. Proponowane kamienie milowe idą co tydzień:

Strona mapy drogowej, ostatnio zmieniona 20 sierpnia 2026, podaje dla 7.2 datę 10 grudnia 2026 i zaznacza, że prognozowane daty służą tylko do zgrubnego planowania. Mówi też, że nowe funkcje są zamrażane miesiąc przed wydaniem. Wezwanie wymienia role (release lead, koordynacja wydania, tech leads, triage lead, test lead), ale żadnych funkcji. W połowie października nie ma opublikowanego zakresu 7.2, więc wszystko, co przed Beta 1 przedstawia się jako nowość w 7.2, jest zgadywaniem. Do planowania w agencji przydają się daty release candidate: testuj strony klientów i własne bloki na RC1 w tygodniu od 17 listopada, a nie w dniu wydania.

#Jak przygotować wtyczki i bloki na WordPress 7.1

Bez zgadywania przyszłości, oto co da się zrobić z tym, co już opublikowano:

1. Deklaruj atrybuty bloku w block.json z typem i zapisuj je przez setAttributes. To warunek, który samo wezwanie do testów postawiło, żeby blok się synchronizował.
2. Rejestruj swoje możliwości przez Abilities API zamiast wymyślać własny endpoint REST, który ma wywołać agent, i zostaw show_in_rest na false, dopóki nie wiesz, kto z tej ability korzysta.
3. Używaj tokenów --wpds- we własnych ekranach panelu zamiast wpisywać na sztywno kolory i promienie, które rozjadą się w następnym wydaniu.
4. Sprawdź odstępy na swoich ekranach panelu względem kontrolek 40px, bo __next40pxDefaultSize niczego już nie zmienia.

WordPress nie zwalnia, ale też nie sprintuje: jedna funkcja współpracy dostarczona, jedna odroczona, redesign panelu na etapie tokenów, faza wielojęzyczna jeszcze nie zaczęta. Jeśli chcesz tę lekturę zastosowaną do konkretnego stacka, robimy właśnie takie audyty jako deweloperzy WordPress.