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

Gutenberg 24.2 to mały release produktowy dla redakcji i sygnał kompatybilności dla autorów bloków. Notes na marginesie oraz jedno wyszukiwanie w Navigation skracają tarcie content ops. React 19 włączony domyślnie w wtyczce Gutenberg przenosi testy własnych bloków na staging: regresja złapana teraz kosztuje mniej niż ta sama regresja po wejściu linii do core. Czekanie na ogłoszenie „React 19 w WordPress X.Y” zostawia ten błąd na produkcji klienta.

WordPress 7.1 zostawił React 19 poza zipem po problemach kompatybilności. 24.2 tej decyzji nie cofa. React 19 był we wtyczce Gutenberg eksperymentem do ręcznego włączenia od wersji 23.4; 24.2 włącza go domyślnie na każdej stronie z tą wtyczką.

Macie własne bloki albo sklep na FSE i nie chcecie ryzykować update na produkcji? Opiszcie stack (PHP, WP, WooCommerce, lista pluginów edytora) na kontakt. Dostaniecie plan stagingu i odbioru, nie sam changelog.

#Co nowego w Gutenberg 24.2

#Notes (notatki) w edytorze Gutenberg 24.2

Notes siedzą obok treści, nie tylko w sidebarze. Przy review artykułu albo landing page redaktor komentuje przy konkretnym bloku. Mniej skakania między panelem a canvasem.

Dla agencji z wieloosobowym content ops to zmienia rytm:

• copywriter zostawia uwagę przy H2, nie w wątku Slack bez kontekstu,
• reviewer widzi stos uwag przy bloku podczas drugiej rundy,
• developer bloków widzi, które miejsca UI generują najwięcej tarcia redakcyjnego (często własne bloki z niejasnym inspector).

Zmiany kodu nadal idą do Linear/Jira. Notes zastępują zrzuty ekranu z czerwoną strzałką w PDF przy review treści.

#Wyszukiwanie stron i kategorii w menu Navigation

Dodawanie stron, wpisów, kategorii i tagów do Navigation przez jedno pole search. Przy przebudowie IA serwisu (szczególnie wielojęzycznej) spada liczba klików i pomyłek „dodałem złą stronę z listy”.

Praktyczny test stagingu: zbuduj menu z mieszanką page + category + custom link, zapisz, odśwież front, sprawdź mobile overlay. Regresje w Navigation często wychodzą dopiero na froncie, nie w edytorze.

#Gallery w Gutenberg 24.2: sortowanie i duotone

Kontrolka Order by działa teraz także w galeriach z ręcznie wybranych obrazów (od najnowszych, od najstarszych, A do Z, Z do A albo losowo przy każdym wczytaniu strony), a jeden filtr duotone barwi wszystkie obrazy galerii, z poziomu bloku albo dla całej strony w Global Styles. Sprawdź:

• custom CSS zakładający stary markup filtrów,
• bloki potomne / wariacje Gallery w child theme,
• lazy load i CLS przy zmianie kolejności obrazów,
• eksport do AMP lub headless (jeśli serwujecie bloki poza klasycznym theme).

Duotone wygląda kosmetycznie, aż połamie kontrast na zdjęciach produktowych. W sklepach sprawdźcie Gallery na karcie produktu, nie tylko na blogu.

#React 19 w Gutenberg 24.2 (domyślnie)

To główny sygnał dla stacku deweloperskiego. Strony z wtyczką ładują teraz React 19 dla skryptów react i react-dom, chyba że aktywny jest motyw lub wtyczka znana z problemów kompatybilności; takie strony zostają na React 18. Gdy coś się psuje, React 19 można wyłączyć w Gutenberg > Experiments. Do atrybutu inert jest nowy pakiet @wordpress/react-inert-value, który działa i z React 18, i z 19 (wpis o wydaniu 24.2).

Wtyczki i motywy oparte o React w edytorze mają testować i raportować. Nie czekajcie na datę w core: Roadmap to 7.2 uznaje pełne wejście do 7.2 za mało prawdopodobne, więc regresje wychodzą najpierw we wtyczce.

Typowe miejsca pękania po upgrade React:

• react/jsx-runtime wbudowany w bundle wtyczki zamiast zewnętrznego skryptu dostarczanego przez WordPress (wtedy React 18 i 19 działają obok siebie),
• API usunięte w React 19: string refs, default props w komponentach funkcyjnych, legacy context,
• własne bloki z nieaktualnym @wordpress/scripts / starym webpack,
• slot fills i plugin sidebary zakładające stare lifecycle,
• zależności peer od React 18 w package.json wtyczki klienckiej,
• testy E2E Playwright/Cypress, które łapały timingi z 18.

Jeśli utrzymujecie bibliotekę bloków dla kilku klientów, jeden staging z 24.2 na reprezentatywnym projekcie jest tańszy niż pięć hotfixów po core.

#Gutenberg 24.2 a WordPress 7.1 i React 19 w core

W 7.1 React 19 nie wszedł do core. Decyzja była poprawna z punktu widzenia stabilności ekosystemu i niewygodna dla zespołów, które już przygotowały upgrade. Gutenberg 24.2 jest oficjalnym miejscem, w którym ekosystem ma „poczuć” React 19 bez wymuszania go na każdej instalacji bez wtyczki Gutenberg.

Dla agencji oznacza to trzy tory:

1. Klient bez Gutenberg plugin na produkcji - na razie zostaje na React z core (linia 7.1). Planujcie testy, nie instalujcie wtyczki Gutenberg „bo 24.2 wyszło”.
2. Klient z Gutenberg plugin (early features) - 24.2 to obowiązkowy staging przed update.
3. Własne produkty / bloki sprzedawane wielu klientom - CI przeciwko Gutenberg 24.2 + matrix PHP/WP.

Nie łączcie tego komunikatu z WordPress.com Agentem: to inny produkt i inny tor (Agent i MCP write). Agent nie testuje Waszych bloków pod React 19.

#Checklist testów Gutenberg 24.2 na stagingu

1. Zainstaluj Gutenberg 24.2 na kopii produkcyjnej (nie na live klienta). W Gutenberg > Experiments potwierdź, że React 19 jest aktywny: z wtyczką z listy niekompatybilnych strona zostaje na React 18 i test nic nie mówi o 19.
2. Otwórz wpis z Waszymi custom blokami: insert, duplicate, move, save, preview, undo.
3. Sprawdź Navigation: wyszukaj stronę i kategorię, zapisz menu, odśwież front i mobile.
4. Gallery z duotone: włącz filtr, zmień kolejność, zapisz, sprawdź front.
5. Notes: dodaj uwagę przy bloku, przeładuj edytor, potwierdź persistence, usuń.
6. Smoke WooCommerce (jeśli sklep): produkt, koszyk, checkout, e-mail.
7. Jeśli coś pada: minimalna reproducja + wersje PHP / WP / Gutenberg / wtyczki w issue trackerze.

Rozszerzenie przy bibliotece bloków (2-4 godziny):

• uruchom unit/integration testy pakietu,
• zbuduj assets na czysto (npm ci + build),
• sprawdź peerDependencies React,
• porównaj bundle size przed/po (regresja często idzie w parze z podwójnym Reactem).

#Czego unikać przy aktualizacji Gutenberg 24.2

• Nie włączajcie wtyczki Gutenberg na produkcji sklepu WooCommerce bez rollback planu i okna serwisowego.
• Nie obiecujcie klientowi „React 19 w core od jutra”. 24.2 to wtyczka.
• Nie traktujcie Notes jako systemu ticketowego dla deweloperów.
• Nie aktualizujcie dziesięciu klientów tego samego dnia „bo wyszło 24.2”. Jeden reprezentatywny staging, potem fala.

#Gutenberg 24.2 w retainerze utrzymaniowym

Klient na retainerze „aktualizacje WordPress” powinien dostać w raporcie miesięcznym osobną linię: test Gutenberg 24.2 / tor React 19. To sesja kompatybilności bloków, osobna od zwykłego bumpa core.

Jeśli retainer nie obejmuje testów edytora, dopiszcie change request przed update Gutenberg na stagingu. Tanio wychodzi raz. Drogo wychodzi, gdy edytor pada w dniu publikacji kampanii.

#Notes i Navigation search w codziennej redakcji

Notes

• jedna uwaga = jedna decyzja (copy / layout / legal),
• bez wątków filozoficznych w marginesie,
• po merge do final: usuń lub archiwizuj notes, żeby canvas nie wyglądał jak graffiti.

Navigation search

• nazwy stron w adminie muszą być unikalne i czytelne (duplikaty „Oferta” w dwóch językach bez prefiksu locale mylą search),
• po przebudowie menu: eksport struktury do dokumentu IA (nawet tabela Markdown) jako źródło prawdy poza WordPressem.

#Test Gutenberg 24.2 na WooCommerce i membership

Jeśli serwis to nie blog, a sklep albo membership, checklista ogólna jest za krótka. Dodajcie:

• edycja szablonu Single Product w site editorze (nie tylko klasyczny produkt),
• bloki koszyka / checkout (bloki Woo vs shortcode legacy),
• bloki restricted content (membership, paywall),
• preview jako użytkownik zalogowany vs gość,
• zapis draft produktu z Gallery + duotone (czy front sklepu nie dziedziczy filtra na miniaturach w gridzie).

Regresja React w Inspectorze produktu potrafi zablokować publikację kampanii Black Friday bardziej niż regresja na poście blogowym. Priorytetyzujcie staging sklepu przed stagingiem bloga firmowego.

#Gutenberg 24.2 a child theme, FSE i theme.json

Agencje często trzymają „kilka linii” w theme.json i style.css child theme. Po 24.2 sprawdźcie:

• nadpisania Gallery i duotone w theme.json,
• CSS celujący w klasy, które Notes albo nowy UI Navigation mogły zmienić,
• pattern’y zsynchronizowane z biblioteką, które zakładają stary markup.

FSE nie zwalnia z testów. Przeciwnie: im więcej UI w JSON i patternach, tym więcej miejsc, gdzie React 19 w edytorze może pokazać pusty panel albo nieskończony spinner. Tło o blokach, wzorcach i Site Editorze: bloki Gutenberg i full site editing.

#Jak zgłosić klientowi wynik testów Gutenberg 24.2

W mailu po teście stagingu trzy akapity wystarczą:

1. Co przetestowaliśmy (lista bloków + Navigation + Gallery + Notes).
2. Co znaleźliśmy (konkret: „Inspector bloku X gubi focus”, nie „edytor dziwnie działa”).
3. Decyzja: aktualizujemy Gutenberg / czekamy na fix upstream / zostajemy na core bez pluginu do daty Y.

Klienci akceptują opóźnienie update, gdy widzą listę testów. Nie akceptują „jakoś padło po update” bez tej listy.

#Jak zgłosić bug w Gutenberg 24.2

Issue w repo wtyczki albo na Gutenberg GitHub powinien mieć:

• wersje: WP, PHP, Gutenberg, przeglądarka,
• kroki reproducji w 5 linijkach,
• oczekiwane vs faktyczne,
• czy pada tylko z Waszym blokiem, czy na Twenty Twenty-Five + core blocks.

„U nas nie działa” bez reproducji ląduje w limbo. Jedna dobra reproducja na czystym środowisku przyspiesza fix bardziej niż dziesięć komentarzy „+1”.

#Matrix testów React 19 dla biblioteki bloków

Jeden staging na jednym kliencie nie wystarczy, jeśli sprzedajecie bloki wielu markom. Minimalny matrix:

Automatyzacja: jeden workflow CI, który instaluje Gutenberg 24.2, buduje bloki, odpala smoke Playwright na insert/save. Ręcznie zostawcie Navigation, Gallery duotone i Notes - E2E bywa kruche na marginesach UI.

Koszt matrixu zwraca się przy drugim kliencie z tą samą biblioteką bloków. Przy jednym landingu „static” wystarczy checklista 15-30 minut z poprzedniej sekcji.

#Typowe regresje po React 19 w Gutenberg

Z doświadczenia upgrade’ów React w ekosystemie WordPress (nie tylko 24.2) najczęściej wychodzą:

• podwójna kopia React w bundlu (objaw: dziwne warningi w konsoli, niespójny state),
• kontrolki Inspector, które „gubią” focus przy każdym keystroke,
• bloki dynamiczne SSR vs client: hydrate mismatch po zmianie markup Gallery,
• starsze @wordpress/components jako peer niekompatybilne z nowym Reactem,
• E2E czekające na selektory, które Notes albo nowy Navigation search przestawiły w DOM.

Każdą regresję zapisujcie z wersją Gutenberg w tytule issue. „Psuje się edytor” bez numeru wersji jest bezużyteczne przy bisect.

#Gutenberg Notes a współpraca w czasie rzeczywistym

W tym samym tygodniu Make WordPress Core opublikował przewodnik po silnikach synchronizacji testowanych do współpracy w czasie rzeczywistym. W komentarzu pod tym wpisem autor Yjs, Kevin Jahns, ostrzegał, że edycja na żywo generuje mnóstwo małych komunikatów, a uruchamianie workera PHP dla każdego z nich to duży narzut. To nie jest changelog 24.2, ale kontekst dla leadów technicznych: tor współpracy wieloosobowej i tor React 19 to osobne ryzyka. Notes na marginesie rozwiązują asynchroniczny review. Nie rozwiązują konfliktu dwóch kursorów w tym samym bloku.

Nie sprzedawajcie klientowi „real-time collaboration”, bo wyszło 24.2. Sprzedawajcie sprawniejszy review i przetestowane bloki.

#Kiedy wdrażać Gutenberg 24.2 na produkcji

1. Staging zielony na checklistie i na smoke WooCommerce.
2. Okno serwisowe uzgodnione (nie piątek po 16:00 przy sklepie).
3. Rollback: poprzedni zip Gutenberg + backup DB z przed update.
4. Monitoring 24-48 h: błędy JS w edytorze, tickety publikacji, failure checkout.

Jeśli klient ma włączony auto-update wtyczek, wyłączcie auto-update Gutenberg do czasu zielonego stagingu. Gutenberg to nie „kolejna SEO wtyczka”.

#Release notes wtyczki bloków po Gutenberg 24.2

Jeśli sprzedajecie własne bloki jako wtyczkę:

• dodajcie w changelogu linię „tested with Gutenberg 24.2 (React 19 default)”,
• w readme: wymagana minimalna wersja @wordpress/scripts / build toolchain,
• w CI: job gutenberg-next obok joba wordpress-stable,
• w support policy: „zgłoszenia bez numeru Gutenberg zamykamy z prośbą o uzupełnienie”.

Klienci enterprise czytają release notes. Jedna linia o 24.2 buduje zaufanie bardziej niż ogólne „improved compatibility”.

#Duotone Gallery a design system marki

Duotone w Gallery jest wygodne dla redakcji i niebezpieczne dla brandu z ścisłym design systemem. Jeśli klient ma zdefiniowane filtry i tokeny koloru:

• wyłączcie duotone w patternach produktowych,
• zostawcie je na blogu / social proof,
• zapiszcie regułę w Guidelines contentowych (nie mylić z Guidelines WordPress.com Agent).

Agent i Gutenberg to osobne produkty, ale ten sam problem: narzędzie daje redakcji moc, której brand guide nie przewidział. Ownership design systemu zostaje po stronie agencji.

#Dlaczego WordPress 7.1 odłożył React 19

Przypomnienie faktów z lata 2026 (szczegóły w road mapie 7.1): upgrade z React 18 do 19 wypadł z 7.1 po krótkiej próbie w Gutenbergu, która pokazała nieoczekiwane niezgodności między obiema wersjami React i w sposobie, w jaki wtyczki używają React. W poście na Make Core z 24 lipca 2026 Jarda Snajdr napisał, że potrzebny jest dłuższy okres testów, żeby dopracować warstwę kompatybilności. 24.2 jest konsekwencją tej ostrożności: najpierw wtyczka Gutenberg, potem ewentualnie core.

Dla leadów: nie narracja „Automattic się spóźnia”, tylko „macie okno testów, z którego musicie skorzystać”. Agencje, które w sierpniu odłożyły przygotowania „bo 7.1 bez React 19”, w październiku dostają drugą szansę w 24.2. Trzeciej przed core może nie być wygodnej.

#Odbiór freelancerskich bloków pod Gutenberg 24.2

Gdy freelancerski autor bloku mówi „u mnie działa na core”, dopytajcie:

• czy testował Gutenberg 24.2,
• czy w package.json jest peer React 19 czy nadal 18,
• czy dostarczy reproducję na czystym stagingu.

Płatność za blok bez tej checklisty to zakup ryzyka. W umowie B2B dopiszcie akceptację na środowisku z Gutenberg 24.2 jako warunek odbioru.

#Wydajność edytora po React 19 w Gutenberg

Nowszy React często poprawia concurrent features, ale na słabych laptopach redakcji albo na VPS z ciężkim adminem możecie zobaczyć:

• dłuższy czas do interaktywności Inspectora,
• jank przy drag-and-drop dużej Gallery,
• wyższe zużycie pamięci przy wielu notes naraz.

Mierzcie subiektywnie na sprzęcie redaktora (nie tylko na M-series developera) i obiektywnie: Performance panel w DevTools na zapisie wpisu z 40 blokami. Jeśli LCP admina nie obchodzi SEO, to obchodzi retencję content teamu. Redaktor, który czeka 3 sekundy na każdą zmianę w Inspectorze, wraca do Classic Editor albo do Google Docs.

#Dostępność notatek i nawigacji w Gutenberg 24.2

Notes na marginesie muszą być osiągalne z klawiatury i czytelne dla czytników. Navigation search musi zapowiadać wyniki dla AT. Po 24.2:

• przejdźcie tabem przez notes i zamknięcie uwagi,
• sprawdźcie focus trap w modalach Navigation,
• nie zakładajcie, że „nowy UI Automattic = WCAG z automatu”.

Dla klientów pod BFSG / EAA / polską ustawą o dostępności to nie jest opcjonalny test. To warunek odbioru szablonu.

#Kiedy zostać na WordPress core bez wtyczki Gutenberg

Zostańcie na core (bez Gutenberg plugin), gdy:

• sklep generuje tyle zamówień dziennie, że nie macie okna na regresję,
• zależycie od wtyczek edytora bez maintainerów,
• klient ma kontrakt „zero zmian UI admina w Q4”.

Włączcie 24.2 na stagingu mimo to, żeby wiedzieć, co Was czeka. Baseline wiedzy jest tańszy niż niespodzianka w dniu core upgrade.

#Szkolenie redakcji z Notes w Gutenberg 24.2

Techniczny green light to połowa sukcesu. Druga połowa: 30-minutowy warsztat dla redaktorów.

Agenda:

1. Jak dodać note przy bloku i jak ją rozwiązać.
2. Kiedy note, a kiedy ticket w trackerze (zmiana kodu = ticket).
3. Jak szukać w Navigation bez tworzenia duplikatów stron.
4. Kiedy nie ruszać duotone na zdjęciach produktowych.

Bez warsztatu notes zamieniają się w śmietnik, a search w Navigation w źródło złych linków. W retainerze zapiszcie ten warsztat jako linię wdrożeniową 24.2.

#Ryzyka Gutenberg 24.2 dla leadów technicznych

W jednej tabeli dla statusu projektu:

Dla zarządu: 24.2 jest tani na stagingu i drogi na produkcji bez checklisty.

#Kiedy zlecić test Gutenberg 24.2 na zewnątrz

Zlećcie przegląd, gdy:

• utrzymujecie bibliotekę bloków dla wielu marek,
• sklep generuje sprzedaż i nie macie okna na regresję Inspectora,
• freelancer oddał bloki „działające na core” bez testu 24.2,
• retainer „aktualizacje” nie obejmuje jeszcze toru React 19.

W zapytaniu podajcie: URL stagingu albo listę wtyczek, wersję WooCommerce, czy HPOS jest włączony, deadline okna serwisowego. To wystarczy, żeby wycenić smoke vs pełny matrix.

#Gutenberg 24.2: staging przed produkcją

Notes, search w menu i Gallery to zysk redakcyjny. React 19 w wtyczce to obowiązek stagingu dla agencji sprzedającej bloki i FSE. Update bez checklisty przenosi ryzyko na klienta.

Tor Agent / MCP write i tor Gutenberg zostają osobne: Agent nie testuje React, React 19 w wtyczce nie zamyka publish gate przy MCP write.

Przegląd bloków albo retainer z toru Gutenberg: kontakt. Szerszy rozwój: WordPress developer.