Gutenberg Shipped React 19, Broke a Bunch of Plugins, and Reverted It in Two Days. That's a Good Thing.

On June 3, 2026, Gutenberg 23.3 shipped with the React 19 upgrade baked in. The release also included a new modal-based media editor, five customizable dashboard widgets, and more work on real-time collaboration. By June 5, the React 19 part was gone — reverted in Gutenberg 23.3.2 after plugins started crashing across production sites. Two days. That is the entire arc of this story, and if you build, maintain, or use WordPress plugins, the fallout window is still open.

What actually broke

The failure was not subtle. When a plugin bundles its own copy of react/jsx-runtime — which many popular plugins do — the elements it creates have a shape that React 19 actively rejects. Not a deprecation warning. Not a console log. A hard crash at render time. The block editor would half-load, admin screens would white-screen, and the only fix was to either downgrade the Gutenberg plugin or deactivate the offending plugin.

This is a real-world consequence of how the WordPress plugin ecosystem works. Plugins are not npm packages. They do not share a dependency tree. Each plugin ships its own bundled JavaScript, and if that bundle includes a copy of React (which the official WordPress scripts make very easy to do), that copy runs alongside the one WordPress core provides. When the core version jumped from 18 to 19, the two copies stopped being compatible. Plugins with their own React 18 runtime were suddenly trying to create elements that the React 19 runtime sitting next door refused to accept.

The specific patterns that React 19 removes are the ones WordPress has been warning about for years: ReactDOM.render() and hydrate() (replaced by createRoot() and hydrateRoot()), unmountComponentAtNode() (replaced by root.unmount()), findDOMNode(), and defaultProps on function components. If your plugin or a dependency in your plugin uses any of those, it will break when React 19 lands for real.

Why the revert was the right call

Some people saw the revert as a failure. It was the opposite. The upgrade plan, published on May 27, was straightforward: ship React 19 in Gutenberg 23.3, use the plugin release as a public testing window, and then land the upgrade in WordPress core with 7.1 in August. The team did exactly that. They shipped it. They watched what broke. They reverted within 48 hours instead of letting the damage spread through the full plugin release cycle. That is how a mature open-source project handles a risky dependency upgrade.

The revert announcement was equally direct. The core team confirmed the upgrade is still happening for WordPress 7.1 — currently scheduled for August 19, 2026 — but the next attempt will include two things the first attempt did not: a compatibility layer for already-released plugins that bundle their own React, and an experimental feature flag so site owners can switch between React 18 and 19 without being forced onto the new runtime.

That compat layer is the key detail. It means the next time React 19 ships in Gutenberg, plugins that bundle React 18 will not immediately crash. They will get a shim that translates between the two versions. But — and this is the important part — the shim is a bridge, not a permanent solution. If you maintain a plugin, the shim buys you time. It does not buy you a pass.

What plugin authors should do right now

You have roughly ten weeks before WordPress 7.1 ships. Here is the honest priority list.

Stop bundling your own react/jsx-runtime. This is the single most common cause of the June 3 crash. If your plugin uses @wordpress/scripts for its build toolchain and you have not customized the webpack externals config, you are probably fine — @wordpress/scripts already treats React as an external dependency provided by WordPress core. But if you are using a custom webpack config, Vite, or any other bundler that inlines React, you need to change that configuration now. The whole point of @wordpress/element as the canonical React surface in WordPress is that it provides a single, shared copy of React. Use it.

Audit your dependencies. Even if your own code does not bundle React, a dependency might. Run grep -r "react/jsx-runtime" node_modules/ in your plugin directory and see what comes up. If a third-party library ships its own React copy, you need to either replace that library, configure your bundler to externalize it, or wait for the library to update.

Test against Gutenberg trunk. The next Gutenberg release that includes React 19 (likely Gutenberg 23.5 or 24.0, depending on timing) will have the compat layer. Install it on a staging site and test every screen your plugin touches — the block editor, admin pages, WooCommerce admin if you are in that ecosystem, and any frontend blocks that use React.

Remove deprecated patterns. Even with the compat layer, plugins that use ReactDOM.render(), findDOMNode(), or defaultProps on function components are running on borrowed time. The compat layer translates at the boundary. It does not fix code that uses APIs React 19 has removed. If your plugin uses those patterns, fix them before August. Not because the compat layer will not work, but because it will not work forever.

The WooCommerce wrinkle

If you run a WooCommerce store, this is not abstract. WooCommerce 10.8 already requires WordPress 6.9, and the next two WooCommerce releases are building against the assumption that React 19 is the admin runtime. Cart blocks, checkout blocks, the new dashboard widgets — all of them are being tested against React 19. Any custom WooCommerce extension your team maintains is, for this purpose, a Gutenberg plugin. The same rules apply: stop bundling React, audit dependencies, test against trunk.

The bigger picture

The React 19 upgrade is a symptom of a larger shift in how WordPress handles its JavaScript stack. For years, WordPress shipped a JavaScript runtime and let plugins do whatever they wanted with it. That freedom is what made the plugin ecosystem explosive. It is also what makes upgrades painful. The @wordpress/element abstraction, the move to treat React as an external dependency, the compat layers — these are all attempts to keep the ecosystem's freedom while adding enough structure that core can evolve without breaking half the directory.

If you have been ignoring the @wordpress/scripts build toolchain and shipping raw webpack bundles, the React 19 upgrade is your signal to stop doing that. The tooling exists. It handles the externals. It works with the WordPress dependency system. The ecosystem is moving toward a model where plugins share a single runtime, and the June 3 crash is what happens when that model meets a plugin that does not participate.

Ten weeks. That is what you have. Update your build config, test against trunk, and stop bundling your own React. The next attempt will be smoother, but only if the plugin ecosystem does its part.