Gutenberg 24.2 i React 19: co sprawdzić we własnych blokach

Aktualizacja, 3 listopada 2026. Gutenberg 24.3 jest już dostępny (wtyczka z datą 28 października; wpis What’s new z 2 listopada). Zmiany redakcyjne ważne na żywym serwisie: formatowanie tekstu w zaznaczeniu obejmującym kilka bloków, reakcje emoji przy notatkach (serce, impreza, oczy i kilka innych), Media inserter przebudowany na siatce DataViews z podglądami plików innych niż obrazki oraz komunikaty o nieudanym zapisie/autosave ze szczegółami, statusem HTTP gdy jest, kopiowaniem i odliczaniem do kolejnej próby. Wydanie zawiera też poprawki bezpieczeństwa z WordPressa 7.1.4, więc zaktualizuj wtyczkę Gutenberg, jeśli masz ją na produkcji. React 19 nadal jest domyślnie włączony jak w 24.2; checklista testów poniżej nadal obowiązuje.

Gutenberg 24.2 wyszedł 14 października 2026. Dla redakcji przynosi notatki w marginesie edytora, jedno wyszukiwanie linków w menu i sortowanie galerii. Dla autorów wtyczek i motywów ważniejsza jest jedna zmiana: wtyczka Gutenberg ładuje teraz domyślnie React 19 zamiast Reacta 18. Kto ma na stronie własne bloki albo strony ustawień napisane w React, powinien je teraz sprawdzić, zanim React 19 trafi do samego WordPressa.

Ten tekst opiera się na oficjalnym wpisie o wydaniu 24.2, liście zmian w repozytorium Gutenberga, dwóch wpisach Make WordPress Core o React 19 i przewodniku migracji React 19.

#Co nowego w Gutenbergu 24.2?

Wydanie ma pięć głównych zmian:

• notatki przeniesione do marginesu obok treści,
• jedno wyszukiwanie dla wszystkich rodzajów linków w bloku nawigacji,
• sortowanie i wspólny filtr duotone w bloku galerii,
• kolejne bloki z tymi samymi narzędziami projektowymi (około 80 zmian w kodzie),
• React 19 włączony domyślnie i dwa dodatki w Interactivity API.

Do tego ponad 60 poprawek błędów oraz zmiany w dostępności i wydajności. Kilka mniejszych zmian ma znaczenie w codziennej pracy. Suwak liczby kolumn w bloku kolumn zniknął: kolumnę dodaje się przyciskiem plus obok przycisku bloku na pasku narzędzi, a usuwa jak każdy inny blok. Po przycięciu obrazka edytor obrazów pozwala wrócić do oryginału bez wchodzenia do biblioteki mediów. Pole autora wpisu zawsze ma wyszukiwanie i szuka użytkowników po stronie serwera, więc na stronach z wieloma kontami właściwa osoba pojawia się na liście.

Gutenberg 24.2 poprawia też adresy nowych wpisów. Do tej pory nowy wpis mógł zostać opublikowany z adresem auto-draft, jeśli ktoś przed publikacją kliknął w pole przyjaznego adresu (slug). W 24.2 to już się nie zdarza. Jeśli na stronie z wtyczką Gutenberg widzieliście wpisy z takim adresem, to była przyczyna.

Panele dodawane przez wtyczki przeniosły się w menu opcji edytora do podmenu paneli, obok nowych podmenu wyglądu i notatek. Przypięte przyciski tych paneli na pasku narzędzi zostają tam, gdzie były. Autorzy wtyczek z własnym panelem bocznym powinni sprawdzić, czy instrukcje dla użytkowników nadal opisują właściwe miejsce.

#Czy React 19 jest już w WordPressie?

Nie. WordPress 7.1 działa na React 18.3. W lipcu 2026 Jarda Snajdr opisał na Make WordPress Core, dlaczego przejście na React 19 wypadło z 7.1: po krótkim włączeniu we wtyczce Gutenberg wyszły nieoczekiwane niezgodności między starą i nową wersją Reacta oraz w sposobie, w jaki wtyczki z Reacta korzystają, i zmianę trzeba było wycofać.

„Potrzebny będzie dłuższy okres testów, w którym poprawimy i dopracujemy warstwę zgodności, dzięki której istniejące wtyczki będą działać bez problemów.”

Źródło: Jarda Snajdr, Make WordPress Core, 24 lipca 2026, tłumaczenie własne

Od wersji 23.4 wtyczka Gutenberg miała eksperyment React 19, który trzeba było włączyć ręcznie. Gutenberg 24.2 odwraca to ustawienie: eksperyment jest domyślnie włączony. Sam WordPress, bez wtyczki Gutenberg, nadal ładuje React 18.3.

Plan wydania WordPress 7.2 zakłada premierę na początku grudnia 2026. O React 19 mówi, że typy, zależności i poprawki renderowania w Gutenbergu są w większości gotowe, ale pełne przejście w 7.2 jest mało prawdopodobne. Dla zespołów utrzymujących strony oznacza to, że React 19 we wtyczce Gutenberg jest teraz okresem testów, a nie datą wdrożenia w WordPressie. Tło decyzji z lata opisuję w tekście o planie WordPress 7.1.

#Kiedy Gutenberg 24.2 zostawia stronę na React 18?

Według wpisu o wydaniu strony z wtyczką ładują React 19 dla skryptów react i react-dom, chyba że aktywny jest motyw albo wtyczka znana z problemów ze zgodnością. Wtedy strona zostaje na React 18. Listę takich motywów i wtyczek zaczęto od problemów zaobserwowanych na WordPress.com i rozszerzono w tym wydaniu (zmiana #84607).

Z tego wynikają dwie praktyczne rzeczy. Po pierwsze, ta sama wersja Gutenberga może na dwóch stronach ładować różne wersje Reacta, zależnie od zestawu wtyczek. Testując blok, sprawdzajcie, którą wersję faktycznie dostał edytor. W konsoli przeglądarki na ekranie edytora wystarczy wpisać React.version, bo WordPress udostępnia React jako zmienną globalną. Po drugie, brak problemów na stronie, która trafiła na listę wyjątków, niczego nie dowodzi. Blok był wtedy testowany na React 18.

Lista wyjątków to rozwiązanie przejściowe. Jeśli Wasza wtyczka jest na niej, problem wróci w dniu, w którym React 19 wejdzie do WordPressa.

#Jak wyłączyć React 19 w Gutenbergu?

Zespół Gutenberga pisze wprost, co zrobić, gdy coś przestanie działać:

„Jeśli utrzymujesz wtyczkę albo motyw, który używa Reacta, przetestuj go z Gutenbergiem 24.2 i zgłoś każdy problem, który znajdziesz. Jeśli coś przestanie działać na stronie, wyłącz React 19 w Gutenberg > Experiments.”

Źródło: What’s new in Gutenberg 24.2, Make WordPress Core, 14 października 2026, tłumaczenie własne

W panelu WordPressa to menu Gutenberg, strona eksperymentów, pole wyboru przy React 19. Lipcowy wpis o eksperymencie opisywał tę samą stronę jako dostępną w ustawieniach Gutenberga. Wyłączenie działa dla całej strony, więc to rozwiązanie awaryjne dla produkcji, a nie sposób na naprawę bloku. Blok, który działa tylko po wyłączeniu React 19, trzeba poprawić przed wydaniem WordPressa z React 19.

Druga możliwość to nieinstalowanie wtyczki Gutenberg na produkcji. Strona bez tej wtyczki dostaje React z WordPressa, czyli dziś 18.3. Wtyczkę Gutenberg instaluje się na produkcji wtedy, gdy klient potrzebuje funkcji, których jeszcze nie ma w WordPressie. Jeśli jej nie potrzebuje, React 19 testujcie na kopii strony.

#Które API usunął React 19 i co to psuje w blokach WordPress?

Lipcowy wpis na Make WordPress Core wymienia dwa typowe źródła awarii wtyczek. Drugie z nich to stare funkcje Reacta, przestarzałe od co najmniej sześciu lat i usunięte w React 19. Część z nich warstwa zgodności w Gutenbergu uzupełnia, ale nie wszystkie. Przewodnik migracji React 19 podaje pełną listę wraz z datą, od której każde API było przestarzałe:

Komponenty klasowe zachowują defaultProps, bo dla klas nie ma odpowiednika w składni ES6. Usunięto też react-dom/test-utils i react-test-renderer/shallow, co dotyczy testów jednostkowych, a nie samego bloku.

W kodzie WordPressa najczęściej trafia się render montujący stronę ustawień albo widżet panelu administracyjnego. Starsze wtyczki importują go z @wordpress/element, który pod spodem wywołuje ReactDOM.render. Nowsze wersje tego pakietu eksportują createRoot i to jego trzeba użyć:

import { createRoot } from '@wordpress/element';

const container = document.getElementById( 'my-plugin-settings' );
if ( container ) {
	createRoot( container ).render( <SettingsPage /> );
}

Drugi częsty przypadek to defaultProps przy komponencie funkcyjnym w edytorze bloku. W React 19 domyślne wartości po prostu nie są ustawiane, więc komponent dostaje undefined i zwykle nie rzuca błędu, tylko wyświetla pusty panel albo źle liczy wartość. Taki błąd łatwo przeoczyć, bo konsola milczy.

Przewodnik podaje gotowy zestaw automatycznych poprawek: npx codemod@latest react/19/migration-recipe. Uruchamiajcie go na osobnej gałęzi i czytajcie każdą zmianę, bo nie zna specyfiki pakietów @wordpress/*.

React 18.3, na którym działa WordPress 7.1, według zespołu Reacta jest identyczny z 18.2, ale dodaje ostrzeżenia o przestarzałych API i innych zmianach potrzebnych w React 19. Jeśli w konsoli edytora na zwykłym WordPressie 7.1 widzicie ostrzeżenia z nazwą Waszej wtyczki, to jest gotowa lista rzeczy do poprawy.

#Jak sprawdzić, czy wtyczka dołącza własną kopię Reacta?

Pierwsze źródło awarii z lipcowego wpisu jest częstsze i trudniejsze do zauważenia w kodzie źródłowym, bo widać je dopiero w zbudowanym pliku JavaScript.

„Gdyby wszyscy poprawnie budowali swój JavaScript, większość problemów ze zgodnością w ogóle by nie wystąpiła.”

Źródło: Jarda Snajdr, Make WordPress Core, 24 lipca 2026, tłumaczenie własne

Chodzi o kod react/jsx-runtime dołączony bezpośrednio do pliku wtyczki zamiast skryptu react-jsx-runtime, który dostarcza WordPress. Wtedy na stronie działają obok siebie React 18 z paczki wtyczki i React 19 z WordPressa, a struktury danych utworzone przez starą wersję trafiają do nowej. Komponent wygląda poprawnie w kodzie, a w edytorze nie montuje się albo rzuca błąd o nieprawidłowym elemencie.

Sprawdzenie zajmuje kilka minut na wtyczkę:

1. Otwórzcie plik *.asset.php obok zbudowanego skryptu (na przykład build/index.asset.php). Jeśli kod używa JSX, na liście zależności powinien być react-jsx-runtime.
2. Przeszukajcie zbudowane pliki pod kątem kodu samego Reacta, na przykład grep -l "react.element" build/*.js. Trafienie w pliku wtyczki to sygnał, że część Reacta jest w paczce. To powód do sprawdzenia konfiguracji, nie wyrok.
3. Sprawdźcie, czy konfiguracja budowania nie omija mechanizmu, który zamienia importy react i @wordpress/* na skrypty WordPressa. Najczęściej zdarza się to przy własnym webpacku albo Vite zamiast @wordpress/scripts.
4. Dla wtyczek kupionych od zewnętrznego dostawcy, bez dostępu do źródeł, zostaje test w edytorze z następnej sekcji i zgłoszenie u autora.

Zespół Gutenberga pracuje nad automatycznym wykrywaniem tych problemów we wtyczce Plugin Check. Do czasu, aż to zadziała, sprawdzenie zostaje po stronie autora wtyczki.

#Jak przetestować własne bloki z React 19 na kopii strony?

Lipcowy wpis definiuje test zgodności prosto: użyć wszystkich części wtyczki, które korzystają z Reacta, czyli zwykle bloków, rozszerzeń edytora i własnych stron w panelu administracyjnym, i sprawdzić, że interfejs nie jest zepsuty, a w konsoli przeglądarki nie ma błędów. Na kopii testowej strony robi się to tak:

1. Zróbcie kopię strony z tą samą wersją PHP, WordPressa i wtyczek co produkcja. Jeśli kopia zawiera dane klientów sklepu, zanonimizujcie je przed skopiowaniem.
2. Zainstalujcie Gutenberga w wersji z wydania: wp plugin install gutenberg --version=24.2.0 --activate.
3. W wp-config.php kopii ustawcie define( 'SCRIPT_DEBUG', true );. WordPress ładuje wtedy nieskompresowane wersje skryptów, w tym deweloperską wersję Reacta, która pokazuje pełne ostrzeżenia zamiast skróconych kodów błędów.
4. W edytorze wpiszcie w konsoli React.version i upewnijcie się, że to 19. Jeśli widzicie 18, któraś aktywna wtyczka jest na liście wyjątków i test trzeba powtórzyć bez niej.
5. Wstawcie każdy własny blok do nowego wpisu, zmieńcie każde ustawienie w panelu bloku, zapiszcie, przeładujcie edytor i sprawdźcie, czy blok nie pokazuje komunikatu o nieprawidłowej treści.
6. Otwórzcie każdą stronę ustawień wtyczki i każdy panel boczny, który wtyczka dodaje do edytora. Po 24.2 te panele są w podmenu paneli w menu opcji.
7. Na koniec obejrzyjcie zapisane wpisy na stronie. Bloki dynamiczne renderuje PHP, więc tam React nie ma znaczenia, ale bloki z Interactivity API i skryptami na stronie trzeba przeklikać.

Lista do punktu 5 powinna obejmować bloki, które klient faktycznie używa, a nie tylko te, które są zarejestrowane. Jeśli strona ma bibliotekę kilkudziesięciu bloków, zacznijcie od tych na stronie głównej, karcie produktu i w formularzach. Ogólne zasady pracy na kopii testowej opisuje mój przewodnik po wdrażaniu zmian przez kopię strony, a do szybkiego sprawdzenia jednego bloku na czystej instalacji wystarczy WordPress Playground.

Każdy znaleziony problem zgłaszajcie z numerem wersji Gutenberga, wersją Reacta z konsoli i treścią błędu. Zespół prosi o zgłoszenia w repozytorium Gutenberga na GitHubie, a dla wtyczek zewnętrznych u ich autorów.

#Jak działają notatki na marginesie edytora?

Do tej pory pływające notatki i panel ustawień nie mogły być otwarte jednocześnie, a kolumna notatek zabierała miejsce treści. W 24.2 edytor rezerwuje margines obok obszaru edycji i tam wyświetla notatki, więc zostają widoczne przy zmianie bloków i ustawień wpisu.

Przy węższym oknie każdy wątek zwija się do awatara autora, a kliknięcie awatara rozwija go z powrotem. Nowe podmenu notatek w menu opcji pozwala je rozwinąć, zminimalizować albo ukryć, a edytor zapamiętuje wybór. Trzy zmiany zmniejszają ryzyko utraty pracy: usunięcie notatki można cofnąć, niewysłana notatka albo odpowiedź nie znika po zaznaczeniu innego bloku, a notatki przewijają się razem z treścią.

Dla redakcji, która omawia teksty w edytorze, oznacza to mniej przełączania paneli. Dla autorów bloków jest jeden praktyczny skutek: obszar edycji ma teraz mniej miejsca, gdy notatki są widoczne. Bloki z ustaloną szerokością albo własnym układem w edytorze warto obejrzeć z otwartymi notatkami.

Plan WordPress 7.2 zapowiada kolejne zmiany w notatkach: tryb sugestii, w którym proponowaną zmianę tekstu można przyjąć albo odrzucić, reakcje emoji i osobny przycisk dodawania notatki na pasku narzędzi bloku.

#Co zmieniło się w bloku nawigacji i w galerii?

Dodanie do menu czegoś innego niż strona wymagało wcześniej wiedzy, którego bloku użyć, na przykład linku do kategorii albo linku do tagu, i dopiero w nim wyszukiwania. Teraz wyszukiwarka linków w bloku nawigacji przeszukuje wszystkie rodzaje treści naraz i przy każdym wyniku pokazuje jego typ. Istniejący link można zmienić z kategorii na stronę bez usuwania go i dodawania od nowa. Ta sama wyszukiwarka pokazuje też bloki, które menu przyjmuje, więc wpisanie Home znajduje blok linku do strony głównej.

Wyniki są teraz sortowane według typu: wpisy i strony przed kategoriami, tagami i mediami. Ta kolejność obowiązuje w każdym wyszukiwaniu linków w edytorze, nie tylko w menu. Na dużych stronach tagi i załączniki przestają wypychać szukany wpis z listy wyników. Dla autorów wtyczek, które dodają własne typy treści do wyszukiwarki linków, to powód, żeby sprawdzić, gdzie ich wyniki lądują.

Style globalne mogą teraz stylować stany linków nawigacji (najechanie, fokus, widoczny fokus, aktywny), na razie w zakresie typografii. Motywy, które robiły to własnym CSS, mogą przenieść część reguł do theme.json, ale najpierw warto sprawdzić, który zapis wygrywa.

W bloku galerii opcja sortowania działa teraz także dla galerii z ręcznie wybranych obrazów. Sortowanie od najnowszych, od najstarszych i alfabetycznie w obie strony porządkuje obrazy raz, a potem nadal można je przeciągać. Opcja losowa jest w tym samym miejscu i miesza obrazy przy każdym wczytaniu strony. Dla stron z pamięcią podręczną całych stron to ważne: losowa kolejność zmieni się dopiero przy odświeżeniu pamięci, nie przy każdej wizycie.

Galeria dostała też obsługę duotone. Jeden filtr barwi wszystkie obrazy galerii, ustawiony w bloku albo dla wszystkich galerii na stronie w stylach globalnych. Duotone ustawiony na pojedynczym obrazie ma pierwszeństwo przed ustawieniem galerii. Duotone trafił też do bloków media z tekstem i wideo. Przy zdjęciach produktów sprawdźcie, czy filtr ustawiony globalnie nie zmienia kolorów tam, gdzie klient ich nie chce.

#Co nowego w Interactivity API?

Nowa dyrektywa data-wp-html wyświetla HTML ze stanu, tak jak data-wp-text wyświetla tekst. Przyjmuje tylko wartości oznaczone jako zaufane przez asDangerousHTML(). Przykład z wpisu o wydaniu:

import { asDangerousHTML, store } from '@wordpress/interactivity';

store( 'myPlugin', {
	state: {
		get description() {
			return asDangerousHTML(
				'<p>A <strong>formatted</strong> description.</p>'
			);
		},
	},
} );

<div data-wp-interactive="myPlugin">
	<article data-wp-html="state.description">
		<p>Loading description.</p>
	</article>
</div>

Plan 7.2 wyjaśnia, że pierwsza wersja wyświetla tylko wartości jawnie oznaczone jako zaufane przez kod aplikacji, a obsługa oczyszczonych zwykłych napisów przyjdzie później. Do asDangerousHTML() nie przekazujcie niczego, co pochodzi od użytkownika albo z atrybutów bloku bez oczyszczenia po stronie PHP. W tym samym wydaniu dokumentacja Gutenberga dostała uwagę, że atrybuty bloków i wartości stylów globalnych trzeba w momencie renderowania traktować jako niezaufane. Jeśli robicie przegląd bezpieczeństwa wtyczki, dodajcie wyszukiwanie asDangerousHTML do listy rzeczy, które czyta człowiek.

Router udostępnia teraz state.navigating i state.initiator, więc blok wie, że trwa nawigacja po stronie klienta i który blok ją rozpoczął. Według planu 7.2 zastępuje to przestarzałą parę state.navigation.hasStarted i state.navigation.hasFinished. Bloki z własnym wskaźnikiem ładowania przy nawigacji warto przepisać na nowe pola, zanim stare zostaną usunięte.

#Czy notatki w Gutenbergu to już współpraca w czasie rzeczywistym?

Nie. Notatki to komentarze do bloków, czytane i dodawane w dowolnym momencie. Współpracy w czasie rzeczywistym nie ma w planie WordPress 7.2. Plan mówi, że jak w 7.1 potrzeba więcej czasu na decyzje architektoniczne, więc temat pominięto, zamiast wpisać go i potem wycofać.

Prace trwają w eksperymentalnej wtyczce gutenberg-sync-engines, opisanej w przewodniku po silnikach synchronizacji z 14 października. Testowane są trzy silniki: yjs-server, DE-RTC i intent-log. Wtyczka wymaga WordPressa 7.0 lub nowszego i wtyczki Presence API, a do tego zawiera własną, lekko zmienioną kopię Gutenberga. Nie zadziała więc obok aktywnej wtyczki Gutenberg, czyli testu React 19 i testu współpracy na żywo nie da się zrobić na jednej kopii strony.

Pod przewodnikiem autor biblioteki Yjs, Kevin Jahns, zwrócił uwagę na koszt serwera:

„Edycja w czasie rzeczywistym generuje mnóstwo małych komunikatów. Jeśli każdy z nich musi uruchomić proces PHP, wczytać współdzielony dokument, sprawdzić go, scalić i zapisać z powrotem do bazy danych, to duży narzut na komunikację, przetwarzanie i bazę danych.”

Źródło: komentarz Kevina Jahnsa pod przewodnikiem po silnikach synchronizacji, 15 października 2026, tłumaczenie własne

Dla właścicieli stron na tanim hostingu współdzielonym to sygnał, że współpraca w czasie rzeczywistym może kiedyś wymagać innego hostingu.

Aktualizacja, 3 listopada 2026. Wtyczka funkcyjna Presence API doszła do 0.20.0 1 listopada (lista WordPress.org; ok. 10 aktywnych instalacji). Podsumowanie spotkania z 26 października, opublikowane 1 listopada, mówi, że checklista do merge nadal wymaga zewnętrznych testów użytkowników i audytu bezpieczeństwa spoza repozytorium, a 3 grudnia to najwcześniejsza data pierwszej propozycji w Trac (osiem tygodni bez łamiącej zmiany API od 0.17.0). Wersje 0.18.4–0.20.0 dodają poprawkę wylogowania dla blokad wpisów, haki keepalive/roomChanged dla relayów push oraz wp_presence_admin_state(), żeby relay mógł zapisywać te same wiersze co Heartbeat. Presence zostaje zależnością gutenberg-sync-engines, nie zamiennikiem notatek w 24.2/24.3, i nadal nie wnosi współedycji w czasie rzeczywistym do WordPressa 7.2.

#Kto powinien przetestować bloki przed WordPressem 7.2?

Test ma sens dla każdej strony z własnymi blokami, rozszerzeniami edytora albo stronami ustawień w React, oraz dla autorów wtyczek i motywów, które takie elementy mają. Strona zbudowana wyłącznie z bloków WordPressa i popularnych wtyczek z aktywnym wsparciem zależy od tego, czy ich autorzy zrobią test. Zespół Gutenberga prosi o to właśnie teraz.

Jeśli nie macie w zespole osoby, która przejrzy zbudowane pliki i przeklika bloki na kopii strony, developer WordPress zrobi to w ramach jednego zlecenia, a przy stałej opiece nad stroną test nowych wersji Gutenberga przed aktualizacją produkcji jest częścią pracy. O tym, dlaczego taki przegląd wymaga człowieka, piszę też w tekście o rekrutacji developerów pracujących z AI.

W zapytaniu podajcie wersję WordPressa i PHP, listę wtyczek z własnymi blokami, informację, czy na produkcji jest wtyczka Gutenberg, i czy macie kopię testową strony. Wycena jest indywidualna, po zakresie. Formularz jest na stronie kontakt.