Aktualizacja, 23 maja 2026: WordPress 7.0 o kryptonimie Armstrong został wydany. Wydanie zamyka Fazę 3 mapy drogowej Gutenberga fundamentalną infrastrukturą AI (Abilities API + AI Services Registry + AI Client), zmodernizowanym panelem, Command Palette dostępną wszędzie, niestandardowym CSS na poziomie bloku i blokiem Icons. Współpraca w czasie rzeczywistym została wycofana w testach RC i nie wchodzi do 7.0. Ten artykuł to powydaniowe podsumowanie; starsze sekcje mapy drogowej zostały zachowane jako kontekst historyczny, nie jako opis tego, co aktywuje się dziś na instalacji 7.0.
WordPress 7.0 "Armstrong" został wydany w maju 2026 po dłuższym niż zwykle cyklu release candidate. Wydanie zbudowane przez ponad 900 kontrybutorów. Główna zmiana to infrastruktura AI w core: powierzchnia Abilities API do bezpiecznych operacji admina, AI Services Registry dla integracji modeli hostowanych i WordPress AI Client, wokół którego pluginy firm trzecich się standaryzują. Zmodernizowany panel admina, Command Palette dostępna wszędzie w wp-admin, niestandardowy CSS na poziomie bloku i blok Icons również trafiły do wydania. Współpraca w czasie rzeczywistym została wycofana w testach RC i nie jest częścią aktualizacji.
Ostrzejsza polemika o tym, co powierzchnia AI w 7.0 znaczy konkretnie dla autorów pluginów, jest w naszym tekście o tym, dlaczego serwer MCP w twoim pluginie WordPress to ruch AI, który przeżyje. Powydaniowe implikacje bezpieczeństwa są w naszej analizie raportu GuardingWP State of WordPress Security 2026, który stawia nową powierzchnię kluczy AI w kontekście baseline’u 53 procent niezałatanych CVE.
Śledź make.wordpress.org/core i oficjalny kanał wordpress.org/news pod kątem dalszych patchy.
Dowiedz się więcej o profesjonalnym tworzeniu stron WordPress w WPPoland.
Data wydania i kryptonim WordPress 7.0
WordPress 7.0 o kryptonimie Armstrong został wydany w maju 2026 po niespotykanie długim cyklu release candidate (RC4 wszedł 14 maja 2026, finalne wydanie nastąpiło wkrótce po). Nazwa “Armstrong” kontynuuje tradycję nazywania głównych wydań WordPressa od muzyków jazzowych.
Jeśli planujesz aktualizację produkcyjną, najbezpieczniejsze okno to wciąż dwa do czterech tygodni po finalnym wydaniu, kiedy pierwsza runda patchy zbierze problemy kompatybilności zgłoszone przez early adopterów.
Co naprawdę zeszło w 7.0 Armstrong
To potwierdzona lista funkcji z ogłoszenia release wordpress.org, nie wcześniejsza intencja roadmapy. Cokolwiek ze starszej mapy drogowej nie znajduje się tutaj, nie weszło do 7.0.
- Infrastruktura AI w core. Abilities API do bezpiecznych operacji admina przez ustrukturyzowane intencje, AI Services Registry do łączenia hostowanych dostawców modeli (Anthropic, OpenAI, Vercel AI Gateway, self-hosted) i WordPress AI Client, pod który pluginy firm trzecich teraz budują. To zmiana platformowa, która definiuje wydanie.
- Command Palette wszędzie. Cmd-K / Ctrl-K otwiera Command Palette na każdym ekranie wp-admin, nie tylko w edytorze bloków. Powierzchnia skrótów dla power-userów jest teraz pierwszej kategorii.
- Niestandardowy CSS na poziomie bloku. Każdy blok może nieść swój własny CSS, ograniczony do tego bloku. Usuwa długotrwały powód do schodzenia w custom theme.
- Blok Icons. Natywny blok do osadzania ikon SVG z wyselekcjonowanej biblioteki, z motywo-świadomymi tokenami kolorów.
- Zmodernizowany panel. Odświeżone powierzchnie landingowe admina, z eksperymentami agentic-AI widocznymi za feature flagą.
- Minimalne PHP 7.4. Witryny wciąż na starszym PHP muszą zaktualizować środowisko serwera przed aktualizacją do 7.0.
- Ponad 900 kontrybutorów. Product Manager WP Charitable David Bisset publicznie podziękował kontrybutorom i “ich małżonkom, partnerom, rodzinom, zwierzętom, mechanizmom radzenia sobie i doradcom, którzy ich wspierali” - najuczciwsza linia napisana o głównym wydaniu WordPressa od lat.
Co nie weszło i nie jest już oczekiwane na linii 7.0:
- Współpraca w czasie rzeczywistym została wycofana z tego wydania po testach release candidate. Wcześniejszy opis na mapie drogowej poniżej został zachowany jako kontekst historyczny.
Bezpieczeństwo: chroń klucze API dostawców AI od pierwszego dnia
Założyciel Patchstack Oliver Sild napisał publicznie na X w okolicy release: “there will be an absolute rush by hackers to steal API keys.” Ryzyko jest konkretne. Skompromitowany credential wp-admin na instalacji 7.0 nie tylko pozwala atakującemu zmienić treść; pozwala mu też wydrenować 4- albo 5-cyfrowy miesięczny rachunek za tokeny u dostawcy AI zanim faktura to złapie. Justin Nealey osobno sflagował, że WP AI Client nie ma wbudowanego throttle i kilka pluginów dzielących jeden klucz potrafi wydmuchać limit tokenów w niecałą minutę.
Powierzchnia kontroli do zastosowania jest prosta i ta sama, którą zespół finansowy zastosowałby do każdego nowo wybitego rozliczalnego credentiala:
- Zakresuj klucze API per connector, nie per witryna. Jeden klucz na dostawcę na connector. Rotuj na opublikowanym cadensie.
- Zastosuj rate limity na bramie, nie w pluginie. Jeśli twój dostawca wspiera rate limity per-klucz (Anthropic, OpenAI, Vercel AI Gateway wszystkie wspierają), ustaw je nisko na tyle, żeby anomalia w konsumpcji była widoczna wobec jednego cyklu rozliczeniowego.
- Alertuj na anomalia zużycia tokenów wewnątrz cyklu, nie pod koniec miesiąca. Większość dostawców wystawia API rozliczeniowo-dniowe; wepnij to w swój monitoring.
- Loguj użycie connectorów po stronie WordPress. Abilities API udostępnia operation IDs; loguj je w odrębnym strumieniu od zwykłego audit logu wp-admin.
Te mapują się wprost na kontrole łańcucha dostaw już wymagane przez NIS2 artykuł 21 paragraf 2 litera d dla podmiotów w zakresie. Traktuj nową powierzchnię AI jako nową klasę umowy ICT trzeciej strony, zarejestruj odpowiednio - w Polsce również w trybie KSC i CERT Polska.
Co naprawdę wiadomo o 7.0 w tej chwili
Po odjęciu marketingowej oprawki obraz jest węższy niż sugerują wpisy “kompletny przewodnik”.
Potwierdzone dla linii release candidate w maju 2026:
- RC4 i Field Guide dokumentują infrastrukturę Abilities API, zmiany w panelu admina oraz PHP 7.4 jako minimalną obsługiwaną wersję.
- Współpraca w czasie rzeczywistym została wycofana z tego wydania po testach RC. Starsze teksty marketingowe o współpracy to kontekst historyczny roadmapy.
- AI Experiments 1.0 celuje w wydanie wtyczki równolegle z core, z zatwierdzeniem przez admina zanim wtyczki użyją zapisanych poświadczeń AI.
Nadal w ruchu w finalnym tygodniu wydania:
- Które detale UI connectorów AI trafiają do core, a które do wtyczki AI Experiments.
- Późne poprawki kompatybilności wtyczek i motywów wykryte na stagingu.
Dla agencji i zespołów produktowych w 2026: buduj na WordPress 6.x ze wzorcami zgodnymi z przyszłą wersją (block themes, theme.json, REST API, Action Scheduler), aby migracja do 7.0 była przyrostowa.
AI w WordPress dzisiaj, i dokąd może pójść 7.0
Uczciwa wersja “funkcji AI w WordPress 7.0” zaczyna się od tego, co już działa w 6.x, bo to jest to, co rzeczywiście chodzi na produkcyjnych stronach.
Dostępne dzisiaj, w produkcyjnym WordPress:
- Yoast i Rank Math (w tym polskie wersję językowe) oferują asystenty pisania wspomagane AI: tytuły, meta opisy, sugestie linkowania wewnętrznego, zbudowane na API modeli firm trzecich.
- Jetpack AI Assistant oferuje generowanie w edytorze, podsumowania i tłumaczenie. Jakość różni się w zależności od języka i prompta; jakość po polsku poprawia się, ale wymaga przeglądu.
- Samodzielne wtyczki generujące treść istnieją w szerokim zakresie jakości; przydatne do szkiców, niebezpieczne, gdy wpięte bezpośrednio w publikację bez przeglądu człowieka.
- Automattic i zespoły kontrybutorów prowadzą eksperymenty Fazy 3, w tym współpracę w czasie rzeczywistym i wywołania AI po stronie edytora, we wtyczce Gutenberg, przed jakimkolwiek scaleniem do core.
Pragmatyczna architektura dodawania AI do witryny WordPress dzisiaj, która prawdopodobnie przeżyje cokolwiek dostarczy 7.0:
- Wystaw mały endpoint REST API na dostawcę (OpenAI, Anthropic, Google albo model self-hosted). Trzymaj kod specyficzny dla dostawcy za jednym interfejsem, by wymiana modelu była zmianą konfiguracji, a nie przepisaniem.
- Wszystko wolniejsze niż kilka sekund kieruj przez Action Scheduler, nie przez synchroniczne żądanie. To ten sam wzorzec, którego używa WooCommerce; skaluje się.
- Klucze API trzymaj jako stałe w
wp-config.phpalbo przez zarządzane miejsce na sekrety ładowane przy starcie. Nigdy nie umieszczaj żywych kluczy w opcjach wtyczek ani plikach.envzacommitowanych do repo. - Cache’uj odpowiedzi po hashu prompta plus wersji modelu. Wywołania AI są drogie i często powtarzane.
Tryby awaryjne, na które warto się przygotować od pierwszego dnia:
- Wyciek klucza API przez auto-aktualizacje wtyczek lub backupy obejmujące
wp-content. - Błędy rate-limit podczas skoku ruchu, które po cichu degradują doświadczenie edytora, jeśli nie ma fallbacku.
- Halucynowane fakty, cytowania lub specyfikacje produktów opublikowane bez kroku przeglądu człowieka. Koszt jednej złej strony w wynikach wyszukiwania jest wyższy niż koszt dowolnego workflow przeglądu.
Jeśli 7.0 wprowadzi warstwę abilities lub connectors w core, te same granice mają zastosowanie: powierzchnia API się zmienia, tryby awaryjne nie. W kwestii etyki i ramowania redakcyjnego zobacz przewodnik po etyce treści AI dla wydawców.
Jak przygotować się bez zgadywania migracji
Pisanie krokowego “jak migrować do 7.0” przewodnika zanim 7.0 się ukaże jest nieuczciwe. Komendy specyficzne dla wersji, procedura aktualizacji bazy danych, nowe ustawienia admina: nic z tego nie jest finalne. Każdy, kto publikuje dzisiaj dokładne kroki migracji, wypełnia luki domysłami.
To, co można zrobić teraz, to zmniejszyć przyszły koszt migracji niezależnie od tego, jak będzie wyglądać 7.0. Praca jest niewdzięczna i spłaca się przy każdym wydaniu, nie tylko tym.
Zaudytuj części stacku najbardziej narażone na złamanie przy dużej aktualizacji:
- Motywy nadal używające template tagów w
functions.phpzamiast block themes. Skonwertuj na block themes albo zaplanuj prace. - Niestandardowe bloki Gutenberg zbudowane przeciwko wczesnym wersjom
@wordpress/scripts. Przypnij wersję i przetestuj względem najnowszej stabilnej. - Page buildery z własną warstwą renderowania. To najczęstsza przyczyna długu “nie możemy zaktualizować”.
- Niestandardowe endpointy REST bez wersjonowania. Dodaj namespace
/v1/teraz, by przyszłe podniesienie było nieprzerywające.
Skonfiguruj nudną infrastrukturę, która pozwoli szybko zaktualizować, gdy 7.0 się ukaże:
- Środowisko staging odzwierciedlające produkcyjną wersję PHP, zestaw wtyczek i wolumen treści. Parytet bazy danych ma większe znaczenie, niż się ludziom wydaje.
- Automatyczne backupy z przetestowaną ścieżką odtworzenia. Nieprzetestowany backup to teatr.
- Aktualizacje wtyczek i motywów w regularnym tempie, nie odkładane do następnej dużej. Strony utknięte na 6.0 są utknięte, bo nikt nie aktualizował 6.1 do 6.8.
- Krótka lista autorów wtyczek, którym ufasz, z kontaktami mailowymi. Gdy 7.0 się ukaże, będziesz chciał wiedzieć w ciągu tygodnia, które z twoich wtyczek są testowane względem niej.
Gdy 7.0 faktycznie osiągnie RC w oficjalnym kalendarzu wydań, ścieżka aktualizacji jest ta sama, która działa dla każdego dużego wydania WordPress: uruchom najpierw na staging, obserwuj log błędów, odczekaj dwa do czterech tygodni po ogólnej dostępności zanim dotkniesz produkcji dla stron klienckich, i przeczytaj oficjalny field guide na Make WordPress zanim założysz, że jakikolwiek przewodnik firm trzecich (w tym ten) odzwierciedla to, co się faktycznie ukazało.
Co robić do momentu wydania 7.0
Dopóki WordPress 7.0 nie osiągnie tagowanego wydania na wordpress.org, najużyteczniejsze, co każdy zespół może zrobić, to ignorowanie wpisów prognostycznych (w tym tego) i obserwowanie źródeł pierwotnych: bloga Make WordPress core, notek wydaniowych Gutenberga i kamienia milowego trac dla 7.0.
Dla istniejącego projektu pracującego w 2026 roku buduj na obecnym wydaniu 6.x z użyciem block themes, theme.json i REST API. Traktuj AI jako warstwę integracji za swoimi własnymi endpointami, nie jako funkcję, na którą czekasz, aż dostarczy core. Gdy 7.0 wyląduje, migracja staje się pytaniem, które z twoich niestandardowych integracji mogą zostać zastąpione przez API core, a nie przepisaniem.
Jeśli chcesz pomocy w audycie stacku pod kątem gotowości do aktualizacji, nasz zespół developerów WordPress wykonuje te prace dla produkcyjnych stron przy każdym cyklu wydań.
