Gutenberg React 19 Revert: What Plugin Authors Should Do Now

I have lived through enough WordPress upgrades to know the pattern. A new dependency lands, the demos look clean, the release notes use words like “incremental” and “backwards compatible”, and then a few thousand production sites quietly catch fire on a Tuesday. That is roughly what just happened with React 19 in Gutenberg, and the core team did the right thing about it.

If you ship plugins, maintain a client site, or just bumped the Gutenberg plugin this week, this is the kind of news you want to read carefully rather than skim. The good part is that the WordPress project handled it with the maturity I expect from this ecosystem: they upgraded, they watched what broke, they reverted, and they wrote down the new plan in public.

Here is what actually happened, what it changes for the next two months, and what I would do about it if I were running a real WordPress shop today.

What is actually new

On May 27, 2026, the core team published their plan to upgrade WordPress to React 19. The plan was simple: ship React 19 in Gutenberg 23.3, use the full plugin release cycle as a public testing window, and then land the upgrade in WordPress core with version 7.1 in August. The post explicitly called out the deprecated patterns removed in React 19 — ReactDOM.render() and hydrate() (replaced by createRoot() and hydrateRoot()), unmountComponentAtNode() (replaced by root.unmount()), findDOMNode(), and defaultProps on function components.

On June 3, 2026, Gutenberg 23.3 shipped with the React 19 upgrade in place, alongside a new modal-based media editor, five new customizable dashboard widgets, and continued work on real-time collaboration.

Two days later, on June 5, 2026, the team posted that they were temporarily reverting the React 19 upgrade in Gutenberg 23.3.2. The reason was concrete, not theoretical: many plugins built against React 18 were crashing on the new runtime. The specific failure mode is worth understanding — plugins that bundle their own react/jsx-runtime helper produce elements that React 19 actively checks and rejects, because the element shape changed between versions. So it was not a soft warning. It was a hard reject at render time.

The team is not abandoning the upgrade. The post says clearly: “We continue to be committed to doing the upgrade in WordPress 7.1.” What changes is the path to get there. The next attempt will include a compat layer for already-released plugins and an experimental feature flag to switch between React 18 and React 19, so plugin authors and site owners can test the new runtime without being forced onto it overnight.

Why it matters for WordPress and WooCommerce people

If you are a site owner, the practical effect is that you should now update the Gutenberg plugin again — version 23.3.2 puts the editor back on React 18 and restores compatibility with the plugins you already have installed. If you were one of the people who saw a half-broken block editor or admin screen between June 3 and June 5, you were not imagining it. You were running real software at the moment the runtime contract changed.

If you are a plugin author, the revert is a gift, not a reprieve. WordPress 7.1 is currently scheduled for August 19, 2026 according to the WordPress roadmap. That gives you roughly ten weeks to stop bundling your own react/jsx-runtime and start treating @wordpress/element as the canonical React surface in admin and editor contexts. The next attempt will land with a compat layer, but compat layers exist to soften migration, not replace it.

If you run a WooCommerce stack, this matters indirectly but materially. WooCommerce 10.8 already requires WordPress 6.9 or greater, and the next two Woo releases will increasingly assume the React 19 runtime in admin screens, Cart and Checkout blocks, and the new dashboard widgets. Any custom Woo extension your team maintains is, for this purpose, a Gutenberg plugin too.

And if you have ever wondered why I keep saying WordPress wins on maturity, this is exactly the reason. A platform that did not care about backwards compatibility would have shipped the breakage, blamed plugin authors, and moved on. WordPress shipped the breakage, looked at the production impact within forty-eight hours, reverted, and wrote down a better plan in public. That is governance. That is what the page rank history, the redirections, the revisions, and the plugin ecosystem are really sitting on top of.

What I would do (or not do) about it

Here is the short list I am working through with our team this week.

• Update Gutenberg to 23.3.2 on staging first. The revert is in. If you froze the plugin at an older version because you saw crashes, you can move forward again — but verify on a clone before touching production.
• Audit every custom block and admin screen for the deprecated React APIs. Search your codebase for ReactDOM.render, hydrate, unmountComponentAtNode, findDOMNode, string refs, and defaultProps on function components. None of these will work when the React 19 upgrade returns.
• Stop bundling react and react/jsx-runtime in plugin builds. If your build tooling pulls them into your plugin output, you are the failure mode the core team described. Use the WordPress-provided React via @wordpress/element and let the editor own the runtime version.
• Enable SCRIPT_DEBUG on staging. The detailed React warnings are how you find out which screen will break before your users do.
• Do not roll back to an older Gutenberg version on production. The 23.3.2 line is the safe one. Going backwards introduces a different class of incompatibility.
• If you sell a plugin, ship a compatibility release before 7.1. The 7.1 release window is the right deadline to internalize, even if a compat layer is on the way. Two months is enough time if you start this week.

The thing I would not do is panic-rewrite anything that does not actually use the removed APIs. React 19 keeps most patterns intact — function components, hooks, suspense, refs the modern way — all of it works. The breakage is specific and the migration is mechanical.

Two months of breathing room is more than most ecosystems give you for a runtime upgrade of this size. Use the time, ship the fix, and let WordPress 7.1 land cleanly when August comes.