Uwaga na początku: w momencie pisania (kwiecień 2026) WordPress 7.0 jest na publicznej mapie drogowej, ale jeszcze nie został wydany. Konkretne listy funkcji, zmiany schematu i terminy migracji krążące w sieci, w tym we wpisach reklamujących się jako "kompletny przewodnik", są po części prognozą, po części listą życzeń. Traktuj wszystko, co brzmi definitywnie na temat 7.0, jako spekulację, dopóki nie pojawi się w release candidate opublikowanym na oficjalnym blogu Make WordPress i oznaczonym w core trac.
To, co wiemy z publicznych wpisów Make WordPress: prace Fazy 3 nad edytowaniem zespołowym są w toku, głębsza integracja między edytorem bloków a dostawcami AI jest omawiana na spotkaniach core, a model szablonów Site Editor jest doprecyzowywany. Czego jeszcze nie wiemy: które funkcje AI (jeśli w ogóle) trafią do core, a które zostaną wtyczkami, jakie będzie finalne minimum PHP, ani dokładna data wydania.
Jeśli planujesz pracę, która będzie pokrywać się z cyklem 7.0, uczciwym ruchem jest śledzenie make.wordpress.org/core i biletów core trac bezpośrednio, zamiast polegać na prognozach firm trzecich. Polska społeczność WordPress, w tym organizatorzy WordCamp Polska, śledzi te same kanały. Ten wpis jest jedną z takich prognoz firm trzecich; czytaj go z tą świadomością.
Dowiedz się więcej o profesjonalnym tworzeniu stron WordPress w WPPoland.
Co naprawdę wiadomo o 7.0 w tej chwili
Po odjęciu marketingowej oprawki obraz jest węższy niż sugerują wpisy “kompletny przewodnik”.
Potwierdzone w publicznej dyskusji Make WordPress:
- Faza 3 mapy drogowej Gutenberga jest motywem przewodnim, a współpraca i redakcyjny przepływ pracy to dwa obszary, w których pojawiło się najwięcej publicznych propozycji i PR-ów.
- Integracja AI jest prototypowana we wtyczce Gutenberg i omawiana na spotkaniach core, ale granica między “trafia do core” a “zostaje wtyczką” jest nieustalona.
- Site Editor i system wzorców są iterowane, a doprecyzowania edycji szablonów i blokad bloków trafiają najpierw do wydań punktowych 6.x.
Niepotwierdzone, mimo częstych twierdzeń:
- Konkretna data wydania 7.0. Harmonogramy wydań się przesuwają; traktuj każdą pojedynczą datę jako cel, nie zobowiązanie.
- Definitywna lista funkcji AI w core. Istnieje kilka propozycji, w tym abilities niezależne od dostawcy i UI connectors, ale propozycje to nie wydania.
- Podniesienie minimalnego PHP i dokładne deprecje. Te decyzje zapadają późno w cyklu.
Dla agencji i zespołów produktowych pracujących w 2026 roku praktyczny wniosek jest prostszy niż jakakolwiek lista funkcji: budujcie na WordPress 6.x z użyciem zgodnych z przyszłą wersją wzorców (block themes, theme.json, REST API, Action Scheduler do zadań w tle), tak aby cokolwiek 7.0 ostatecznie dostarczy, migracja była przyrostowa, a nie przepisaniem od zera.
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 wersje 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 wersje 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ń.
