Wokół nadchodzącego wydania WordPressa 7.0 łatwo wpaść w uproszczenie, że „WordPress dodaje AI”. Tylko że to nie do końca tak działa. W oficjalnych materiałach nie widać jednego wielkiego modułu „AI”, który nagle wszystko załatwia. Zamiast tego Core buduje kilka osobnych warstw: jedne odpowiadają za połączenie z usługami, inne za rozmowę z modelami, a jeszcze inne za opisywanie i wykonywanie działań wewnątrz samego WordPressa. To ważne, bo pokazuje kierunek architektoniczny: WordPress nie tyle dodaje jedną funkcję, ile przygotowuje fundament pod cały ekosystem integracji.
WordPress 7.0 nie dodaje jednego „AI feature”, tylko cały stos warstw
Najkrócej można to opisać tak: WordPress 7.0 rozwija AI jako zestaw building blocks. W praktyce chodzi przede wszystkim o trzy elementy: Connectors API, AI Client i rozwijane dalej Abilities, w tym także ich wariant po stronie klienta. Oficjalne dev notes mówią o tym wprost: AI Client trafia do WordPressa 7.0 jako wbudowane, niezależne od dostawcy PHP API do pracy z modelami; Connectors API ma zająć się rejestrowaniem i zarządzaniem połączeniami z usługami zewnętrznymi; a Abilities API, wprowadzone już w WordPressie 6.9, opisuje możliwości WordPressa w ustandaryzowanym, maszynowo czytelnym formacie.
To podejście sporo mówi o ambicji projektu. Gdyby celem było tylko „dodanie generatora treści”, WordPress mógłby wypuścić pojedynczy panel czy przycisk w edytorze. Tymczasem oficjalne materiały pokazują coś innego: Core chce oddzielić konfigurację usług, komunikację z modelami i wykonywanie działań w WordPressie. To bardziej architektura platformy niż pojedyncza funkcja.
Najprostsza analogia: redaktor, telefon i lista możliwości
Da się to wyjaśnić bez technicznego żargonu.
Wyobraźmy sobie redaktora pracującego w CMS-ie.
-
Connectors to jego książka kontaktów i konfiguracja połączeń.
-
AI Client to telefon do eksperta AI.
-
Abilities to lista rzeczy, które redaktor może zrobić w systemie.
-
Client-Side Abilities to te same możliwości, ale dostępne bliżej interfejsu, już w samej przeglądarce.
Ta analogia dobrze oddaje role poszczególnych warstw, bo dokładnie tak rozdziela je WordPress w swoich dokumentach: Connectors służą do zarządzania usługami zewnętrznymi, AI Client do spójnej komunikacji z modelami, a Abilities do rejestrowania i wykonywania możliwości systemu.
Connectors: czyli jak WordPress chce uporządkować połączenia z usługami
Jednym z mniej spektakularnych, ale bardzo ważnych elementów WordPressa 7.0 jest Connectors API. Oficjalny dev note opisuje je jako nowy framework do rejestrowania i zarządzania połączeniami z zewnętrznymi usługami. Na początku nacisk jest położony głównie na providerów AI, a celem jest ustandaryzowanie takich rzeczy jak zarządzanie kluczami API, wykrywanie dostępnych providerów i interfejs administracyjny do konfiguracji usług.
To może brzmieć mało efektownie, ale właśnie tu często zaczyna się bałagan. W ekosystemie pluginów AI każdy może dziś robić konfigurację po swojemu: osobne ekrany ustawień, osobne pola na klucze, osobne mechanizmy łączenia z usługą. Connectors API próbuje to scalić. Oficjalny opis wskazuje też, że jeśli provider AI zarejestruje się w AI Client, odpowiedni connector może być utworzony automatycznie. To sugeruje, że WordPress buduje nie tylko pojedyncze API, ale powiązany system warstw, które mają się uzupełniać.
AI Client: jedna warstwa rozmowy z modelami
Najgłośniejszym z tych elementów jest pewnie AI Client. Według oficjalnego dev note WordPress 7.0 ma zawierać wbudowany AI Client, czyli provider-agnostic PHP API, które pozwala pluginom wysyłać prompty do modeli AI i odbierać wyniki przez spójny interfejs. Innymi słowy: zamiast pisać osobną integrację z OpenAI, osobną z Anthropic i osobną z kolejnym providerem, plugin może korzystać z jednej warstwy dostępowej wewnątrz WordPressa.
To ważne, ale równie ważne jest to, czym AI Client nie jest. Nie jest gotowym „pisarzem AI w Core”. Nie jest też automatycznie gotowym agentem, który sam wykonuje zadania w WordPressie. To raczej wspólny sposób zadawania pytań modelom i odbierania odpowiedzi. WordPress wcześniej opisywał ten kierunek także w proposalu merge do 7.0, podkreślając potrzebę spójnej warstwy dla pracy z providerami AI i integracji z resztą powstających building blocks.
Najprościej: AI Client odpowiada na pytanie „jak WordPress rozmawia z AI?”. Nie odpowiada natomiast sam z siebie na pytanie, co WordPress ma potem zrobić z wynikiem tej rozmowy.
Abilities: czyli co WordPress potrafi zrobić
I tu wchodzą Abilities. W WordPressie 6.9 pojawiło się Abilities API, opisane oficjalnie jako nowy fundament pozwalający Core, pluginom i motywom rejestrować swoją funkcjonalność w ujednoliconym, standaryzowanym i maszynowo czytelnym formacie. Dev note mówi wprost, że ability może zawierać takie elementy jak wejścia, wyjścia, uprawnienia i logika wykonania. W praktyce oznacza to, że funkcje WordPressa przestają być tylko zbiorem rozproszonych callbacków, endpointów i ukrytej logiki, a zaczynają być opisywane jako konkretne możliwości systemu.
To jest różnica subtelna, ale duża. Zwykły endpoint REST mówi: „pod ten adres możesz wysłać request”. Ability mówi raczej: „to jest konkretna rzecz, którą WordPress umie zrobić, z takim wejściem, takim wyjściem i takimi zasadami dostępu”. Oficjalne materiały dodają, że abilities mogą być automatycznie wystawiane przez REST API, ale sama idea Abilities jest wyższą warstwą niż sam transport. Dlatego warto myśleć o nich nie jako o konkurencji dla REST, tylko jako o bardziej semantycznym opisie działań systemu.
Najprościej: Abilities odpowiadają na pytanie „co WordPress potrafi zrobić?”.
Client-Side Abilities: ten sam pomysł, ale bliżej interfejsu
W WordPressie 7.0 ten model jest rozwijany dalej przez Client-Side Abilities API. Oficjalny dev note opisuje je jako klientowy odpowiednik Abilities dla JavaScriptu i działania w przeglądarce. To ważne, bo wiele nowoczesnych interakcji w WordPressie dzieje się już nie wyłącznie po stronie PHP, ale właśnie w interfejsie administracyjnym, w blokach i w logice klienta. WordPress zaznacza też, że to API ma służyć m.in. pluginom, narzędziom automatyzacji workflow i agentom AI działającym w środowisku przeglądarkowym.
To rozwinięcie dobrze pokazuje kierunek całej architektury. Gdyby chodziło tylko o backendowe wywołania do modeli, wystarczyłby sam AI Client. Ale ponieważ WordPress myśli także o działaniach wykonywanych w interfejsie, potrzebuje warstwy możliwości dostępnej również po stronie klienta. To kolejny znak, że projekt nie dokleja AI do starej architektury, tylko próbuje przebudować kilka warstw wokół nowych scenariuszy użycia.
Jak te warstwy działają razem
Dopiero zestawienie tych elementów pokazuje pełny obraz.
Wyobraźmy sobie prosty scenariusz: użytkownik chce wygenerować szkic wpisu, poprawić go i od razu wstawić do edytora.
Najpierw Connectors pomagają skonfigurować usługę i połączenie z providerem AI. Potem AI Client wysyła prompt do modelu i odbiera wynik. Następnie Abilities mogą opisać i uruchomić działania takie jak utworzenie wpisu, wstawienie bloków czy zapisanie treści. A jeśli część logiki ma działać już w interfejsie, rolę mogą przejąć Client-Side Abilities. Każda z tych warstw robi coś innego, ale razem tworzą spójniejszy pipeline niż zbiór przypadkowych, niezależnych integracji.
To właśnie tu widać, że WordPress nie dodaje „jednej sztuczki AI”. On rozdziela odpowiedzialności:
-
jedna warstwa łączy z usługą,
-
druga rozmawia z modelem,
-
trzecia opisuje możliwości systemu,
-
czwarta przenosi część tego modelu do klienta.
Taki podział może wydawać się przesadą, ale z punktu widzenia platformy ma sens: każda warstwa może ewoluować osobno i być używana przez różne pluginy, motywy czy narzędzia.
Czy to oznacza, że WordPress staje się „platformą AI”?
Tu warto zachować proporcje. Oficjalne materiały pokazują wyraźnie, że WordPress buduje infrastrukturę pod AI i automatyzacje, ale to jeszcze nie znaczy, że 7.0 zamienia się w gotowe środowisko agentowe z pudełka. Na dziś bardziej trafne wydaje się stwierdzenie, że WordPress przygotowuje warstwy, które mają ułatwić tworzenie takich rozwiązań w sposób natywny i bardziej spójny w całym ekosystemie.
To rozróżnienie jest ważne także dlatego, że WordPress 7.0 nadal jest przede wszystkim wydaniem platformowym: obok AI pojawiają się w nim także inne duże wątki, a sam cykl release’u był komunikowany publicznie jako wersja z planowaną premierą 9 kwietnia 2026 i zestawem większych zmian infrastrukturalnych. AI jest tu istotnym nurtem, ale nie jedynym.
Co z tego wynika dla twórców stron i pluginów
Dla zwykłego właściciela strony te warstwy będą przez długi czas mało widoczne. Nie zobaczy on raczej „AI Clienta” jako funkcji, którą można kliknąć. Zobaczy za to skutki uboczne tej architektury: bardziej spójne integracje, mniej dublowania konfiguracji w różnych pluginach i większą szansę, że kolejne rozszerzenia AI będą działały według podobnych zasad.
Dla deweloperów znaczenie jest większe. WordPress mówi wprost o warstwach, które mają uprościć natywne integrowanie narzędzi AI z platformą. Abilities mają dać przewidywalny opis działań systemu, AI Client ma ograniczyć konieczność pisania osobnych integracji z providerami, a Connectors mają ujednolicić konfigurację usług. To nie jest jeszcze obietnica, że wszystko nagle stanie się proste, ale jest to dość wyraźny sygnał, że Core chce ograniczyć chaos, który dziś łatwo pojawia się przy budowaniu AI wokół WordPressa.
Najkrótszy wniosek
Najważniejsze w WordPressie 7.0 nie jest to, że „dochodzi AI”. Ważniejsze jest to, jak WordPress próbuje je ułożyć. Nie przez jedną wielką funkcję, ale przez kilka warstw: jedne odpowiadają za połączenia, inne za komunikację z modelami, a jeszcze inne za same możliwości systemu. To podejście jest mniej efektowne niż wielki przycisk „Generate with AI”, ale dużo ciekawsze z punktu widzenia przyszłości platformy.
I właśnie dlatego warto patrzeć na WordPress 7.0 nie jak na wersję z jedną funkcją AI, tylko jak na wydanie, które zaczyna budować architekturę pod AI.
