Gutenberg 24.2 and React 19: what to test in your custom blocks

Gutenberg 24.2 is a small product release for editorial teams and a compatibility signal for block authors. Margin notes and a single Navigation search cut content-ops friction. React 19 enabled by default in the Gutenberg plugin moves testing of your own blocks onto staging: a regression caught now costs less than the same regression after this line lands in core. Waiting for an announcement that “React 19 is in WordPress X.Y” leaves that bug on a client production site.

WordPress 7.1 left React 19 out of the zip after compatibility problems. 24.2 does not reverse that decision. React 19 has been an opt-in experiment in the Gutenberg plugin since 23.4; 24.2 switches it on by default for every site running the plugin.

Do you have custom blocks or an FSE shop and do not want to risk an update on production? Describe the stack (PHP, WP, WooCommerce, editor plugin list) via contact. You get a staging and acceptance plan, not only a changelog.

#What’s new in Gutenberg 24.2

#Notes in the Gutenberg 24.2 editor

Notes sit next to the content, not only in the sidebar. During review of an article or landing page, an editor comments beside the specific block. Less jumping between the panel and the canvas.

For agencies with multi-person content ops, that changes the rhythm:

• a copywriter leaves a note on an H2, not in a Slack thread without context,
• a reviewer sees a stack of notes on the block in the second round,
• a block developer sees which UI spots create the most editorial friction (often custom blocks with a muddy inspector).

Code changes still go to Linear/Jira. Notes replace screenshots with a red arrow in a PDF during content review.

#Searching pages and categories in the Navigation menu

Adding pages, posts, categories, and tags to Navigation through a single search field. When you rebuild a site’s IA (especially multilingual), click count and “I added the wrong page from the list” mistakes drop.

Practical staging test: build a menu with a mix of page + category + custom link, save, refresh the front, check the mobile overlay. Navigation regressions often show up on the front, not in the editor.

#Gallery in Gutenberg 24.2: sorting and duotone

The Order by control now works for galleries of hand-picked images too (newest, oldest, A to Z, Z to A, or random on each page load), and one duotone filter can tint every image in a gallery, from the block or site-wide from Global Styles. Check:

• custom CSS that assumes the old filter markup,
• child blocks / Gallery variations in a child theme,
• lazy load and CLS when image order changes,
• export to AMP or headless (if you serve blocks outside a classic theme).

Duotone looks cosmetic until it breaks contrast on product photos. In shops, check Gallery on the product card, not only on the blog.

#React 19 in Gutenberg 24.2 (by default)

This is the main signal for the developer stack. Sites running the plugin now load React 19 for the react and react-dom scripts, unless a theme or plugin known to be incompatible is active; those sites keep React 18. If something breaks, React 19 can be turned off under Gutenberg > Experiments. For the inert attribute, the new @wordpress/react-inert-value package works with both React 18 and 19 (24.2 release post).

Plugins and themes that use React in the editor should test and report. Do not wait for a date in core: the Roadmap to 7.2 calls a full landing in 7.2 unlikely, so the plugin is where regressions surface first.

Typical break points after a React upgrade:

• react/jsx-runtime bundled into the plugin instead of using the externalized script WordPress provides (React 18 and 19 then run side by side),
• APIs removed in React 19: string refs, default props on function components, legacy context,
• custom blocks on outdated @wordpress/scripts / old webpack,
• slot fills and plugin sidebars that assume old lifecycles,
• React 18 peer dependencies in a client plugin package.json,
• Playwright/Cypress E2E tests that locked onto React 18 timing.

If you maintain a block library for several clients, one staging site with 24.2 on a representative project is cheaper than five hotfixes after core.

#Gutenberg 24.2 vs WordPress 7.1 and React 19 in core

In 7.1, React 19 did not enter core. The decision was right for ecosystem stability and awkward for teams that had already prepared the upgrade. Gutenberg 24.2 is the official place where the ecosystem can feel React 19 without forcing it onto every install without the Gutenberg plugin.

For agencies that means three tracks:

1. Client without the Gutenberg plugin on production - stays on core React for now (7.1 line). Plan tests; do not install the Gutenberg plugin “because 24.2 shipped”.
2. Client with the Gutenberg plugin (early features) - 24.2 is mandatory staging before the update.
3. Own products / blocks sold to many clients - CI against Gutenberg 24.2 + PHP/WP matrix.

Do not mix this message with the WordPress.com Agent: different product, different track (Agent and MCP write). The Agent does not test your blocks under React 19.

#Gutenberg 24.2 staging test checklist

1. Install Gutenberg 24.2 on a production copy (not on the live client site). Under Gutenberg > Experiments, confirm React 19 is active: with a plugin from the incompatibility list the site stays on React 18 and the test says nothing about 19.
2. Open a post with your custom blocks: insert, duplicate, move, save, preview, undo.
3. Check Navigation: search for a page and a category, save the menu, refresh front and mobile.
4. Gallery with duotone: enable the filter, change order, save, check the front.
5. Notes: add a note on a block, reload the editor, confirm persistence, delete.
6. WooCommerce smoke (if a shop): product, cart, checkout, email.
7. If something fails: minimal reproduction + PHP / WP / Gutenberg / plugin versions in the issue tracker.

Extension for a block library (2-4 hours):

• run the package unit/integration tests,
• clean build of assets (npm ci + build),
• check React peerDependencies,
• compare bundle size before/after (regressions often travel with a duplicate React).

#What to avoid when updating Gutenberg 24.2

• Do not enable the Gutenberg plugin on a live WooCommerce shop without a rollback plan and a maintenance window.
• Do not promise the client “React 19 in core tomorrow”. 24.2 is a plugin.
• Do not treat Notes as a ticket system for developers.
• Do not update ten clients the same day “because 24.2 shipped”. One representative staging, then the wave.

#Gutenberg 24.2 in a maintenance retainer

A client on a “WordPress updates” retainer should get a separate line in the monthly report: Gutenberg 24.2 test / React 19 track. That is a block compatibility session, separate from a normal core bump.

If the retainer does not cover editor tests, add a change request before updating Gutenberg on staging. Cheap once. Expensive when the editor dies on campaign publish day.

#Notes and Navigation search in daily editorial work

Notes

• one note = one decision (copy / layout / legal),
• no philosophical threads in the margin,
• after merge to final: delete or archive notes so the canvas does not look like graffiti.

Navigation search

• page names in admin must be unique and readable (duplicate “Offer” in two languages without a locale prefix confuses search),
• after a menu rebuild: export the structure to an IA document (even a Markdown table) as the source of truth outside WordPress.

#Testing Gutenberg 24.2 on WooCommerce and membership

If the site is a shop or membership, not a blog, the general checklist is too short. Add:

• editing the Single Product template in the site editor (not only the classic product),
• cart / checkout blocks (Woo blocks vs legacy shortcode),
• restricted content blocks (membership, paywall),
• preview as logged-in user vs guest,
• saving a product draft with Gallery + duotone (whether the shop front inherits the filter on grid thumbnails).

A React regression in the product Inspector can block a Black Friday campaign harder than a regression on a blog post. Prioritize shop staging before the company blog.

#Gutenberg 24.2 vs child theme, FSE and theme.json

Agencies often keep “a few lines” in theme.json and child theme style.css. After 24.2 check:

• Gallery and duotone overrides in theme.json,
• CSS targeting classes that Notes or the new Navigation UI may have changed,
• synced patterns that assume old markup.

FSE does not excuse you from tests. The more UI lives in JSON and patterns, the more places React 19 in the editor can show an empty panel or an infinite spinner. Background on blocks, patterns and Site Editor: Gutenberg blocks and full site editing guide.

#How to report Gutenberg 24.2 test results to a client

Three paragraphs in the staging-test email are enough:

1. What we tested (block list + Navigation + Gallery + Notes).
2. What we found (concrete: “block X Inspector loses focus”, not “the editor acts weird”).
3. Decision: update Gutenberg / wait for an upstream fix / stay on core without the plugin until date Y.

Clients accept a delayed update when they see a test list. They do not accept “it somehow broke after the update” without that list.

#How to file a Gutenberg 24.2 bug

An issue in the plugin repo or on Gutenberg GitHub should have:

• versions: WP, PHP, Gutenberg, browser,
• reproduction steps in five lines,
• expected vs actual,
• whether it fails only with your block, or on Twenty Twenty-Five + core blocks.

“It doesn’t work for us” without a reproduction lands in limbo. One good reproduction on a clean environment speeds a fix more than ten “+1” comments.

#React 19 test matrix for a block library

One staging site on one client is not enough if you sell blocks to many brands. Minimal matrix:

Automation: one CI workflow that installs Gutenberg 24.2, builds blocks, runs Playwright smoke on insert/save. Leave Navigation, Gallery duotone, and Notes manual - E2E is brittle on UI margins.

Matrix cost pays back on the second client with the same block library. For one static landing, the 15-30 minute checklist above is enough.

#Typical regressions after React 19 in Gutenberg

From React upgrades in the WordPress ecosystem (not only 24.2), the usual catches are:

• duplicate React in the bundle (symptom: odd console warnings, inconsistent state),
• Inspector controls that “lose” focus on every keystroke,
• dynamic SSR vs client blocks: hydrate mismatch after Gallery markup changes,
• older @wordpress/components peers incompatible with the new React,
• E2E waiting on selectors that Notes or the new Navigation search moved in the DOM.

Log every regression with the Gutenberg version in the issue title. “Editor is broken” without a version number is useless for bisect.

#Gutenberg Notes vs real-time collaboration

In the same week, Make WordPress Core published a guide to the sync engines under evaluation for real-time collaboration. In a comment under that post, Yjs author Kevin Jahns warned that real-time editing generates many small messages, and that spinning up a PHP worker for each one adds overhead. That is not the 24.2 changelog, but context for tech leads: the multi-person collaboration track and the React 19 track are separate risks. Margin notes solve async review. They do not solve two cursors colliding in the same block.

Do not sell the client “real-time collaboration” because 24.2 shipped. Sell cleaner review and tested blocks.

#When to deploy Gutenberg 24.2 to production

1. Staging green on the checklist and on WooCommerce smoke.
2. Agreed maintenance window (not Friday after 16:00 on a shop).
3. Rollback: previous Gutenberg zip + DB backup from before the update.
4. Monitoring 24-48 h: JS errors in the editor, publish tickets, checkout failures.

If the client has plugin auto-updates on, disable Gutenberg auto-update until staging is green. Gutenberg is not “just another SEO plugin”.

#Block plugin release notes after Gutenberg 24.2

If you sell your own blocks as a plugin:

• add a changelog line “tested with Gutenberg 24.2 (React 19 default)”,
• in the readme: minimum required @wordpress/scripts / build toolchain,
• in CI: a gutenberg-next job beside wordpress-stable,
• in support policy: “reports without a Gutenberg version get closed with a request to fill it in”.

Enterprise clients read release notes. One line about 24.2 builds more trust than a vague “improved compatibility”.

#Gallery duotone vs brand design system

Duotone in Gallery is convenient for editorial and dangerous for a brand with a strict design system. If the client has defined filters and color tokens:

• disable duotone in product patterns,
• leave it on the blog / social proof,
• write the rule into content guidelines (not to be confused with WordPress.com Agent Guidelines).

Agent and Gutenberg are separate products, but the same problem: the tool gives editorial power the brand guide never planned. Design-system ownership stays with the agency.

#Why WordPress 7.1 deferred React 19

Facts from summer 2026 (detail in the 7.1 roadmap): the upgrade from React 18 to 19 dropped out of 7.1 after a brief trial in Gutenberg showed unexpected incompatibilities between the two React versions and in how plugins use React. In the Make Core post of 24 July 2026, Jarda Snajdr wrote that a considerable testing period is needed to fine-tune the compatibility layer. 24.2 is the consequence of that caution: Gutenberg plugin first, core later if at all.

For leads: skip the narrative “Automattic is late”; use “you have a test window you must use”. Agencies that shelved prep in August “because 7.1 has no React 19” get a second chance in October with 24.2. A third convenient window before core may not appear.

#Accepting freelance blocks under Gutenberg 24.2

When a freelance block author says “it works for me on core”, ask:

• whether they tested Gutenberg 24.2,
• whether package.json peers React 19 or still 18,
• whether they can deliver a reproduction on clean staging.

Paying for a block without that checklist is buying risk. In a B2B contract, add acceptance on an environment with Gutenberg 24.2 as a delivery condition.

#Editor performance after React 19 in Gutenberg

Newer React often improves concurrent features, but on weak editorial laptops or a VPS with a heavy admin you may see:

• longer time to Inspector interactivity,
• jank dragging a large Gallery,
• higher memory use with many notes at once.

Measure subjectively on the editor’s hardware (not only the developer’s M-series) and objectively: DevTools Performance panel on saving a post with 40 blocks. If admin LCP does not matter for SEO, it matters for content-team retention. An editor who waits three seconds for every Inspector change goes back to Classic Editor or Google Docs.

#Accessibility of notes and navigation in Gutenberg 24.2

Margin notes must be keyboard-reachable and readable by screen readers. Navigation search must announce results for AT. After 24.2:

• tab through notes and closing a note,
• check focus trap in Navigation modals,
• do not assume “new Automattic UI = WCAG automatically”.

For clients under BFSG / EAA / accessibility law, that is not an optional test. It is a template acceptance condition.

#When to stay on WordPress core without the Gutenberg plugin

Stay on core (no Gutenberg plugin) when:

• the shop generates enough daily orders that you have no window for a regression,
• you depend on editor plugins without maintainers,
• the client has a “zero admin UI changes in Q4” contract.

Still enable 24.2 on staging so you know what is coming. A knowledge baseline is cheaper than a surprise on core-upgrade day.

#Training editors on Notes in Gutenberg 24.2

A technical green light is half the success. The other half: a 30-minute workshop for editors.

Agenda:

1. How to add a note on a block and how to resolve it.
2. When a note, when a tracker ticket (code change = ticket).
3. How to search in Navigation without creating duplicate pages.
4. When not to touch duotone on product photos.

Without the workshop, notes become a dump, and Navigation search becomes a source of bad links. Put the workshop in the retainer as a 24.2 implementation line.

#Gutenberg 24.2 risks for technical leads

One table for project status:

For leadership: 24.2 is cheap on staging and expensive on production without a checklist.

#When to outsource Gutenberg 24.2 testing

Commission a review when:

• you maintain a block library for multiple brands,
• the shop generates revenue and you have no window for an Inspector regression,
• a freelancer delivered blocks that “work on core” without a 24.2 test,
• the “updates” retainer does not yet cover the React 19 track.

In the inquiry, provide: staging URL or plugin list, WooCommerce version, whether HPOS is on, and the maintenance window deadline. That is enough to quote smoke versus a full matrix.

#Gutenberg 24.2: staging before production

Notes, menu search, and Gallery are an editorial win. React 19 in the plugin is a staging duty for agencies that sell blocks and FSE. An update without a checklist moves risk onto the client.

The Agent / MCP write track and the Gutenberg track stay separate: the Agent does not test React, and React 19 in the plugin does not close the publish gate for MCP write.

Block review or a retainer that includes the Gutenberg track: contact. Broader development: WordPress developer.