W dyskusji o WordPressie 7.0 łatwo zachwycić się nowymi nazwami: AI Client, Abilities, Connectors, Client-Side Abilities. Tylko że obok tego zachwytu pojawia się bardzo rozsądne pytanie: skoro już wcześniej dało się zbudować narzędzie, które generuje treści przy pomocy kilku modeli, tworzy grafikę i publikuje całość przez REST API, to po co WordPressowi kolejne warstwy? To pytanie jest tym bardziej zasadne, że sam WordPress nie twierdzi, iż wcześniej było to niemożliwe. Oficjalne materiały pokazują raczej coś innego: nowe API mają uporządkować to, co do tej pory każdy twórca pluginu i integracji składał po swojemu.
Tak, dało się to zrobić wcześniej
I to jest punkt, od którego warto zacząć uczciwie. Dało się już wcześniej zbudować workflow, w którym jeden model przygotowuje szkic, drugi go poprawia, trzeci rozwija w pełny tekst, a na końcu całość trafia do WordPressa przez REST API razem z obrazem i metadanymi. Dało się też dopisać własną logikę walidacji, retry, workflow etapów i publikacji. Z punktu widzenia efektu końcowego WordPress 7.0 nie odblokowuje więc nagle czegoś, co wcześniej było poza zasięgiem. Oficjalne dev notes o Abilities API wręcz podkreślają, że nowa warstwa nie zmienia dotychczasowego działania WordPressa i może być adoptowana stopniowo, a nie obowiązkowo.
To ważne, bo inaczej łatwo wpaść w fałszywy obraz sytuacji: jakby WordPress dopiero teraz „odkrywał AI”. Nie. AI wokół WordPressa dało się budować wcześniej, i to całkiem skutecznie. Różnica polega raczej na tym, że wcześniej było to głównie rzemiosło integracyjne po stronie autora rozwiązania, a teraz Core próbuje część tego rzemiosła nazwać, wydzielić i ustandaryzować.
REST API rozwiązuje ważny problem, ale nie wszystkie
REST API jest świetne w tym, do czego zostało zaprojektowane. Daje endpointy, transport, standardowy sposób pobierania i zapisywania danych, tworzenia wpisów, dodawania mediów, aktualizacji treści i komunikacji z WordPressem z zewnątrz. Jeśli budujesz własne narzędzie i kontrolujesz cały pipeline, REST bardzo często wystarcza. W praktyce to właśnie dlatego tyle automatyzacji, integracji i headlessowych wdrożeń WordPressa od lat opiera się na REST API.
Problem zaczyna się gdzie indziej. REST mówi głównie: „tu jest zasób” albo „tu jest endpoint”. Nie rozwiązuje sam z siebie takich spraw jak wspólna konfiguracja providerów AI, jednolity sposób rozmowy z różnymi modelami, odkrywalny katalog możliwości systemu albo semantyczny opis tego, co agent czy automatyzacja mogą bezpiecznie wykonać. Innymi słowy: REST dobrze rozwiązuje transport, ale nie porządkuje całej architektury AI wokół WordPressa. Właśnie w tę lukę próbują wejść nowe warstwy.
Co naprawdę dokłada AI Client
Najłatwiej zrozumieć to na przykładzie. Jeśli dziś chcesz zbudować własne narzędzie AI wokół WordPressa, to zwykle musisz sam zdecydować, jak łączysz się z providerami, jak trzymasz konfigurację, jak mapujesz requesty i odpowiedzi różnych modeli, jak obsługujesz uwierzytelnienie i jak przełączasz się między dostawcami. To wszystko jest do zrobienia, ale każda wtyczka i każdy projekt robi to trochę inaczej. Oficjalny opis AI Clienta w WordPressie 7.0 mówi właśnie o tym problemie: ma to być wbudowane, niezależne od dostawcy PHP API, które pozwala pluginom wysyłać prompty do modeli i odbierać wyniki przez spójny interfejs.
To oznacza, że AI Client nie zastępuje Twojej logiki produktu. Nie powie sam, że najpierw trzeba zrobić szkic, potem poprawki, potem tekst końcowy, a na końcu grafikę. Tę orkiestrację nadal projektujesz sam. AI Client ma uprościć coś innego: warstwę technicznego „kleju” między WordPressem a providerami modeli. Czyli mniej własnej infrastruktury po to, żeby w ogóle porozmawiać z AI, i większa szansa, że kilka pluginów w ekosystemie będzie robiło to podobnie.
Najkrócej: REST API pozwala Ci wysłać efekt do WordPressa. AI Client ma ułatwić etap wcześniejszy, czyli samą komunikację z modelami. To nie jest ta sama warstwa problemu.
Co naprawdę dokładają Abilities
Jeszcze ciekawsza jest różnica między REST API a Abilities. Oficjalny dev note dla WordPressa 6.9 opisuje Abilities API jako fundament, który pozwala Core, pluginom i motywom rejestrować swoją funkcjonalność w ujednoliconym, standaryzowanym i maszynowo czytelnym formacie. Ability ma mieć opis, wejścia, wyjścia, permission callback i logikę wykonania. To jest coś więcej niż zwykły endpoint.
Tu właśnie kryje się najważniejsza różnica. REST API mówi głównie: „oto adres, pod który możesz wysłać żądanie”. Ability mówi raczej: „oto konkretna możliwość systemu, którą można odkryć, zrozumieć i wywołać zgodnie z określonym kontraktem”. To semantyczna warstwa nad działaniem systemu. WordPress zaznacza przy tym, że abilities mogą być automatycznie wystawiane przez REST API, więc nie chodzi o porzucenie REST-u, tylko o nadanie temu, co robi WordPress, bardziej ustandaryzowanej i czytelnej formy.
To ma znaczenie zwłaszcza wtedy, gdy z WordPressem mają rozmawiać nie tylko ręcznie napisana integracja albo pojedynczy skrypt, ale też agent AI, narzędzie automatyzacji workflow albo inna wtyczka, która nie zna Twojej własnej architektury. W takiej sytuacji odkrywalne abilities są po prostu wygodniejsze niż zestaw niestandardowych endpointów i niestandardowej dokumentacji.
Connectors rozwiązują jeszcze inny problem
Do tego dochodzi jeszcze jedna warstwa, której często nie widać na pierwszy rzut oka: Connectors API. Oficjalny dev note mówi, że odpowiada ono za rejestrowanie i zarządzanie połączeniami z usługami zewnętrznymi, a w przypadku providerów AI potrafi automatycznie wykrywać dostawców zarejestrowanych przez WP AI Client i tworzyć odpowiednie connectory z poprawnymi metadanymi.
Znów: to nie jest coś, bez czego nie da się wysłać requestu do modelu. Ale jeśli masz kilka pluginów AI, kilku providerów albo bardziej rozbudowane środowisko administracyjne, wspólna warstwa konfiguracji zaczyna być bardzo cenna. Zamiast kilku osobnych ekranów ustawień, kilku miejsc na klucze API i kilku różnych modeli konfiguracji, WordPress próbuje zbudować wspólny punkt wejścia. To bardziej infrastruktura ekosystemu niż funkcja widoczna na demo, ale właśnie takie elementy zwykle najmocniej wpływają na to, czy cały system z czasem robi się spójny, czy chaotyczny.
Czyli po co te warstwy, skoro dało się bez nich?
Bo „dało się” i „warto to standaryzować” nie są sprzeczne. Dało się zbudować własny pipeline na REST API. Dało się też samemu ogarnąć providerów, prompty, przepływ danych, publikację, media i walidację. Ale z punktu widzenia Core problem wygląda szerzej niż pojedynczy projekt. WordPress nie projektuje tych warstw tylko dla jednego narzędzia, ale dla całego ekosystemu pluginów, integracji, automatyzacji i coraz częściej także agentów AI. Oficjalne materiały o Abilities i Client-Side Abilities mówią wprost o wspólnym interfejsie dla pluginów, workflow automation tools i AI agents.
Właśnie tu pojawia się sens nowych warstw. Nie po to, żeby powiedzieć: „teraz dopiero można zrobić AI w WordPressie”, ale po to, żeby powiedzieć: „można to robić w bardziej przewidywalny i współdzielony sposób”. To różnica między pojedynczym, dobrze zrobionym rozwiązaniem a budowaniem standardu dla całego ekosystemu.
Gdzie REST nadal będzie wystarczał
Warto to powiedzieć wprost: w wielu przypadkach REST nadal będzie wystarczający. Jeśli budujesz zamknięte, własne narzędzie, kontrolujesz cały pipeline, nie potrzebujesz przenaszalności między providerami ani odkrywalnych możliwości dla zewnętrznych agentów, to dodatkowe warstwy mogą być dla Ciebie tylko architektonicznym narzutem. I to też jest uczciwy wniosek. WordPress nie mówi przecież, że każdy musi teraz przepisać swoje integracje na nowy model. Materiały o Abilities API wyraźnie zaznaczają stopniową adopcję i brak wpływu na istniejącą funkcjonalność.
To oznacza, że Twoje własne rozwiązanie oparte na REST API nie jest dowodem, że WordPress robi coś zbędnego. Jest raczej dowodem, że wcześniej trzeba było wziąć na siebie więcej odpowiedzialności projektowej i integracyjnej. Dla jednego projektu to często jest w porządku. Dla całego ekosystemu już niekoniecznie.
Gdzie nowe warstwy naprawdę zaczynają mieć sens
Nowe API mają największy sens tam, gdzie kończy się prosty przypadek „mam własny skrypt i własny workflow”. Sens rośnie wtedy, gdy kilka pluginów ma korzystać z tej samej konfiguracji providerów, gdy chcesz łatwiej podmieniać modele, gdy chcesz, żeby możliwości WordPressa były wykrywalne przez inne narzędzia, albo gdy część logiki ma działać w przeglądarce, a nie wyłącznie w PHP. Właśnie dlatego obok Abilities API pojawia się też Client-Side Abilities API dla JavaScriptu, a obok AI Clienta — Connectors API.
Patrząc w ten sposób, nowe warstwy są mniej odpowiedzią na pytanie „jak opublikować wpis przez AI?”, a bardziej odpowiedzią na pytanie „jak zbudować powtarzalny, rozszerzalny model AI dla całego WordPressa?”. To już zupełnie inna skala problemu.
Najuczciwszy werdykt
Najuczciwiej byłoby powiedzieć tak: REST API wystarcza do zbudowania własnego workflow. AI Client, Abilities i Connectors nie zastępują REST-u, tylko porządkują to, co do tej pory trzeba było budować samemu ponad nim.To nie jest rewolucja w sensie „wcześniej się nie dało, a teraz dopiero się da”. To raczej próba standaryzacji.
I chyba właśnie tak najlepiej patrzeć na WordPress 7.0. Nie jak na wersję, która magicznie dodaje AI, ale jak na wersję, która zaczyna układać wokół AI kilka brakujących warstw infrastruktury. Dla jednych będą one zbędne. Dla innych okażą się tym, czego od dawna brakowało. Ale ich sens nie polega na tym, że wcześniej nic nie działało. Ich sens polega na tym, że wcześniej każdy robił to trochę po swojemu.
