Zwrot agentowy: jak agenci AI zmieniają wybór platformy WordPress, design i bezpieczeństwo

#Jak agenci AI wybierają platformę CMS

Wybór platformy był kiedyś decyzją ludzi: właścicieli, agencji i CTO. Andy Peatling, który przez 17 lat pracował w Automattic, a dziś tworzy Miles, agenta AI do projektowania w WordPressie, twierdzi, że ta ścieżka się zamyka. W tekście Ideas for WordPress in an agentic world (14 września 2026) pisze, że agent wybiera platformę na podstawie danych treningowych lub wyszukiwania w sieci i potrafi postawić prostą stronę w około 30 sekund. Jego wniosek jest bezpośredni: “Jeśli WordPress nie jest wybierany, projekt nie będzie rósł” (tłumaczenie własne).

Peatling przedstawia trzy konkretne propozycje:

• Dwie zadeklarowane ścieżki dla agentów. WordPress powinien zdefiniować i publicznie zobowiązać się do dwóch kompletnych ścieżek, które agent może przejść od początku do końca, na przykład strony zbudowanej w całości przez agenta programistycznego, od utworzenia przez publikację po hosting. Jako infrastrukturę, którą te ścieżki powinny łączyć, wymienia Abilities, MCP, Agent Skills oraz metadane motywów i wtyczek, ze zdefiniowanymi uprawnieniami, zatwierdzeniami, punktami przywracania i dziennikami audytu.
• Publiczne benchmarki. Śledzenie skuteczności agentów na tych ścieżkach, zapisywanie, kiedy i dlaczego agenci uwzględniają lub pomijają WordPressa przy wyborze platformy, oraz mierzenie natywnych zdolności agentów narzędziami takimi jak WP-bench.
• Jedno źródło wiedzy dla agentów na WordPress.org. Wyjaśnienie, kiedy WordPress jest właściwym wyborem, a kiedy nie, wyraźne oznaczenie aktualnych API i obniżenie priorytetu starszych oraz taka struktura dokumentacji, by agenci mogli ją przyswoić.

To samo pytanie przewijało się w odcinku WP Minute z udziałem Alexa Panagisa, Briana Coordsa, Andy’ego Peatlinga i Mike’a McAlistera, How do we get agents to use WordPress. Notatki do odcinka odnotowują, że agenci poproszeni o zbudowanie strony nie zawsze polecają WordPressa, że WordPress potrzebuje wyraźniejszego stanowiska, jak agenci mają z niego korzystać, oraz że Abilities API może stać się fundamentem agentowego WordPressa.

#Co robi serwer MCP Elementora w wersji beta w WordPressie

Elementor otworzył swoją betę MCP 15 września 2026. Udostępnia ona możliwości budowania stron przez zdolności WordPressa, więc klient MCP może tworzyć i edytować strony jako natywne struktury Elementora, zamiast zwracać surowy HTML, który ktoś musi wkleić do szablonu. Elementor wymienia jako klientów Claude Code, Claude Desktop, Codex i Cursor oraz każde inne narzędzie obsługujące MCP.

Ogłoszenie wymienia dziewięć możliwości:

• budowanie atomowych stron i układów w jednym kroku,
• edycja lub przeprojektowanie istniejących atomowych stron i układów,
• tworzenie, stosowanie i porządkowanie klas i zmiennych, ustawianie stanów hover i dostosowywanie punktów przełamania responsywności,
• tworzenie i zarządzanie częściami motywu, takimi jak nagłówki, stopki, archiwa i popupy, z warunkami wyświetlania,
• umieszczanie, wypełnianie lub tworzenie komponentów,
• podłączanie danych dynamicznych, takich jak pola wpisów, pola niestandardowe i taksonomie,
• tworzenie własnych widżetów i widoków w panelu administracyjnym,
• masowa aktualizacja treści, debugowanie błędów i uzupełnianie braków SEO,
• dostęp do każdej zdolności zarejestrowanej w WordPress Abilities API, także z wtyczek takich jak WooCommerce, Yoast, WPForms, Jetpack i ACF.

Trzy ostatnie wymagają Angie, osobnej wtyczki Elementora. Beta ma twarde ograniczenia. Dostęp mają tylko administratorzy witryny, połączenie działa per strona, a wszystko, co wygeneruje MCP, zapisuje się jako szkic, nie jest publikowane. Konfiguracja wymaga kanału beta testerów i Atomic Editora. Elementor generuje hasło aplikacji i umieszcza je w prompcie konfiguracyjnym dla narzędzia AI, z opcją ręcznej konfiguracji. Elementy Pro nadal wymagają planu Pro, a standardowy edytor pozostaje bez zmian dla każdego, kto się nie podłączy.

#Jak Block Runner od Human Made waliduje bloki Gutenberga

Block Runner to otwartoźródłowe narzędzie CLI i biblioteka JavaScript od Human Made na licencji GPL-2.0-or-later. README opisuje je jako narzędzie, które “konwertuje obsługiwany HTML na natywne bloki Gutenberga i sprawdza wygenerowany kod za pomocą pakietów Gutenberga używanych przez edytor WordPressa” (tłumaczenie własne). Pakiet pojawił się w npm po raz pierwszy 24 czerwca 2026; wersja 0.9.10 wyszła 4 października 2026.

Problem, który rozwiązuje, zna każdy, kto wklejał wygenerowany kod do edytora: kod, którego edytor nie rozpoznaje, kończy jako blok Własny HTML albo blok proszący o odzyskanie. Block Runner oferuje cztery ścieżki opisane w README:

• convert zamienia HTML na kod bloków według wbudowanych reguł,
• assemble buduje treść strony z drzewa bloków zaplanowanego przez agenta,
• author generuje kod źródłowy wielokrotnego użytku zarejestrowanego bloku, na przykład bloku z komunikatem, dla wtyczki,
• validate i fix sprawdzają lub kanonizują istniejący kod bloków.

Pakiet nie wywołuje żadnego modelu AI. Zewnętrzny agent może zinterpretować projekt i przekazać Block Runnerowi ustrukturyzowany plan, a deterministyczny kod składa i waliduje wynik. Dołączony skill dla agentów programistycznych instaluje się poleceniem npx --no-install block-runner skill --install, które zapisuje go w .agents/skills/block-runner i .claude/skills/block-runner. Podstawowa konwersja wymaga Node.js (20.19+, 22.13+ lub 24+) i nie potrzebuje strony WordPress, Dockera ani agenta.

README jasno mówi o ograniczeniach. Nieobsługiwane struktury mogą zostać jako Własny HTML z ostrzeżeniami, a --strict przerywa uruchomienie przy blokach zastępczych i nierozwiązanych mediach. Dosłownie: “Poprawny kod nie dowodzi wierności wizualnej ani zgodności z każdą stroną” (tłumaczenie własne). Wynik i tak trzeba sprawdzić w docelowej instalacji WordPressa. O tym, jak bloki, wzorce i szablony łączą się ze sobą, piszemy w przewodniku po blokach Gutenberga i full site editing.

#Jakie luki naprawił WordPress 7.1.1 i kto je zgłosił

WordPress 7.1.1 ukazał się 17 września 2026 jako wydanie serwisowe i bezpieczeństwa: 17 poprawek błędów w rdzeniu, 19 poprawek w edytorze blokowym i 11 poprawek bezpieczeństwa. Ogłoszenie zaleca natychmiastową aktualizację i informuje, że poprawki bezpieczeństwa są w razie potrzeby przenoszone do każdej gałęzi, która nadal je otrzymuje. Pełna lista z podziękowaniami, w opublikowanej formie:

Anthropic figuruje przy dwóch z jedenastu problemów, a pwn.ai dzieli jedno zgłoszenie z Paulosem Yibelo. Oba problemy zgłoszone przez Anthropic wymagają uwierzytelnionego konta, jeden z nich tylko poziomu Contributor. Ma to znaczenie przy konfiguracjach z agentami: agent podłączony do strony działa jako użytkownik WordPressa, więc rola, którą mu nadasz, decyduje, do których z tych klas błędów mógłby dotrzeć na niezałatanej instalacji. Role, aktualizacje i monitoring omawia nasz przewodnik po zabezpieczaniu WordPressa.

#Wydarzenie o WordPressie i AI w Faro, październik 2026

Portugalska społeczność WordPressa (Comunidade Portuguesa de WordPress) organizuje WordPress Day for AI Faro 2026 24 października 2026 w hotelu AP Eva Senses w Faro. Według strony wydarzenia potrwa od 09:00 do 18:00, przewidziano 100 miejsc, a wystąpienia będą po portugalsku i angielsku.

Są dwie ścieżki. Ścieżka developerska obejmuje programowanie wspomagane przez AI, narzędzia programistyczne, API, automatyzację, integracje z LLM, MCP oraz przepływy pracy przy tworzeniu na WordPressie. Ścieżka biznesowa jest dla właścicieli firm, agencji i specjalistów i dotyczy produktywności, automatyzacji przepływów pracy i obsługi klienta.

#Czym jest WordPress Abilities API i jak zarejestrować zdolność

Abilities API to warstwa, na której buduje Elementor. Jego część serwerowa weszła do WordPressa 6.9. Zdolność to nazwana jednostka funkcjonalności w formacie namespace/ability-name, rejestrowana funkcją wp_register_ability() w callbacku na haku wp_abilities_api_init. Każda zdolność należy do dokładnie jednej kategorii, rejestrowanej funkcją wp_register_ability_category() na haku wp_abilities_api_categories_init.

Wymagane argumenty to label, description, category, output_schema, execute_callback i permission_callback. input_schema jest opcjonalny i potrzebny tylko wtedy, gdy zdolność przyjmuje dane wejściowe. Oba schematy to JSON Schema, a dane, które nie przejdą walidacji, nigdy nie trafiają do funkcji sprawdzającej uprawnienia. Tablica meta przenosi wskazówki dotyczące zachowania w annotations: readonly, destructive i idempotent.

add_action( 'wp_abilities_api_init', function () {
	wp_register_ability( 'my-plugin/get-site-title', array(
		'label'               => __( 'Get site title', 'my-plugin' ),
		'description'         => __( 'Returns the title of this site.', 'my-plugin' ),
		'category'            => 'site',
		'output_schema'       => array( 'type' => 'string' ),
		'execute_callback'    => fn() => get_bloginfo( 'name' ),
		'permission_callback' => fn() => current_user_can( 'read' ),
		'meta'                => array(
			'annotations'  => array( 'readonly' => true ),
			'show_in_rest' => true,
		),
	) );
} );

Warto znać dwa ustawienia domyślne. Zdolności nie są udostępniane przez REST, dopóki show_in_rest nie jest ustawione na true, a endpointy REST pod /wp-json/wp-abilities/v1 wymagają zalogowanego użytkownika i respektują funkcję sprawdzającą uprawnienia każdej zdolności. Sam rdzeń rejestruje w 6.9 trzy zdolności: core/get-site-info, core/get-user-info i core/get-environment-info. Osobne repozytorium na GitHubie zarchiwizowano po włączeniu kodu do rdzenia. Praktyczne przykłady zdolności w procesach redakcyjnych znajdziesz w tekście przepływy pracy AI w WordPressie z Abilities API.

#Jak WordPress MCP Adapter udostępnia zdolności klientom MCP

MCP Adapter to oficjalny pakiet WordPressa, który zamienia zdolności w narzędzia, zasoby i prompty MCP. Wersja 0.7.0, wydana 2 października 2026, czyni go wtyczką kanoniczną. Wtyczki powinny deklarować w nagłówku Requires Plugins: mcp-adapter zamiast dołączać własną kopię; dołączone kopie nadal działają, ale zapisują w logu komunikat o wycofaniu.

Zdolności są domyślnie prywatne. Zdolność trafia do MCP tylko wtedy, gdy meta.public (lub meta.mcp.public) ma wartość true. Serwer domyślny, pod adresem /wp-json/mcp/mcp-adapter-default-server, udostępnia trzy metanarzędzia zamiast jednego narzędzia na zdolność: mcp-adapter-discover-abilities, mcp-adapter-get-ability-info i mcp-adapter-execute-ability. Agent sprawdza, co jest dostępne, pobiera potrzebny schemat, a potem wykonuje zdolność. Dzięki temu odpowiedź tools/list zawiera trzy schematy niezależnie od tego, ile wtyczek rejestruje zdolności. Własny serwer utworzony na haku mcp_adapter_init działa odwrotnie i wystawia każdą wybraną zdolność jako osobne narzędzie.

Klienta można podłączyć na dwa sposoby:

• STDIO przez WP-CLI: wp mcp-adapter serve --server=mcp-adapter-default-server --user=admin. Flaga --user decyduje, jako który użytkownik WordPressa wykonywane są kontrole uprawnień; bez niej sesja jest nieuwierzytelniona.
• HTTP przez proxy @automattic/mcp-wordpress-remote, które uwierzytelnia się hasłem aplikacji.

Bezpieczeństwo działa w dwóch warstwach. Funkcja sprawdzająca uprawnienia transportu chroni cały serwer i domyślnie wywołuje is_user_logged_in(), a każda zdolność nadal uruchamia własny permission_callback. Adapter obsługuje rewizje protokołu MCP 2025-11-25 i 2026-07-28; starsi klienci są obsługiwani przez schemat 2025-11-25.

#Czego specyfikacja MCP wymaga od narzędzi i hostów

Specyfikacja Model Context Protocol definiuje komunikaty JSON-RPC 2.0 między hostami (aplikacjami LLM), klientami (łącznikami wewnątrz hosta) i serwerami (usługami dostarczającymi kontekst i możliwości). Serwery mogą oferować zasoby, prompty i narzędzia. Obecna rewizja, 2026-07-28, definiuje dwa standardowe transporty: stdio dla podprocesu uruchamianego przez klienta oraz Streamable HTTP, w którym każdy komunikat to żądanie POST do jednego endpointu.

Rozdział o narzędziach ustala zasady ważne wtedy, gdy agent zapisuje dane w WordPressie. W pętli zawsze powinien być człowiek, który może odmówić wywołania narzędzia. Serwery muszą walidować wszystkie dane wejściowe narzędzi, wdrażać kontrolę dostępu, ograniczać częstotliwość wywołań i oczyszczać dane wyjściowe. Klienci powinni prosić o potwierdzenie przy operacjach wrażliwych, pokazywać dane wejściowe przed wywołaniem, ustawiać limity czasu i logować użycie narzędzi. Adnotacje narzędzi należy traktować jako niezaufane, chyba że pochodzą z zaufanego serwera.

Elementy WordPressa pasują do tych zasad. Walidacja JSON Schema w Abilities API odpowiada za sprawdzanie danych wejściowych, permission_callback za kontrolę dostępu, adnotacje readonly i destructive mówią klientowi, które wywołania wymagają potwierdzenia, a zapisywanie przez Elementora wyłącznie szkiców zostawia człowieka między agentem a opublikowaną stroną. Adapter nie ma ogranicznika częstotliwości wywołań (jego przewodnik po obserwowalności wymienia jedynie kod błędu ability_rate_limit, który zdolność może zwrócić), więc ograniczanie częstotliwości zostaje po stronie warstwy hostingu albo samej zdolności.

#Jak działają karty serwera MCP przy wykrywaniu

Agenci muszą też znaleźć serwer, zanim się z nim połączą. SEP-2127, który jako rozszerzenie osiągnął status Final, definiuje MCP Server Cards: statyczne dokumenty z metadanymi opisujące tożsamość zdalnego serwera, endpointy transportu i obsługiwane wersje protokołu. Karta może znajdować się pod dowolnym niezarezerwowanym URI, a streamable-http-url/server-card jest zarezerwowane jako lokalizacja zalecana. Do wykrywania na poziomie domeny AI Catalog opublikowany pod /.well-known/ai-catalog.json może linkować do kart lub je osadzać.

Karty celowo pomijają narzędzia, zasoby i prompty. SEP wyjaśnia, że to, co udostępnia serwer, może zależeć od użytkownika, sesji i konfiguracji, więc klienci muszą korzystać z wywołania tools/list na żywym serwerze. Karty nie mogą zawierać danych uwierzytelniających ani danych konkretnego użytkownika i są opcjonalne: serwery bez karty działają dalej. W WordPressie naturalną bazą dla karty jest adres endpointu adaptera. Publiczny serwer tylko do odczytu w praktyce pokazuje nasz przewodnik po serwerze MCP WPPoland na żywo.

#Jak budować strony WordPress pod agentów AI i GEO

wppoland.com działa na Astro 7 na Cloudflare Pages, a dane Schema.org na każdej stronie są generowane z frontmattera. Nasza zasada robocza: strona ma być tak samo łatwa do odczytania dla maszyny, jak dla człowieka. Dla stron WordPress udokumentowana droga jest krótka: zarejestruj zdolności z rzetelnymi schematami i adnotacjami, przez MCP Adapter opublikuj tylko te, które mają być publiczne, daj agentowi użytkownika WordPressa z najwęższą rolą wystarczającą do zadania i zapisuj zmiany treści jako szkice, dopóki nie zatwierdzi ich człowiek. Te same dane ustrukturyzowane służą też Generative Engine Optimization (GEO).

Jeśli potrzebujesz w tym pomocy, zobacz naszą usługę tworzenia serwerów MCP albo poproś o audyt.