WordPress wraca do trzech dużych wydań w 2026: start planów dla 7.0, AI Client, odświeżenie admina i PHP 7.4 na stole

W projekcie WordPress wraca temat regularniejszego rytmu wydań. Z notatek opublikowanych po kwartalnym spotkaniu „Core Committers Check-in” wynika, że intencją zespołu jest powrót do trzech dużych wydań (major releases) w 2026 roku – równolegle z rozpoczęciem wczesnych ustaleń dotyczących WordPressa 7.0.

Spotkanie core committerów i liderów projektu dotyczyło nie tylko kalendarza. Na agendzie pojawiły się też: wstępna lista możliwych funkcji dla 7.0 (w tym WordPress AI Client), kierunek dla redesignu panelu administracyjnego oraz argumenty za podniesieniem minimalnej wspieranej wersji PHP.

Kontekst: od „jednego major” z powodu spraw prawnych do planu na trzy wydania

To istotna zmiana narracji względem wcześniejszej zapowiedzi z 2025 roku. Wtedy Executive Director, Mary Hubbard, komunikowała, że w 2026 planowane jest tylko jedno duże wydanie, wskazując na „trwające kwestie prawne” – w praktyce odnoszące się do wątku pozwu WP Engine – oraz do decyzji Automattic o wstrzymaniu / ograniczeniu wkładu w rozwój WordPressa w kontekście tego sporu.

Tym razem, zgodnie z notatkami ze spotkania, kierunek ma być bardziej ofensywny: planowane jest przywrócenie rytmu trzech wydań major w skali roku. Warto mieć z tyłu głowy, że to na razie opisane jako „intention” (intencja), a nie zamknięty, opublikowany harmonogram z twardymi datami.

Ustalanie rytmu na 2026 i wstępny cel dla WordPress 7.0

Notatki ze spotkania (opublikowane na Make WordPress Core przez Jonathana Desrosiersa) wskazują, że WordPress 7.0 jest celowany na marzec lub kwiecień.

Co ważne, wydanie w lutym zostało wykluczone. Powód jest dość przyziemny, ale realny w open source: Beta 1 wypadłaby wtedy na początek stycznia, kiedy wiele osób jest jeszcze na urlopach, a do tego część funkcji „w toku” i tak nie byłaby gotowa na tak agresywny termin.

Czy duże wydania będą „pod eventy”? Pomysł jest, planu jeszcze nie ma

Podczas rozmowy wrócił też temat dopasowywania premier do „flagowych” wydarzeń społeczności, na wzór tego, co działo się przy WordPress 6.9 (premiera spięta ze State of the Word).

Jednocześnie uczestnicy spotkania zwrócili uwagę, że takie podejście dokłada sporo złożoności: podróże, strefy czasowe, dostępność release squadu i kontrybutorów. W efekcie: to na razie możliwość do dalszej dyskusji, a nie przyjęty plan.

Co może trafić do WordPress 7.0: funkcje z 6.9 i mocny wątek AI

W notatkach przewijają się funkcje, które wcześniej były rozważane w kontekście WordPressa 6.9, a teraz są omawiane jako kandydaci dla 7.0. Wśród nich wymieniono:

template activation
blok Tabs (Tabs block)
możliwości po stronie klienta dla Abilities API (client-side abilities for the Abilities API)
client-side media editing (edycja mediów po stronie klienta)

Z tej listy najwięcej miejsca poświęcono jednak tematowi AI – a konkretnie WordPress AI Client.

WordPress AI Client: SDK „provider-agnostic” jako kandydat do core

WordPress AI Client to element szerszego planu AI Teamu – jeden z czterech „Building Blocks” z ich roadmapy – i jest już rozpatrywany jako potencjalny składnik WordPress core.

Istotny fakt z notatek: wersja 0.1.0 WordPress AI Client została wydana w poprzednim tygodniu (względem daty spotkania). To SDK ma dać pluginom i motywom natywny, provider-agnostic sposób integracji z usługami AI. „Provider-agnostic” oznacza tutaj, że biblioteka nie wymusza jednego dostawcy i nie zachęca do twardego wiązania implementacji z konkretnym API jednego vendora.

Projekt adaptuje PHP AI Client do konwencji WordPressa. W praktyce ma to kilka bardzo konkretnych konsekwencji architektonicznych:

Używa WordPress HTTP API do wykonywania zapytań sieciowych (czyli wpasowuje się w standardowe mechanizmy WordPressa zamiast wprowadzać „własny” transport).
Centralizuje klucze API w dedykowanym ekranie „AI Credentials” (zamiast mnożyć ustawienia w każdym pluginie z osobna).
Obsługuje dobór modelu bez zmuszania wtyczek do hard-code’owania konkretnych providerów (czyli plugin nie musi na sztywno zakładać np. „tylko X” lub „tylko Y”).

W notatkach padło też, co ma pojawić się dalej (czyli funkcje zapowiedziane dla kolejnych wersji klienta):

Wsparcie dla Abilities API (Abilities API support).
REST endpoints (endpointy REST) ułatwiające integrację i komunikację.
Client-side Prompt Builder (narzędzie do budowania promptów po stronie przeglądarki).

Dlaczego committers widzą AI Client w core?

Argumentacja w notatkach jest dość jednoznaczna: skoro AI Client ma zachęcać ekosystem do budowania na solidnych fundamentach (wprost pada tu przykład Abilities API), to „naturalnym domem” dla tego komponentu ma być WordPress core. W notatkach podkreślono też, że połączenie powiązanych API ma „odblokować wiele możliwości” zarówno dla developerów, jak i właścicieli stron.

Ograniczenia: WordPress ma pozostać agnostyczny wobec modeli i dostawców

Równolegle na spotkaniu mocno wybrzmiały ograniczenia i ryzyka. W notatkach zapisano, że WordPress „zawsze pozostanie agnostyczny”, a dodanie do core integracji z konkretnym modelem AI albo tylko z częścią usług firm trzecich nie jest podejściem, które da się utrzymać długoterminowo.

Pojawiła się też uwaga o możliwych, dalszych perspektywach: uczestnicy wspomnieli, że część nowych możliwości może wypłynąć z rozwoju modeli „machine-based” lub działających na poziomie przeglądarki (browser-level). Na tym etapie nie wybrano jednak konkretnego kierunku.

Zanim decyzja zapadnie: potrzebne jasne use case’y w „default WordPress”

Z notatek wynika też, że zanim dojdzie do decyzji o włączeniu AI Client do core, kontrybutorzy chcą zobaczyć klarowne przypadki użycia w ramach „domyślnego WordPressa”. Jako przykłady padają m.in.:

wyszukiwanie w bibliotece mediów pod kątem konkretnej tematyki / obiektów (np. po „subject matter”),
generowanie newsletterów na podstawie ostatnio opublikowanych treści.

Redesign panelu admina: raczej odświeżenie niż rewolucja

Drugim dużym wątkiem był redesign panelu administracyjnego. Według notatek przekaz był jasny: celem nie jest totalna przebudowa, tylko „fresh coat of paint” – czyli odmalowanie i odświeżenie tego, co już istnieje.

Ta deklaracja ma znaczenie w kontekście rozmów z lipcowego kwartalnego spotkania, gdzie rozważano testowanie redesignu jako eksperymentu w pluginie Gutenberg albo jako oddzielnego pluginu w stylu „MP7”. To nazwa-symbol, nawiązująca do MP6 z 2013 roku (model „feature as a plugin”), który w istotny sposób ukształtował redesign admina w WordPress 3.8.

Sam redesign admina jest osadzony w Phase 3: Collaboration z roadmapy Gutenberga. Prace w tym obszarze ruszyły już w 2023 roku – wtedy Matías Ventura (Gutenberg Lead Architect) opisał wizję unowocześnienia doświadczenia pracy w panelu administracyjnym, a później pokazywał nowe układy podczas State of the Word 2023.

Ciekawostka z osi czasu: wczesny podgląd redesignu admina był pierwotnie planowany „obok” WordPressa 6.9, ale we wrześniu został zdjęty z planu – po aktualizacji roadmapy oznaczono go jako „no longer planned based on the current state of work”.

Na dziś nadal nie ma terminu, kiedy odświeżony admin mógłby trafić do WordPressa. Ostatni duży refresh panelu miał miejsce ponad dekadę temu, przy WordPress 3.8.

Minimalne PHP 7.4: „mocne powody” są, decyzji jeszcze nie ma

Na spotkaniu wrócił również temat podniesienia minimalnej wspieranej wersji PHP do 7.4. Rozmowa dotyczyła „compelling reasons” – czyli przekonujących argumentów – ale bez finalnej decyzji.

Z notatek wynika, że dyskusja była bardzo pragmatyczna i dotykała ograniczeń, które większość osób rozwijających produkty na WordPressie zna z codziennej pracy:

Wsparcie dla starszych wersji PHP wymusza utrzymywanie kompatybilności, która dodaje „bloat” (rozrost kodu / dodatkowe obejścia) i spowalnia rozwój.
PHP 7.4 miałoby przesunąć codebase w stronę bardziej spójnego typowania, co ułatwia zrozumienie kodu zarówno developerom, jak i systemom AI analizującym kod.
Wiele zewnętrznych SDK dla AI już dziś wymaga nowszych wersji PHP, więc zbyt niskie minimum blokuje WordPressowi możliwość korzystania z nich.

Jednocześnie całość była przedstawiona jako balans między postępem a utrzymaniem szerokiej dostępności – tak, żeby nie „zostawić nikogo za burtą”. Na tym spotkaniu nie przesądzono, czy i kiedy podniesienie minimalnego PHP nastąpi.

Co dalej: lista tematów do domknięcia po spotkaniu

Jonathan Desrosiers wypunktował też konkretne rzeczy do dalszej pracy po tej sesji. W notatkach pojawiają się następujące follow-upy:

Zaproponowanie bardziej otwartych i „semi-open” formatów spotkań.
Publikacja harmonogramu wydań na 2026 rok.
Potwierdzenie funkcji celowanych do WordPress 7.0 oraz potencjalnie 7.1.
Ocena, czy koordynowanie wydań z wydarzeniami stacjonarnymi jest praktyczne (w kontekście złożoności logistycznej).

Podsumowanie: 2026 zapowiada się jak rok „budowania fundamentów”

Najważniejszy sygnał z kwartalnego check-inu jest prosty: projekt chce wrócić do trzech wydań major w 2026 roku, a WordPress 7.0 jest wstępnie celowany na marzec/kwiecień. Równolegle widać ciężar dyskusji przesuwający się na fundamenty: standaryzację integracji AI (WordPress AI Client i Abilities API), rozsądne podejście do odświeżenia admina oraz temat minimalnego PHP 7.4 jako warunku dalszego tempa rozwoju.