Mapa drogowa WordPress 7.1

#Wprowadzenie

19 czerwca 2026 Anne McCarthy z Automattic opublikowała mapę drogową WordPress 7.1 na blogu Make WordPress Core, w swoim pierwszym cyklu jako liderka wydania. Jej ujęcie na LinkedIn było charakterystycznie ciepłe: “I am so excited about what’s taking shape” (jestem bardzo podekscytowana tym, co się kształtuje). Mapa drogowa jest naprawdę napakowana, a słowem przewodnim jest współpraca, ustawiona jako motyw spinający całe wydanie.

Warto od razu nazwać pewne napięcie. Wydanie reklamowano hasłem współpracy, ale jej flagowa funkcja, czyli współpraca w czasie rzeczywistym, to ta jedna rzecz, która wciąż jest odkładana. Została wycofana z WordPress 7.0 mniej więcej dwa tygodnie przed tamtym wydaniem. Wracała w mapie drogowej 7.1 owinięta w “big, open strategy questions” (duże, otwarte pytania strategiczne) zamiast daty wydania. A na WordCamp Europe 2026 komitenci rdzenia otwarcie kwestionowali, czy ta funkcja w ogóle należy do rdzenia. Uczciwe odczytanie 7.1 to więc dwa wydania w jednym: solidny zestaw usprawnień stylów, mediów i platformy, który faktycznie wszedł 19 sierpnia, oraz historia współpracy, o którą wciąż się otwarcie spiera.

Aktualizacja, 20 sierpnia 2026: WordPress 7.1 Mary Lou ukazał się 19 sierpnia, w terminie. Z wydania wypadły przejście z React 18 na React 19, e-mail w Unicode, Guidelines / wp_knowledge, współpraca w czasie rzeczywistym oraz wygaszanie bloku klasycznego. Weszły responsywne style, media po stronie klienta, trwały pasek administratora, edytor wpisów zawsze w iframe, Playlist i Tabs oraz bogatsze Notes. Notatka z 28 lipca o Becie 3 nadal opisuje dwa punkty, które odpadły jako pierwsze.

#W skrócie

• Anne McCarthy prowadziła 7.1 po raz pierwszy. WordPress 7.1 Mary Lou ukazał się 19 sierpnia 2026, w dniu zamknięcia WordCamp US w Phoenix.
• Wydanie było zbudowane wokół współpracy, ale współpraca w czasie rzeczywistym (RTC) została znów przesunięta po wycięciu z 7.0.
• Co realnie weszło: responsywne style, media po stronie klienta, trwały pasek administratora, edytor wpisów zawsze w iframe, Playlist i Tabs. Guidelines i wycofanie bloku klasycznego nie weszły. React 19 wypadł poza 7.1.
• Obsługa adresów e-mail w Unicode została wycofana z wydania decyzją Matta Mullenwega, ze względów bezpieczeństwa, sześć tygodni po tym, jak trafiła do rdzenia.
• Komitenci rdzenia zaproponowali model wdrożeń canary w stylu Chrome, co jest sygnałem, że ich zdaniem sam proces testowania i zbierania opinii wymaga przemyślenia.
• Krótkie okno stabilizacji zrobiło to, co zwykle: czerwcowa lista była zamiarem. Paczka z 19 sierpnia jest dostawą.

#Co faktycznie weszło, według tego, kogo dotyczy

Mapa drogowa wymienia bardzo wiele. Dla właściciela witryny lub agencji użytecznym pytaniem nie jest “co jest na liście”, lecz “co zmienia moją pracę”. Oto podział.

Wzorzec jest jasny. Pozycje, które weszły, są infrastrukturalne albo skierowane do twórców. Historia współpracy, ta, od której wydanie wzięło nazwę, skończyła w paśmie od średniej do niskiej i poza zipem.

Środek tej tabeli domknął Gutenberg 23.6, ostatnie wydanie funkcjonalne przed 7.1. Podnosi bloki Playlist i Tabs z eksperymentalnych do stabilnych, dodaje notatki przy zaznaczeniu tekstu z autouzupełnianiem @wzmianek, wariant Dynamic Gallery pokazujący wszystkie media dołączone do wpisu, API rejestracji ikon dla wtyczek i motywów oraz konfigurowalne szerokości viewportu w theme.json, czyli responsywne style, które przestają być zabetonowane w trzech punktach przełamania wybranych przez kogoś innego.

#Responsywne style: cichy bohater

Jeśli budujesz witryny dla klientów, najużyteczniejszą rzeczą w 7.1 nie jest współpraca, lecz responsywne style. Do tej pory kontrola nad tym, jak blok wygląda na różnych rozmiarach ekranu, oznaczała własny CSS, wtyczkę albo walkę z edytorem. 7.1 wstawia stylowanie bloku per punkt przełamania bezpośrednio do edytora, obok stylów stanów interaktywnych dla hover, focus i active. Autorzy motywów ustawiają własne punkty przełamania w theme.json. Beta 4 dodała wyłączenie po skargach na UX, więc nikt nie jest zmuszony z tego korzystać.

To mało efektowne i ważniejsze niż większość bardziej błyskotliwych pozycji. Kontrola responsywności to codzienny punkt tarcia w realnej pracy z klientem, a przeniesienie jej do rdzenia zmniejsza liczbę wtyczek i własnego CSS, które inaczej każda witryna nawarstwia. To rodzaj dojrzałości platformy, który nie trafia na nagłówki, ale po cichu likwiduje całą kategorię zgłoszeń do pomocy technicznej.

#React 19 wypada, blok klasyczny zostaje: pod maską

Dwie pozycje z mapy drogowej są niewidoczne dla użytkowników końcowych i ważne dla deweloperów. Jedna z nich wypadła z wydania. Aktualizacja edytora z React 18 na React 19 nie weszła do 7.1: problemy ze zgodnością wtyczek okazały się trudniejsze, niż zakładano, a sponsorowany przez Automattic kontrybutor Jarda Snajdr stwierdził, że aktualizacja wymaga „znacznego okresu testów”, zanim będzie mogła trafić do wydania.

To decyzja słuszna i niewygodna zarazem. React 19 był jedną z niewielu pozycji tej mapy drogowej z wysoką pewnością, a jednocześnie tą, która najłatwiej mogła połamać kod firm trzecich. Przesunięcie zrobiło z 7.1 wydanie mniejsze, niż zapowiadała mapa drogowa, i przerzuciło pracę nad zgodnością na następny cykl. Dla deweloperów praktyczny skutek to odroczenie, a nie odwołanie: aktualizacja wciąż nadejdzie, więc testowanie własnych bloków i interfejsów edytora pod kątem React 19 we wtyczce Gutenberg nadal ma sens, tyle że bez sierpniowego terminu nad głową.

Blok klasyczny to ciekawszy przypadek, bo plan zmienił się w połowie cyklu. Pierwotnie miał zostać ukryty z insertera bloków w 7.1 i stopniowo wygaszany, bo ciągnie za sobą TinyMCE, ciężki edytor. Reakcja społeczności była natychmiastowa: niektórzy, jak Seth Rubenstein (Pew Research Center), skwitowali to lakonicznym „dobrze”, inni doświadczeni blogerzy, jak Jeff Chandler, widzieli nadciągające zamieszanie: „O rany. Nie spodziewałem się tego. Wiem, jakie to wywoła skutki”.

Aktualizacja: ten plan ukrycia z insertera został wycofany. Blok klasyczny pozostaje w 7.1 w inserterze dokładnie tak jak w 7.0, a dyrektor inżynierii w Automattic Marin Atanasov zauważył, że pierwotne podejście „stawiało sprawę w dużej mierze na głowie”, a wypychanie użytkowników bez lepszej alternatywy tylko pogarsza doświadczenie bez żadnego realnego zysku. Wątek wydajnościowy nadal obowiązuje, bo leniwe ładowanie TinyMCE ze stron, które nigdy go nie używają, to realny zysk dla sklepów WooCommerce, gdzie mierzy się każdy kilobajt wagi edytora, ale zegar migracji, który niektórzy już uruchomili, nigdy nie wystartował. Jeśli utrzymujesz treści w bloku klasycznym, w 7.1 nic cię do niczego nie zmusza.

Aktualizacja: z 7.1 wypadła też obsługa adresów e-mail w Unicode. Trafiła do rdzenia sześć tygodni wcześniej, po jedenastu latach prac, a Matt Mullenweg zdecydował o jej wycofaniu ze względów bezpieczeństwa. Jedenaście lat do scalenia i sześć tygodni do odwrotu to bolesny wynik dla zaangażowanych kontrybutorów, a czytać to warto obok debaty o canary poniżej: zmiana, która przechodzi przegląd, zostaje scalona, a potem późno wypada na ocenę bezpieczeństwa, to dokładnie ta awaria pętli informacji zwrotnej, którą komitenci próbują nazwać. Jeśli liczyłeś na adresy e-mail spoza ASCII w 7.1, planuj na dotychczasowym zachowaniu.

Dwie zmiany istotne dla deweloperów pojawiły się jako propozycje merge już po mapie drogowej i warto je śledzić. Theming systemu projektowego wprowadza rejestrowany w rdzeniu arkusz wp-theme oraz reactowy ThemeProvider, czyli podwaliny pod długo obiecywany redesign panelu administracyjnego, a pierwszym widocznym efektem są schematy kolorów użytkownika w edytorze witryny. Z kolei Abilities API dostało trzy proponowane zdolności tylko do odczytu (core/read-settings, core/read-content, core/read-users), które pozwalają agentom i narzędziom AI odczytywać podstawowe dane witryny za sprawdzeniem uprawnień, choć jeden z opiekunów Abilities już zgłosił, że nie są gotowe do rdzenia. Oba to rodzaj instalacji hydraulicznej, która decyduje, czy historia AI i panelu administracyjnego trafi czysto, czy ześlizgnie się do 7.2.

#Guidelines i AI: zakład na proces pracy

Wyróżnikiem jest Guidelines, funkcja, która pozwala witrynie zdefiniować reguły redakcyjne i głos marki w jednym miejscu, co następnie zasila narzędzia AI w edytorze, tak aby generowana treść trzymała się tych reguł. Jest też iteracja AI Client dodająca strumieniowanie generacji i osadzenia (embeddings) oraz iteracja Connectors, która wynosi uwierzytelnianie poza zwykłe klucze API.

Funkcja ta nabrała realnego kształtu, gdy sponsorowany przez Automattic komitent rdzenia Greg Ziółkowski opublikował formalną propozycję wdrożenia nowego typu wpisów wp_knowledge oraz Guidelines do rdzenia. Propozycja ta wywołała jednak skrajne emocje:

• George Stephanis (Bethink Studios) przyjął ją entuzjastycznie, zauważając, że rozwiązuje ona problemy z wytycznymi redakcyjnymi, z którymi wtyczki zmagały się od lat.
• Aaron Jorbin (niezależny komitent) ocenił fundamenty jako dobre, ale uznał obecną implementację za niepełną.
• Jon Brown (9seeds) stwierdził dosadnie, że funkcja powinna najpierw rozwijać się jako wtyczka przez rok lub dwa, a „potem być może i tak nigdy nie trafić do rdzenia”.
• W raporcie Search Engine Journal oraz dyskusjach deweloperskich przewijał się sceptycyzm, wskazujący, że funkcja ta jest oderwana od rzeczywistych potrzeb użytkowników.

To właściwy kształt AI w systemie CMS. Ryzykiem przy asyście AI w pisaniu jest jednorodna treść poza głosem marki, czyli dokładnie ten problem ze slopem, z którym zmaga się dziś każdy zespół treści. Warstwa Guidelines, która ogranicza generację do standardów witryny, jest zabezpieczeniem przed tym. Nie weszła. Matt Mullenweg zawetował scalenie w lipcu, mówiąc, że funkcje AI potrzebują realnego przyjęcia i imponującego tygodniowego wzrostu, zanim trafią do rdzenia. Eksperyment zostaje w Gutenbergu i w Automattic. Traktuj to jako propozycję, nie jako możliwość 7.1. Debatę o scaleniu opisaliśmy w tekście WordPress 7.1: wytyczne AI i własny typ wpisu wp_knowledge.

#Saga RTC i dlaczego wciąż utyka

Współpraca w czasie rzeczywistym to funkcja, którą WordPress wciąż prawie wydaje. Została wycięta z 7.0 na dwa tygodnie przed premierą. W mapie drogowej 7.1 McCarthy ujmowała ją uczciwie, z wciąż otwartymi “big, open strategy questions” (dużymi, otwartymi pytaniami strategicznymi): co właściwie wydać i jakiego mechanizmu przechowywania użyć. Szczegóły tej drugiej próby omówiliśmy w tekście o współpracy w czasie rzeczywistym w WordPress 7.1, a mapa drogowa nie tyle rozstrzygała poruszone tam pytania, ile je powtarzała.

Bardziej odkrywczy zwrot przyszedł od komitentów rdzenia. Na ich spotkaniu podczas WordCamp Europe 2026 pojawiła się “strong opinion, loosely held” (mocna opinia trzymana luźno), że pełny zestaw funkcji RTC nie powinien w ogóle znaleźć się w rdzeniu, a jedynie leżąca u podstaw architektura, z bogatą warstwą funkcji zostawioną wtyczkom lub hostingom. Ten podział utrzymał się w tym cyklu. 7.1 nie dostarczyło ani podwalin, ani widocznej funkcji. Współpraca jako motyw przewodni została aspiracją. 7.2 jest obecnie planowane na 9 grudnia 2026. Nie sprzedawaj klientowi edycji wielu osób na żywo także na tę datę, dopóki field guide nie powie, że to weszło.

#Debata o canary: problem procesu w przebraniu

Najciekawszą rzeczą, jaką komitenci omawiali na WordCamp Europe, nie była wcale funkcja. Zaproponowali przejście WordPressa na model wdrożeń canary w stylu Chrome z flagami funkcji, fundamentalnie inny sposób budowania, testowania i wydawania rdzenia. Sama grupa przyznała, że jest to prawdopodobnie “a technical solution to a communications problem” (techniczne rozwiązanie problemu komunikacyjnego), i postawiła oczywiste pytania, na przykład czym builds canary różniłyby się od tego, co już oferuje wtyczka Gutenberg, i czy wtyczka Gutenberg w ogóle powinna nadal istnieć.

To jeszcze daleka droga. Ale fakt, że komitenci to poruszyli, mówi coś o tym, gdzie ich zdaniem obecny model zawodzi, zwłaszcza wokół testowania i opinii. Powtarzające się falstarty RTC to objaw: dotarcie dużej funkcji na dwa tygodnie przed wydaniem, zanim zostanie wycofana, to awaria pętli informacji zwrotnej, a nie tylko funkcja, która nie była gotowa. Pomysł canary to próba wyłapania tego wcześniej. Niezależnie od tego, czy się przyjmie, sam fakt, że jest na stole, to najuczciwsze przyznanie w całym cyklu, że prawdziwym ograniczeniem jest proces budowania, a nie lista zaległych funkcji.

#Problem z harmonogramem

Oto twarda liczba. Beta 1 była 15 lipca, wydanie 19 sierpnia, a Beta 3 niosła 71 poprawek. To niespełna cztery tygodnie na zamknięcie tak dużej mapy drogowej. McCarthy odziedziczyła ambitną listę i krótki rozbieg, a realnym wynikiem od początku było to, że część pozycji wejdzie, część przesunie się do 7.2, a część przyjdzie za flagami funkcji w stanie częściowym. To nie zarzut wobec liderki wydania, lecz strukturalna rzeczywistość stałej daty wyznaczonej tak, by zbiegła się z WordCamp US. React 19 i adresy e-mail w Unicode odpadły jeszcze przed Betą 3. Guidelines, RTC i wygaszanie bloku klasycznego odpadły wokół niej. Paczka, która weszła, to krótsza lista.

Dla właścicieli witryn praktyczny wniosek się nie zmienił: traktuj opublikowaną mapę drogową jako zamiar, a nie gwarancję. Planuj wokół tego, co realnie weszło, czyli responsywnych stylów, mediów po stronie klienta, Playlist i Tabs oraz edytora w iframe. Nie obiecuj klientowi funkcji, która sześć tygodni przed wydaniem wciąż niosła “duże, otwarte pytania strategiczne”, i nie zakładaj, że scalona funkcja to funkcja wydana. E-mail w Unicode został scalony, a potem wycofany. To ta sama lekcja.

#24-godzinne opóźnienie aktualizacji: bezpieczeństwo vs. prędkość

Równolegle do prac nad rdzeniem, zespół ds. wtyczek WordPress.org wprowadził znaczącą zmianę w infrastrukturze: 24-godzinne opóźnienie (cooldown) dla wszystkich aktualizacji wtyczek i motywów. Choć Matt Mullenweg pierwotnie zapowiadał to rozwiązanie w kontekście automatycznych aktualizacji mających zapobiegać atakom na łańcuch dostaw, okazało się, że opóźnienie dotyczy wszystkich metod aktualizacji, w tym ręcznych instalacji z kokpitu.

Wywołało to silny opór ze strony deweloperów i administratorów witryn:

• Miriam Schwab (Elementor) ostrzegła, że opóźnienie tworzy niebezpieczne „okno podatności”. Gdy poprawka bezpieczeństwa zostaje wdrożona, kod łaty staje się publicznie dostępny i boty mogą go analizować, by tworzyć exploity, podczas gdy administratorzy mają zablokowaną możliwość instalacji aktualizacji przez 24 godziny.
• Pavel Ciorici (twórca motywów) zauważył, że wydanie szybkiej poprawki błędów w trakcie trwania cooldownu resetuje licznik czasu, kumulując opóźnienia.
• Steve Burge (PublishPress) przedstawił przeciwny punkt widzenia, chwaląc zmianę za to, że pomogła wykryć drobne problemy bezpieczeństwa już w pierwszym tygodniu działania.
• Francisco Torres (współreprezentant zespołu wtyczek) przyznał, że opór jest odczuwalny, potwierdzając, że zespół zbiera opinie społeczności i planuje wprowadzenie poprawek do tych zasad.

Dla agencji oraz wydajnych stron WordPress, ta zmiana infrastruktury wymusza zmianę podejścia do wdrażania poprawek bezpieczeństwa, podnosząc znaczenie prywatnych repozytoriów oraz wcześniejszego testowania aktualizacji na serwerach testowych.

#Co zrobić teraz

• Deweloperzy: edytor wpisów jest zawsze w iframe. Bloki na API v2 lub niższym potrzebują przejścia na v3. Szczegóły są w nocie o edytorze wpisów w iframe. React 19 nadal nie jest w rdzeniu. Testujcie go we wtyczce Gutenberg.
• Witryny na WP Rocket: błąd typu w module zgodności z Cloudflare wyłącza witryny na 7.1 (wp-media/wp-rocket#8596). Najpierw staging, potem produkcja. Jeśli utrzymujecie sklepy, to jest sprawdzenie wydajności i niezawodności WooCommerce, a nie kosmetyka.
• Witryny legacy: blok klasyczny nadal jest w inserterze. W 7.1 nie ma wymuszonej migracji. Audytujcie go, gdy i tak będziecie ruszać treść, nie dlatego, że to wydanie uruchomiło zegar.
• Zespoły redakcyjne: Guidelines nie weszły. Nie przebudowujcie procesu wokół eksperymentu w Gutenbergu.
• Wszyscy: automatyczne aktualizacje do 7.1 już się toczą. Testujcie na stagingu, zwłaszcza jeśli macie object cache, wtyczkę cache’ującą strony albo własny JavaScript edytora.

#Podsumowanie

WordPress 7.1 Mary Lou to użyteczne wydanie platformy z nieco mylącą nazwą. Ujęcie współpracy było realnym zamiarem. Funkcja współpracy nie weszła, drugi cykl z rzędu. Zdejmij to ujęcie, a 19 sierpnia dostałeś wydanie mniejsze i nadal warte wzięcia: responsywne style, które usuwają codzienne tarcie, media po stronie klienta, które przestają rozbijać się o limit pamięci PHP przy wrzutkach HEIC, Playlist i Tabs jako stabilne bloki, trwały pasek administratora i edytor wpisów zawsze w iframe. Guidelines nie weszły. Wycofanie bloku klasycznego nie weszło. React 19 i e-mail w Unicode zostały poza. Przepaść między czerwcową mapą drogową a sierpniową paczką jest już zmierzona, a nie przewidywana.

Głębszą historią nadal jest debata o canary. Projekt gotowy publicznie zakwestionować własny model wdrożeń to projekt, który wie, że jego pętle sprzężenia zwrotnego są napięte, a ten sam niepokój napędza powracające pytanie, czy WordPress traci na znaczeniu. Obserwuj tę rozmowę, bo będzie kształtować wydania długo po tym. Planuj wokół tego, co weszło. Testuj staging. Traktuj następną mapę drogową tak, jak tę należało traktować od początku: zamiar, dopóki nie ma zipa.

Ostatnia aktualizacja: 20 sierpnia 2026.