WordPress 7.0 „Armstrong” trafił do użytkowników 20 maja 2026 roku. To nie jest aktualizacja, którą da się sprowadzić do kilku poprawek w edytorze. W pakiecie znalazły się nowe fundamenty pod integracje AI, przebudowę sposobu, w jaki wtyczki mogą wystawiać swoje funkcje, oraz JavaScriptowy most między kokpitem a agentami działającymi w przeglądarce. Sama wersja 7.0 objęła ponad 419 zgłoszeń w Core Trac, ponad 76 ulepszeń i funkcji oraz ponad 300 poprawek błędów.
Sedno zmiany jest proste: WordPress zaczyna opisywać swoje możliwości w sposób czytelny dla maszyn. Nie chodzi już tylko o to, że model językowy napisze tekst do wpisu. Chodzi o to, że system może dostać listę dostępnych czynności, sprawdzić wymagane uprawnienia, przyjąć dane wejściowe, wykonać akcję i zwrócić wynik w przewidywalnym formacie. To różnica między chatbotem, który „podpowiada”, a narzędziem, które realnie wykonuje pracę w WordPressie.
Model językowy zyskuje „ręce” – jak działają systemowe zdolności
Abilities API pojawiło się już w WordPressie 6.9. Wersja 7.0 rozbudowuje ten pomysł i łączy go z nową infrastrukturą AI, ale punkt wyjścia jest wcześniejszy: wtyczki, motywy i sam Core mogą rejestrować swoje funkcje jako abilities, czyli samodzielne jednostki działania opisane w ustandaryzowanym, maszynowo czytelnym formacie.
W praktyce ability to nie „magiczna komenda dla AI”. To kontrakt. Dobrze zarejestrowana zdolność mówi systemowi:
- jak się nazywa, np.
my-plugin/generate-report, - do jakiej kategorii należy,
- jakie przyjmuje dane wejściowe,
- jaki zwraca wynik,
- kto ma prawo ją wykonać,
- jaka funkcja PHP albo JavaScript faktycznie robi robotę.
To ważne, bo modele językowe są dobre w rozumieniu intencji, ale fatalnie znoszą brak granic. Jeżeli administrator napisze: „przygotuj szkic wpisu z ostatnich danych sprzedażowych”, model nie powinien zgadywać, gdzie kliknąć, jak nazwać pola i czy wolno mu publikować. Abilities API zamienia luźną intencję w zestaw dopuszczonych operacji.
Najmocniejszy przykład to wtyczka, która ma funkcję eksportu raportu. Stary model integracji wyglądał tak: osobny przycisk w panelu, osobny endpoint AJAX, osobna dokumentacja, czasem osobna integracja z zewnętrznym narzędziem automatyzacji. Nowy model: wtyczka rejestruje ability, np. analytics/export-monthly-report, opisuje wymagane parametry — miesiąc, format, zakres danych — i udostępnia wynik w kontrolowany sposób.
Dla dewelopera najważniejsze są tu konkretne elementy API:
wp_register_ability()— rejestruje nową zdolność,wp_get_ability()— pobiera konkretną zdolność,wp_get_abilities()— zwraca listę zarejestrowanych zdolności,wp_register_ability_category()— tworzy kategorię,wp_abilities_api_init— hook, na którym trzeba rejestrować abilities,wp_abilities_api_categories_init— hook do rejestrowania kategorii.
Tu jest pierwszy praktyczny filtr jakości: nie rejestruj wszystkiego. Ability powinna opisywać konkretną czynność, którą da się bezpiecznie wykonać i przetestować. Dobry kandydat to „utwórz szkic wpisu”, „pobierz liczbę zamówień”, „wygeneruj raport”, „sprawdź status licencji”. Słaby kandydat to „zrób SEO”, „popraw stronę”, „zarządzaj sklepem”. Takie polecenia są zbyt szerokie, trudne do walidacji i niebezpieczne przy automatyzacji.
Drugim filtrem jest JSON Schema. Abilities API używa schematów dla danych wejściowych i wyjściowych. Jeżeli ability przyjmuje tytuł wpisu, status publikacji i treść, trzeba wskazać typy pól, wymagane wartości, limity długości i dopuszczalne opcje. WordPress waliduje input przed wykonaniem oraz output po wykonaniu. Schemat nie jest papierową dokumentacją — to barierka bezpieczeństwa.
Trzeci filtr to permission callback. Jeżeli akcja kasuje wpis, zmienia ustawienia albo wysyła dane do zewnętrznego modelu AI, nie może być dostępna tylko dlatego, że użytkownik zna jej nazwę. Permission callback powinien używać realnych uprawnień WordPressa, np. current_user_can( 'manage_options' ), edit_posts, publish_posts albo własnych capabilities dodanych przez wtyczkę. W Client-Side Abilities API brak uprawnień kończy się błędem ability_permission_denied.
To jest moment, w którym model językowy dostaje „ręce”, ale nie dostaje wolnej ręki. Agent może działać tylko w granicach zarejestrowanych abilities, z walidacją danych, kontrolą uprawnień i przewidywalnym zwrotem wyniku. Dla administratora strony to dobra wiadomość. Dla autora wtyczki — dodatkowa odpowiedzialność.
Największy błąd wdrożeniowy? Rejestrowanie destrukcyjnych akcji zbyt wcześnie. Najpierw warto wystawić abilities tylko do odczytu: pobieranie statystyk, list, statusów, szkiców, konfiguracji. Dopiero po testach można dodać akcje zmieniające stan systemu, takie jak publikacja, usuwanie, aktualizacja ustawień czy synchronizacja z zewnętrznym CRM.
Client-Side Abilities API, czyli sterowanie WordPressem za pomocą komend
WordPress 7.0 dokłada do pierwotnego Abilities API warstwę JavaScriptową. To Client-Side Abilities API — odpowiednik działający po stronie przeglądarki, przygotowany z myślą o kokpicie, edytorze blokowym, agentach przeglądarkowych i rozszerzeniach takich jak WebMCP. Oficjalny cel jest konkretny: umożliwić zdolności klienta, takie jak nawigowanie po interfejsie albo wstawianie bloków.
To zmienia sposób myślenia o „klikaniu przez AI”. Najzdrowszy model nie polega na tym, że agent próbuje trafić kursorem w przycisk po współrzędnych. To kruche. Wystarczy inny język panelu, zmieniony układ menu albo modal z komunikatem i automatyzacja się sypie. Client-Side Abilities API pozwala opisać czynność jako funkcję, np. „przejdź do ustawień wtyczki”, „wstaw blok”, „utwórz element”, „uruchom akcję w panelu”. Agent nie musi udawać człowieka przy myszy. Może wykonać zarejestrowaną zdolność.
Nowa warstwa składa się z dwóch paczek:
@wordpress/abilities— czyste zarządzanie stanem: store, rejestracja, wyszukiwanie i wykonywanie abilities, bez zależności od serwera WordPressa;@wordpress/core-abilities— warstwa integracyjna WordPressa, która pobiera abilities i kategorie z REST API/wp-abilities/v1/i rejestruje je po stronie klienta.
W praktyce decyzja jest prosta. Jeżeli wtyczka potrzebuje abilities zarejestrowanych po stronie serwera, ładuje @wordpress/core-abilities. Jeżeli działa wyłącznie na własnej stronie administracyjnej i rejestruje tylko lokalne akcje JavaScriptowe, wystarczy @wordpress/abilities. WordPress Core ładuje @wordpress/core-abilities na stronach administracyjnych, więc abilities serwerowe są domyślnie dostępne w panelu.
Najważniejsze funkcje po stronie JavaScriptu to:
registerAbility,registerAbilityCategory,getAbilities,getAbility,executeAbility,unregisterAbility.
Dla użytkownika końcowego brzmi to technicznie, ale konsekwencja jest bardzo praktyczna. Komenda „przejdź do ustawień newslettera i ustaw częstotliwość wysyłki na tygodniową” może zostać rozbita na dozwolone akcje: nawigacja do ekranu, odczyt aktualnej konfiguracji, zmiana wskazanego pola, zapis. Tylko pod warunkiem, że wtyczka wystawiła odpowiednie abilities i użytkownik ma uprawnienia.
Warto zwrócić uwagę na adnotacje. Abilities mogą być oznaczane jako:
readonly: true— operacja tylko czyta dane,destructive: true— operacja zmienia lub usuwa dane,idempotent: true— powtórne wykonanie z tym samym inputem daje ten sam rezultat.
To nie są ozdobniki dla dokumentacji. Od tych adnotacji zależy sposób wykonania po stronie REST: readonly używa GET, operacja destrukcyjna i idempotentna może użyć DELETE, a pozostałe przypadki idą przez POST.
Deweloperzy powinni tu podjąć ostrą decyzję: każda ability modyfikująca dane musi mieć jawnie opisane ryzyko. Jeżeli funkcja publikuje wpis, wysyła newsletter, usuwa produkt albo zmienia ceny w WooCommerce, nie powinna być wystawiona jako luźna komenda bez potwierdzenia, logowania zdarzeń i testów ról użytkowników. Najpierw staging. Potem konto testowe z ograniczonymi uprawnieniami. Dopiero potem produkcja.
WordPress 7.0 dokłada też WP AI Client i Connectors API. AI Client daje wtyczkom provider-agnostyczny sposób wysyłania promptów do modeli AI, a Connectors API standaryzuje konfigurację połączeń z zewnętrznymi usługami. W panelu Settings → Connectors pojawiają się featured connectors dla Anthropic, Google i OpenAI, ale to nie oznacza darmowego AI w Core ani automatycznego wysyłania danych poza stronę. Połączenia wymagają konfiguracji, a samo uruchomienie promptów wymaga kodu, który je wywoła.
Najbardziej praktyczny szczegół bezpieczeństwa dotyczy kluczy API. Dla connectorów z api_key WordPress szuka danych w tej kolejności: zmienna środowiskowa, potem stała PHP, dopiero potem baza danych. Klucze zapisane w bazie są maskowane w interfejsie, ale nie są szyfrowane; szyfrowanie jest osobnym tematem rozwijanym w kolejnym tickecie.
Decyzja administracyjna jest więc jasna: dla produkcyjnych stron lepsze są zmienne środowiskowe lub stałe PHP niż wklejanie kluczy w panelu, szczególnie na stronach z wieloma administratorami, integratorami i kontami agencyjnymi.
Nowa era wtyczek: kto zintegruje się z Abilities API, ten będzie widoczny dla agentów
Stare wtyczki nie przestaną działać z dnia na dzień. To ważne. Abilities API nie łamie istniejącego kodu i może być wdrażane stopniowo. WordPress 6.9 wprowadził je jako nową funkcję bez wpływu na dotychczasowe działanie wtyczek i motywów.
Ale rynek nie zmienia się wyłącznie przez twarde blokady techniczne. Częściej zmienia się przez widoczność. Wtyczka, która nie wystawia swoich funkcji jako abilities, nadal będzie mieć ekran ustawień, przyciski i dokumentację. Problem w tym, że dla agentów AI i narzędzi automatyzacji może być praktycznie „ślepa”. Agent nie widzi intencji ukrytej w losowym formularzu ustawień. Widzi abilities, endpointy, schematy danych, uprawnienia i kategorie.
Dlatego Plugin Economy po WordPressie 7.0 będzie premiować wtyczki, które potrafią opisać swoje możliwości w sposób maszynowo czytelny. Nie chodzi o modę na AI. Chodzi o integracyjność. Wtyczka SEO może wystawić ability do analizy szkicu. Wtyczka formularzy — ability do pobrania leadów z ostatnich 7 dni. Wtyczka e-commerce — ability do sprawdzenia produktów z niskim stanem magazynowym. Wtyczka rezerwacyjna — ability do znalezienia wolnych terminów bez ręcznego przeklikiwania panelu.
Priorytety dla autora wtyczki są następujące:
- Najpierw abilities tylko do odczytu
Lista statusów, statystyki, podgląd konfiguracji, walidacja ustawień. To najbezpieczniejszy start. - Potem akcje tworzące szkice, nie publikujące publicznie
Generowanie szkicu wpisu, propozycji opisu produktu, wstępnego raportu. Użytkownik zatwierdza efekt. - Na końcu akcje destrukcyjne i finansowe
Usuwanie danych, publikacja, zmiana cen, wysyłka mailingu, operacje na zamówieniach. Te działania wymagają najostrzejszych permission callbacków, logów i testów. - REST tylko wtedy, gdy naprawdę potrzebny
Abilities mogą być udostępniane przez REST po ustawieniumeta.show_in_rest. Dostęp wymaga uwierzytelnionego użytkownika, a dla zewnętrznego dostępu rekomendowanym mechanizmem są application passwords. - Kompatybilność bez paniki
Jeżeli wtyczka ma działać również na WordPressie starszym niż 6.9, trzeba sprawdzać istnienie funkcji, np.function_exists( 'wp_register_ability' ), zanim kod zacznie rejestrować abilities.
Dla właściciela strony najważniejsza decyzja nie brzmi „czy włączyć AI”, tylko „którym wtyczkom pozwalam działać przez abilities”. Lista kontrolna przed wdrożeniem jest krótka, ale konkretna:
- sprawdź, czy strona działa na WordPressie 7.0 i co najmniej PHP 7.4; rekomendowana wersja PHP pozostała na poziomie 8.3, a PHP 7.2 i 7.3 zostały porzucone w WordPressie 7.0,
- zrób test na stagingu, nie na produkcji,
- utwórz konto testowe z rolą niższą niż administrator i sprawdź, które abilities może wykonać,
- nie wystawiaj destrukcyjnych działań bez logów i potwierdzeń,
- trzymaj klucze API poza bazą, gdy hosting i proces deploymentu na to pozwalają,
- testuj scenariusz „brak skonfigurowanego modelu AI” — wtyczka ma się grzecznie wyłączyć, a nie rzucać błędami w kokpicie.
Koszt? Samo Abilities API nie ma osobnego cennika w WordPress Core. Koszty pojawiają się po bokach: praca deweloperska, testy, utrzymanie integracji oraz opłaty u dostawców modeli AI, jeżeli dana funkcja faktycznie wysyła prompt do zewnętrznego modelu. WordPress nie uruchamia takich połączeń automatycznie i nie wysyła danych do zewnętrznych usług bez konfiguracji oraz kodu wywołującego.
Najrozsądniejsza ścieżka dla rynku wtyczek jest więc pragmatyczna. Nie przepisywać wszystkiego. Nie dorabiać „AI” do każdej opcji w panelu. Najpierw wybrać 3–5 funkcji, które użytkownicy realnie wykonują często i które da się bezpiecznie opisać schematem. Potem dodać abilities. Dopiero później łączyć je w sekwencje, które agent może wykonywać jedna po drugiej.
Wtyczki, które to zrobią, będą łatwiejsze do automatyzacji. Wtyczki, które zostaną przy zamkniętych ekranach ustawień i niestandardowych przyciskach, nadal będą działać — ale w świecie agentów będą wymagały ręcznej obsługi. To nie jest natychmiastowy wyrok. To powolna utrata przewagi.
FAQ: najczęstsze pytania o Abilities API w WordPress 7.0
Czy Abilities API pojawiło się dopiero w WordPressie 7.0?
Nie. Podstawowe Abilities API zostało wprowadzone w WordPressie 6.9, a WordPress 7.0 rozbudował je o warstwę JavaScriptową, WP AI Client i integrację z nową infrastrukturą AI.
Czy WordPress 7.0 ma wbudowanego asystenta AI w kokpicie?
Nie w takim sensie, w jakim wielu użytkowników to sobie wyobraża. Core dostarcza infrastrukturę dla deweloperów: AI Client, Connectors API i abilities. Nie ma domyślnego, końcowego „asystenta AI” dla użytkownika ani automatycznego wysyłania danych do modeli.
Czy wtyczka musi wdrożyć Abilities API, żeby działać w WordPressie 7.0?
Nie. Istniejące wtyczki mogą dalej działać. Integracja z Abilities API jest jednak coraz ważniejsza, jeżeli funkcje wtyczki mają być dostępne dla agentów AI, workflow automation i narzędzi sterowanych komendami.
Czy Abilities API jest bezpieczne?
Jest bezpieczniejsze niż przypadkowe endpointy i automatyzacje „klikające” po interfejsie, ale tylko przy poprawnym wdrożeniu. Najważniejsze są: permission_callback, walidacja przez JSON Schema, ograniczenie akcji destrukcyjnych, testy ról użytkowników i ostrożne wystawianie REST API.
Od czego powinien zacząć autor wtyczki?
Od jednej kategorii i kilku abilities tylko do odczytu. Dopiero po testach warto dodać akcje tworzące szkice, a na końcu operacje destrukcyjne. Rejestracja abilities poza hookiem wp_abilities_api_init zakończy się błędem _doing_it_wrong() i nieudaną rejestracją.
Co właściciel strony powinien sprawdzić jako pierwsze?
Najpierw wersję WordPressa, PHP i role użytkowników. Potem staging, klucze API i listę wtyczek, które faktycznie wystawiają abilities. Największy błąd to podłączenie modelu AI do produkcyjnej strony bez sprawdzenia, które akcje może wykonać konto redaktora, autora albo zewnętrznego integratora.
