WordPress 7.0 Armstrong – dlaczego zmienia wszystko?

Największa zmiana w WordPressie 7.0 nie polega na tym, że w panelu pojawił się kolejny przycisk „Generate”. To byłoby za mało. Armstrong, wydany publicznie 20 maja 2026 r., przesuwa AI z poziomu przypadkowych dodatków do poziomu wspólnej infrastruktury: AI Client, Connectors API, Abilities API i panel Settings → Connectors zaczynają robić porządek tam, gdzie przez ostatnie lata panował pluginowy bałagan.

Nie oznacza to darmowego generatora treści w rdzeniu. WordPress 7.0 nie wysyła sam z siebie promptów do OpenAI, Google czy Anthropic, nie ma wbudowanego sekretnego modelu i nie rozwiązuje za właściciela strony kwestii prywatności. Daje za to jeden mechanizm, dzięki któremu wtyczki mogą korzystać z AI bez trzymania osobnych kluczy, osobnych ekranów ustawień i osobnych bibliotek do każdego dostawcy. To zmienia codzienną administrację stroną bardziej niż efektowna demonstracja na konferencji.

Koniec z chaosem wtyczek – jak WP 7.0 cywilizuje sztuczną inteligencję

Do tej pory typowy scenariusz wyglądał znajomo: jedna wtyczka generowała meta description, druga opisy produktów, trzecia odpowiadała klientom na czacie, czwarta poprawiała alt texty, piąta streszczała wpisy. Każda prosiła o własny API key, każda miała osobny panel ustawień, każda inaczej obsługiwała błędy i każda na swój sposób decydowała, czy wysłać do modelu tytuł wpisu, pełną treść, dane produktu albo fragment komentarza.

WordPress 7.0 ucina ten problem nie przez zakaz używania wtyczek AI, tylko przez ustandaryzowanie warstwy technicznej. AI Client w rdzeniu jest provider-agnostic, czyli plugin może poprosić WordPressa o wykonanie zadania z użyciem skonfigurowanego modelu, zamiast pisać integrację od zera pod jednego dostawcę. WordPress obsługuje trasowanie zapytania do modelu, który właściciel strony wcześniej ustawił.

To jest różnica między „mam dziesięć wtyczek z AI” a „mam jeden system połączeń, z którego korzystają zgodne wtyczki”. W praktyce oznacza to:

• mniej miejsc, w których przechowywany jest klucz API;
• mniej duplikowania SDK i logiki połączeń;
• łatwiejszą zmianę dostawcy, gdy cena, jakość albo polityka danych przestaje pasować;
• większą szansę, że wtyczki będą wykrywać brak modelu i wyłączać funkcję zamiast generować błędy;
• sensowniejszy model rozwoju dla deweloperów, którzy mogą budować funkcje, a nie po raz setny ekran „wklej klucz OpenAI”.

Rdzeń nie zastępuje wszystkich wtyczek. To ważna granica. WordPress 7.0 nie jest gotowym systemem marketing automation, nie jest CRM-em i nie jest chatbotem sprzedażowym. Rdzeń dostarcza instalację elektryczną. Lampy, przełączniki i automatyka nadal należą do wtyczek, motywów albo własnego kodu.

Dobry przykład: generowanie tytułów, streszczeń, obrazów i alt textów nie jest automatycznie częścią samego WordPressa jako takiego. Te funkcje rozwija opcjonalny plugin AI, który korzysta z nowych „building blocks” WordPressa. W wersji AI 1.0.0 doszły między innymi Request Logging, Connector Approvals, obsługa alt textów w eksperymentalnym edytorze mediów oraz refinements dla workflow redakcyjnego.

Najrozsądniejsza decyzja po aktualizacji nie brzmi więc: „wyrzucamy wszystkie wtyczki AI”. Brzmi: robimy audyt, które wtyczki nadal mają własne klucze, własne koszty i własny dostęp do danych. Te, które dublują podstawową integrację z modelem, powinny trafić na listę do wymiany. Te, które dostarczają realny proces biznesowy — na przykład workflow dla sklepu, moderację komentarzy albo integrację z CRM — mogą zostać, ale powinny korzystać z nowej infrastruktury, gdy tylko autorzy je dostosują.

Największy błąd po stronie właściciela strony to zostawienie starego układu „bo działa”. Działa do pierwszego incydentu: nie wiadomo, która wtyczka zużywa tokeny, który klucz API jest aktywny, gdzie trafiają dane klientów i dlaczego faktura za modele wzrosła po kampanii produktowej.

AI Connectors i realne koszty prowadzenia strony firmowej

Nowy ekran Settings → Connectors jest centrum dowodzenia połączeniami z zewnętrznymi usługami. W WordPressie 7.0 pokazuje domyślnie dostawców Anthropic, Google i OpenAI, pozwala też dodawać własne połączenia. Technicznie opiera się na Connectors API, które obsługuje między innymi metadane dostawcy, logo, opis, konfigurację uwierzytelniania i automatyczne wykrywanie providerów z rejestru AI Clienta.

Z perspektywy firmy najważniejsze są trzy rzeczy: koszt, kontrola dostępu i ślad audytowy.

Koszt nie spada dlatego, że WordPress nagle negocjuje za wszystkich tańsze tokeny. Spada wtedy, gdy przestajesz wysyłać podobne zapytania z kilku wtyczek, przestajesz używać drogiego modelu do prostych zadań i zaczynasz rozdzielać pracę: tani model do klasyfikacji, lepszy model do treści publikowanych, a najdroższy tylko do zadań wymagających rozumowania albo długiego kontekstu.

Cenniki API pokazują, dlaczego to ma znaczenie. OpenAI podaje dla gpt-5.4-mini w trybie Standard cenę $0,75 za 1 mln tokenów wejściowych i $4,50 za 1 mln tokenów wyjściowych; w Batch/Flex jest to $0,375 / $2,25. Google dla Gemini 3.1 Flash-Lite podaje $0,25 input i $1,50 output za 1 mln tokenów, a Anthropic dla Claude Haiku 4.5 — $1 input i $5 output za 1 mln tokenów.

Prosty model budżetowy dla sklepu: 1000 opisów produktów, każdy z promptem około 400 tokenów i odpowiedzią około 180 tokenów. To daje 400 tys. tokenów wejściowych i 180 tys. wyjściowych. Przy takim założeniu koszt samego API wyniesie orientacyjnie:

• Gemini 3.1 Flash-Lite: około $0,37;
• OpenAI gpt-5.4-mini Standard: około $1,11;
• Claude Haiku 4.5: około $1,30.

Do tego trzeba doliczyć zapytania testowe, poprawki, błędne wygenerowania, tłumaczenia, dłuższe prompty, cache, ewentualne wyszukiwanie webowe, VAT, marżę narzędzia pośredniego i koszt samej wtyczki. Różnica między 1000 a 50 000 produktów robi się odczuwalna dopiero wtedy, gdy firma nie ma limitów i nie wie, która funkcja odpala model. Dlatego centralizacja połączeń jest narzędziem kontroli kosztu, a nie magiczną obniżką cennika.

Druga sprawa to bezpieczeństwo. Connectors API wspiera uwierzytelnianie typu api_key oraz none, a WordPress przygotowuje tę warstwę także pod przyszłe typy integracji. To dobry kierunek, ale nie zamyka tematu. Zespół AI WordPressa sam wskazywał ograniczenia rozwiązywania bezpieczeństwa kluczy wyłącznie na poziomie wtyczek: łatwo stworzyć fałszywe poczucie ochrony, jeśli strona nie ma mocniejszego mechanizmu zarządzania sekretami.

Praktyczna procedura dla firmy po przejściu na WordPressa 7.0:

1. Spisz wszystkie aktywne wtyczki AI i sprawdź, które nadal trzymają własne klucze API.
2. Utwórz osobne klucze dla produkcji, stagingu i testów. Nie używaj prywatnego klucza właściciela firmy na wszystkich stronach.
3. Ustaw limit wydatków w panelu dostawcy AI. Limit w WordPressie nie zastąpi limitu billingowego u dostawcy.
4. Włącz logowanie zapytań, gdy korzystasz z funkcji eksperymentalnych AI 1.0.0 i chcesz widzieć, które funkcje, providery i workflow generują ruch.
5. Zezwalaj wtyczkom na dostęp do connectorów świadomie. Connector Approvals pozwala administratorowi decydować, które wtyczki mogą używać skonfigurowanych połączeń.
6. Usuń stare klucze z nieużywanych wtyczek. Samo wyłączenie funkcji AI w panelu często nie wystarcza, jeśli plugin nadal przechowuje sekret w opcjach.

Dla małej firmy największa oszczędność zwykle nie wynika z wyboru modelu tańszego o kilka centów. Wynika z zatrzymania niekontrolowanych workflow. Automatyczne generowanie 200 opisów po każdej zmianie importu CSV potrafi kosztować więcej niż dobrze zaplanowana jednorazowa aktualizacja katalogu.

E-commerce i blogi po aktualizacji: automatyzacja, która pracuje na danych serwisu

Najciekawsza część WordPressa 7.0 zaczyna się tam, gdzie AI przestaje być pustym polem tekstowym, a zaczyna korzystać z danych strony. Abilities API opisuje, co WordPress i wtyczki potrafią zrobić w sposób możliwy do wykrycia przez narzędzia automatyzacji. WordPress 7.0 rozwija ten kierunek przez client-side abilities, command palette i mechanizmy pozwalające łączyć akcje w workflow.

W WooCommerce kierunek jest już konkretny. Dokumentacja WooCommerce MCP opisuje obsługę Model Context Protocol jako developer preview: AI może odkrywać operacje sklepu z zachowaniem uwierzytelniania i uprawnień, a dostępne abilities obejmują między innymi odpytywanie produktów, tworzenie, aktualizowanie i usuwanie produktów, odpytywanie zamówień, zmianę statusu zamówienia oraz dodawanie notatek.

To otwiera trzy praktyczne zastosowania.

Pierwsze: opisy produktów. Dobrze ustawiony workflow nie powinien wysyłać do modelu samej nazwy produktu. To przepis na generyczne teksty i wymyślone obietnice. Minimum danych wejściowych dla sklepu to:

• nazwa produktu i SKU;
• kategoria oraz warianty;
• materiał, wymiary, pojemność, kolor, kompatybilność;
• realne cechy techniczne;
• ograniczenia: czego produkt nie robi, z czym nie jest zgodny;
• styl marki;
• zakazane twierdzenia, np. „najlepszy”, „certyfikowany”, „medyczny”, jeśli firma nie ma dowodów;
• długość opisu krótkiego i pełnego;
• język i format odpowiedzi.

Dopiero wtedy AI ma sens. Najpierw generuje szkic, potem człowiek zatwierdza, a dopiero na końcu opis trafia do katalogu. Przy 20 produktach ręczna kontrola nie boli. Przy 5000 produktach trzeba dodać kolejkę, wersjonowanie, diff i możliwość cofnięcia zmiany. WooCommerce testuje już AI Product Advisor, publiczną betę z maja 2026 r., która analizuje katalog, sugeruje poprawki w tytułach, opisach, kategoriach, tagach i wariantach oraz pokazuje historię zaakceptowanych zmian. Sam opis projektu jasno mówi jednak, że to narzędzie eksperymentalne.

Drugie zastosowanie: asystent klienta. Różnica między prostym chatbotem a sensownym asystentem sprzedażowym leży w danych. Bot, który zna tylko FAQ, odpowiada ogólnikami. Asystent połączony z bazą produktów może sprawdzić dostępność, warianty, kompatybilność, widełki cenowe, kategorie i powiązane produkty. Tu trzeba postawić twardą granicę: odczyt informacji o produkcie jest niskim ryzykiem, ale zmiana statusu zamówienia, rabat, zwrot pieniędzy albo edycja stanu magazynowego wymagają uprawnień, logów i potwierdzenia człowieka.

Trzecie zastosowanie: blogi i redakcje. WordPressowy plugin AI rozwija funkcje typowo redakcyjne: generowanie tytułów, excerptów, alt textów, klasyfikację treści, notatki edytorskie i aktualizacje na podstawie uwag. To nie zastępuje redaktora. Przyspiesza zadania, które są powtarzalne, ale nadal wymagają kontroli: streszczenia starych wpisów, opisy obrazów, propozycje meta title, czyszczenie struktury nagłówków, wykrywanie wpisów bez aktualizacji od dwóch lat.

Najlepsza kolejność wdrożenia wygląda tak:

1. Najpierw zadania niskiego ryzyka: alt text jako sugestia, excerpt, tagi, klasyfikacja, szkice meta description.
2. Potem zadania średniego ryzyka: opisy produktów, aktualizacje kategorii, rozbudowa FAQ, teksty landing page.
3. Na końcu automatyzacje z zapisem do bazy: aktualizacja produktów, zmiany statusów, masowe poprawki treści, akcje na zamówieniach.

Nie automatyzuj od razu cen, stanów magazynowych, regulaminów, treści medycznych, finansowych ani odpowiedzi reklamacyjnych. Tu AI może przygotować propozycję, ale decyzja powinna zostać po stronie człowieka. Najgorszy scenariusz w sklepie to nie słaby opis produktu. Najgorszy scenariusz to masowa publikacja błędnej informacji o kompatybilności, gwarancji albo dostępności.

FAQ: najczęstsze pytania o WordPress 7.0 Armstrong i AI

Czy WordPress 7.0 ma AI włączone automatycznie?
Nie. Rdzeń daje infrastrukturę, ale nie wysyła danych do zewnętrznych modeli bez konfiguracji dostawcy i bez kodu lub wtyczki, która uruchomi konkretne zapytanie.

Czy można usunąć wszystkie dotychczasowe wtyczki AI?
Nie od razu. Usuń lub wymień przede wszystkim te, które dublują integrację z dostawcą i trzymają osobne klucze API. Wtyczki odpowiedzialne za realny proces, np. sklepowy asystent, workflow SEO albo moderację komentarzy, nadal mogą być potrzebne.

Czy AI Connectors naprawdę obniżają koszty?
Obniżają koszty organizacyjne i ryzyko dublowania zapytań. Nie zmieniają samych cen tokenów u OpenAI, Google czy Anthropic. Rachunek spada dopiero wtedy, gdy firma wybiera tańsze modele do prostych zadań, ogranicza automatyczne przebiegi i widzi w logach, co zużywa API.

Co sprawdzić przed aktualizacją do WordPressa 7.0?
Najpierw staging, kopia zapasowa, zgodność motywu, page buildera, WooCommerce i krytycznych wtyczek. WordPress wciąż bazuje na PHP, a dokumentacja 7.0 wskazuje wymaganie PHP 7.4 lub wyżej, więc starszy hosting trzeba sprawdzić przed kliknięciem aktualizacji.

Czy dane klientów mogą trafić do dostawcy AI?
Tak, jeśli konkretna funkcja wyśle je w prompcie do skonfigurowanego providera. Dlatego asystent klienta powinien zaczynać od odczytu publicznych danych produktowych, a dostęp do zamówień, notatek i danych osobowych powinien być ograniczony, logowany i opisany w polityce prywatności.

Od czego zacząć po instalacji Armstronga?
Od audytu kluczy API. Znajdź stare wtyczki AI, usuń nieużywane sekrety, ustaw jeden kontrolowany connector, włącz prosty workflow niskiego ryzyka — na przykład generowanie alt textów albo excerptów — i dopiero po sprawdzeniu kosztów oraz jakości przejdź do opisów produktów lub automatyzacji WooCommerce.