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

Update, 3 November 2026. Gutenberg 24.3 is out (plugin dated 28 October; What’s new post published 2 November). Editorial changes that matter on a live site: format text across a multi-block selection, emoji reactions on notes (heart, party, eyes and a few more), a Media inserter rebuilt on the DataViews grid with previews for non-image files, and save/autosave failure notices that show details, HTTP status when available, a copy action and a countdown to the next autosave. The release also ships the security fixes from WordPress 7.1.4, so update the Gutenberg plugin if you run it on production. React 19 stays on by default as in 24.2; the testing checklist below still applies.

Gutenberg 24.2 came out on 14 October 2026. For editorial teams it brings notes in the editor margin, a single link search in menus and gallery sorting. For plugin and theme authors one change matters more: the Gutenberg plugin now loads React 19 by default instead of React 18. If your site has custom blocks or settings pages written in React, check them now, before React 19 reaches WordPress itself.

This post is based on the official 24.2 release post, the changelog in the Gutenberg repository, two Make WordPress Core posts about React 19 and the React 19 upgrade guide.

#What’s new in Gutenberg 24.2?

The release has five main changes:

• notes moved into a margin next to the content,
• one search for every kind of link in the Navigation block,
• sorting and a shared duotone filter in the Gallery block,
• more blocks with the same design tools (about 80 code changes),
• React 19 on by default and two additions to the Interactivity API.

On top of that there are more than 60 bug fixes plus accessibility and performance changes. A few smaller changes matter in daily work. The column count slider in the Columns block is gone: you add a column with the plus button next to the block button in the toolbar and remove it like any other block. After cropping an image, the image editor lets you go back to the original without opening the media library. The post author field always has search and looks users up on the server, so on sites with many accounts the right person shows up in the list.

Gutenberg 24.2 also fixes the addresses of new posts. Until now a new post could be published with the slug auto-draft if someone clicked into the slug field before publishing. In 24.2 that no longer happens. If you have seen posts with that address on a site running the Gutenberg plugin, this was the cause.

Panels added by plugins have moved to a panels submenu in the editor’s options menu, next to the new appearance and notes submenus. Pinned buttons for these panels in the toolbar stay where they were. Authors of plugins with their own sidebar should check that their user instructions still point to the right place.

#Is React 19 in WordPress yet?

No. WordPress 7.1 runs on React 18.3. In July 2026 Jarda Snajdr explained on Make WordPress Core why the move to React 19 was dropped from 7.1: after it was briefly enabled in the Gutenberg plugin, unexpected incompatibilities showed up between the old and new versions of React and in the ways plugins use React, and the change had to be reverted.

“We’ll need a considerable testing period where we improve and fine-tune the compatibility layer that allows the existing plugins to run seamlessly.”

Source: Jarda Snajdr, Make WordPress Core, 24 July 2026

Since version 23.4 the Gutenberg plugin has had a React 19 experiment that you had to turn on by hand. Gutenberg 24.2 flips that setting: the experiment is on by default. WordPress on its own, without the Gutenberg plugin, still loads React 18.3.

The WordPress 7.2 release plan targets early December 2026. On React 19 it says the types, dependencies and rendering fixes in Gutenberg are mostly ready, but a full move in 7.2 is unlikely. For teams that maintain sites, this means React 19 in the Gutenberg plugin is a testing period now, not a release date for WordPress. The background to the summer decision is in my post on the WordPress 7.1 roadmap.

#When does Gutenberg 24.2 keep a site on React 18?

According to the release post, sites with the plugin load React 19 for the react and react-dom scripts, unless a theme or plugin known to have compatibility problems is active. In that case the site stays on React 18. The list of such themes and plugins started from issues observed on WordPress.com and was extended in this release (change #84607).

Two practical points follow. First, the same Gutenberg version can load different React versions on two sites, depending on the set of plugins. When you test a block, check which version the editor actually got. On the editor screen, type React.version in the browser console, because WordPress exposes React as a global variable. Second, a lack of problems on a site that landed on the exception list proves nothing. The block was tested on React 18.

The exception list is a temporary fix. If your plugin is on it, the problem will come back on the day React 19 reaches WordPress.

#How do you turn off React 19 in Gutenberg?

The Gutenberg team says plainly what to do when something breaks:

“If you maintain a plugin or theme that uses React, please test it with Gutenberg 24.2 and report any issue you find. If something breaks on a site, turn React 19 off under Gutenberg > Experiments.”

Source: What’s new in Gutenberg 24.2, Make WordPress Core, 14 October 2026

In the WordPress dashboard that is the Gutenberg menu, the Experiments page, the checkbox next to React 19. The July post about the experiment described the same page as part of the Gutenberg settings. Turning it off applies to the whole site, so it is an emergency measure for production, not a way to fix a block. A block that works only with React 19 turned off has to be fixed before WordPress ships with React 19.

The second option is not to install the Gutenberg plugin on production. A site without this plugin gets React from WordPress, which today is 18.3. You install the Gutenberg plugin on production when the client needs features that are not in WordPress yet. If they do not, test React 19 on a copy of the site.

#Which APIs did React 19 remove, and what does that break in WordPress blocks?

The July Make WordPress Core post names two typical causes of plugin breakage. The second is old React features, deprecated for at least six years and removed in React 19. The compatibility layer in Gutenberg fills in some of them, but not all. The React 19 upgrade guide gives the full list along with the date from which each API was deprecated:

Class components keep defaultProps, because classes have no equivalent in ES6 syntax. react-dom/test-utils and react-test-renderer/shallow were also removed, which affects unit tests, not the block itself.

In WordPress code the most common case is render mounting a settings page or a dashboard widget. Older plugins import it from @wordpress/element, which calls ReactDOM.render under the hood. Newer versions of this package export createRoot, and that is the one to use:

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

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

The second common case is defaultProps on a function component in the block editor. In React 19 the default values are simply not set, so the component receives undefined and usually does not throw an error. It shows an empty panel or calculates a value wrongly instead. This kind of bug is easy to miss, because the console stays silent.

The guide provides a ready set of automatic fixes: npx codemod@latest react/19/migration-recipe. Run it on a separate branch and read every change, because it does not know the specifics of the @wordpress/* packages.

React 18.3, which WordPress 7.1 runs on, is identical to 18.2 according to the React team, but it adds warnings about deprecated APIs and other changes needed for React 19. If you see warnings with your plugin’s name in the editor console on plain WordPress 7.1, that is a ready list of things to fix.

#How do you check whether a plugin bundles its own copy of React?

The first cause of breakage in the July post is more common and harder to spot in the source code, because it only shows up in the built JavaScript file.

“If everyone was bundling their JavaScript correctly, the majority of compat issues wouldn’t happen at all.”

Source: Jarda Snajdr, Make WordPress Core, 24 July 2026

The problem is react/jsx-runtime code bundled directly into the plugin file instead of the react-jsx-runtime script that WordPress provides. The site then runs React 18 from the plugin bundle next to React 19 from WordPress, and data structures created by the old version reach the new one. The component looks correct in the code, but in the editor it does not mount or throws an error about an invalid element.

The check takes a few minutes per plugin:

1. Open the *.asset.php file next to the built script (for example build/index.asset.php). If the code uses JSX, react-jsx-runtime should be on the dependency list.
2. Search the built files for React’s own code, for example grep -l "react.element" build/*.js. A hit in the plugin file signals that part of React is in the bundle. It is a reason to check the build configuration, not a verdict.
3. Check that the build configuration does not bypass the mechanism that swaps react and @wordpress/* imports for WordPress scripts. This happens most often with a custom webpack or Vite setup instead of @wordpress/scripts.
4. For plugins bought from an outside vendor, without access to the source, what remains is the editor test from the next section and a report to the author.

The Gutenberg team is working on detecting these problems automatically in the Plugin Check plugin. Until that works, the check stays with the plugin author.

#How do you test custom blocks with React 19 on a copy of the site?

The July post defines the compatibility test simply: use every part of the plugin that relies on React, which usually means blocks, editor extensions and custom admin pages, and confirm that the interface is not broken and the browser console shows no errors. On a test copy of the site it goes like this:

1. Make a copy of the site with the same PHP, WordPress and plugin versions as production. If the copy contains shop customer data, anonymise it before copying.
2. Install the Gutenberg release version: wp plugin install gutenberg --version=24.2.0 --activate.
3. In the copy’s wp-config.php, set define( 'SCRIPT_DEBUG', true );. WordPress then loads unminified versions of scripts, including the development build of React, which shows full warnings instead of shortened error codes.
4. In the editor, type React.version in the console and make sure it is 19. If you see 18, one of the active plugins is on the exception list and the test has to be repeated without it.
5. Insert every custom block into a new post, change every setting in the block panel, save, reload the editor and check that the block does not show an invalid content message.
6. Open every plugin settings page and every sidebar the plugin adds to the editor. After 24.2 these panels are in the panels submenu of the options menu.
7. Finally, look at the saved posts on the front end. Dynamic blocks are rendered by PHP, so React does not matter there, but blocks with the Interactivity API and front end scripts need clicking through.

The list for step 5 should cover the blocks the client actually uses, not just the ones that are registered. If the site has a library of dozens of blocks, start with those on the home page, the product page and in forms. General rules for working on a test copy are in my guide to rolling out changes through a staging site, and for a quick check of a single block on a clean install, WordPress Playground is enough.

Report every problem you find with the Gutenberg version number, the React version from the console and the error text. The team asks for reports in the Gutenberg repository on GitHub, and for third-party plugins, with their authors.

#How do notes in the editor margin work?

Until now floating notes and the settings panel could not be open at the same time, and the notes column took space away from the content. In 24.2 the editor reserves a margin next to the editing area and shows notes there, so they stay visible while you switch between blocks and post settings.

In a narrower window each thread collapses to its author’s avatar, and clicking the avatar expands it again. The new notes submenu in the options menu lets you expand, minimise or hide them, and the editor remembers the choice. Three changes reduce the risk of losing work: deleting a note can be undone, an unsent note or reply does not disappear when you select another block, and notes scroll together with the content.

For an editorial team that discusses texts in the editor, this means less switching between panels. For block authors there is one practical effect: the editing area has less room when notes are visible. Blocks with a fixed width or their own layout in the editor are worth viewing with notes open.

The WordPress 7.2 plan announces further changes to notes: a suggestion mode in which a proposed text change can be accepted or rejected, emoji reactions and a separate button for adding a note in the block toolbar.

#What changed in the Navigation and Gallery blocks?

Adding anything other than a page to a menu used to require knowing which block to use, for example a category link or a tag link, and only then searching inside it. Now link search in the Navigation block searches all content types at once and shows the type next to each result. An existing link can be changed from a category to a page without deleting it and adding it again. The same search also shows the blocks the menu accepts, so typing Home finds the home link block.

Results are now sorted by type: posts and pages before categories, tags and media. This order applies to every link search in the editor, not only in menus. On large sites, tags and attachments stop pushing the post you are looking for out of the results. For authors of plugins that add their own content types to link search, this is a reason to check where their results end up.

Global Styles can now style navigation link states (hover, focus, focus visible, active), for now limited to typography. Themes that did this with their own CSS can move some rules to theme.json, but check first which declaration wins.

In the Gallery block, the sort option now also works for galleries of hand-picked images. Sorting newest first, oldest first and alphabetically in both directions orders the images once, and you can still drag them afterwards. The random option is in the same place and shuffles the images on every page load. For sites with full page caching this matters: the random order changes only when the cache is refreshed, not on every visit.

The gallery also gained duotone support. One filter tints every image in the gallery, set in the block or for all galleries on the site in Global Styles. Duotone set on a single image takes priority over the gallery setting. Duotone also arrived in the Media & Text and Video blocks. With product photos, check that a globally set filter does not change colours where the client does not want it.

#What’s new in the Interactivity API?

The new data-wp-html directive renders HTML from state, the same way data-wp-text renders text. It accepts only values marked as trusted with asDangerousHTML(). The example from the release post:

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>

The 7.2 plan explains that the first version renders only values explicitly marked as trusted by the application code, and support for sanitized plain strings will come later. Do not pass anything to asDangerousHTML() that comes from a user or from block attributes without sanitizing it on the PHP side. In the same release the Gutenberg documentation gained a note that block attributes and Global Styles values must be treated as untrusted at render time. If you run a plugin security review, add a search for asDangerousHTML to the list of things a person reads.

The router now exposes state.navigating and state.initiator, so a block knows that client-side navigation is in progress and which block started it. According to the 7.2 plan, this replaces the deprecated pair state.navigation.hasStarted and state.navigation.hasFinished. Blocks with their own loading indicator during navigation are worth rewriting to the new fields before the old ones are removed.

#Are Gutenberg notes real-time collaboration yet?

No. Notes are comments on blocks, read and added at any time. Real-time collaboration is not in the WordPress 7.2 plan. The plan says that, as with 7.1, architectural decisions need more time, so the topic was left out rather than listed and then pulled.

Work continues in the experimental gutenberg-sync-engines plugin, described in the guide to sync engines from 14 October. Three engines are being tested: yjs-server, DE-RTC and intent-log. The plugin requires WordPress 7.0 or newer and the Presence API plugin, and it contains its own slightly modified copy of Gutenberg. So it will not work next to an active Gutenberg plugin, which means the React 19 test and the live collaboration test cannot be done on the same site copy.

Under the guide, the author of the Yjs library, Kevin Jahns, pointed to the server cost:

“Real-time editing generates a lot of small messages. If every one of them has to spin up a PHP worker, load the shared document, verify, merge, and write back to the database, that’s a lot of overhead in communication, processing, and database usage.”

Source: Kevin Jahns’s comment under the guide to sync engines, 15 October 2026

For site owners on cheap shared hosting, this signals that live collaboration may one day need different hosting.

Update, 3 November 2026. The Presence API feature plugin reached 0.20.0 on 1 November (WordPress.org listing; about 10 active installs). The meeting summary of 26 October, published 1 November, says the merge checklist still needs outside user testing and a security audit from outside the repo, and that 3 December is the earliest date for an initial Trac proposal (eight weeks with no breaking API change from 0.17.0). Versions 0.18.4 through 0.20.0 add a logout fix for post locks, keepalive/roomChanged hooks for push relays, and wp_presence_admin_state() so a relay can write the same rows Heartbeat writes. Presence stays a dependency of gutenberg-sync-engines, not a replacement for notes in 24.2/24.3, and it still does not ship real-time co-editing in WordPress 7.2.

#Who should test their blocks before WordPress 7.2?

The test makes sense for every site with custom blocks, editor extensions or settings pages in React, and for authors of plugins and themes that have such elements. A site built only from WordPress blocks and popular, actively supported plugins depends on whether their authors run the test. The Gutenberg team is asking for exactly that now.

If nobody on your team can review the built files and click through the blocks on a site copy, a WordPress developer can do it as a single job, and with ongoing site maintenance testing new Gutenberg versions before updating production is part of the work. Why this kind of review needs a person is also covered in my post on hiring developers who work with AI.

In your request, give the WordPress and PHP versions, the list of plugins with custom blocks, whether the Gutenberg plugin runs on production and whether you have a test copy of the site. Pricing is individual, based on scope. The form is on the contact page.