Gutenberg React 19 Revert: What Plugin Authors Should Do Now

🇹🇷 Türkçe: Bu yazının Türkçesini oku →

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.

I have watched a runtime pull the rug before

A runtime that quietly changes the shape of the thing your code hands it, and then rejects what used to work, is not a new kind of pain. I built a chunk of my early career on Macromedia Flash and ActionScript — multi-user games, virtual shows, interactive CD-ROM front ends, all of it riding on a player that Adobe eventually walked into the sea. The lesson from Flash’s death was not “avoid dependencies”, because you cannot. The lesson was subtler and it is exactly the lesson here: the projects that survived a runtime shift were the ones that had not welded their own copy of the runtime into the build. The ones that bundled their own everything, that reached past the platform’s provided libraries and shipped private versions, were the ones that shattered the day the contract underneath them moved.

That is the whole story of the bundled react/jsx-runtime failure in one sentence. A plugin that ships its own React is a plugin that has quietly opted out of the platform’s ability to upgrade the runtime under it safely. Flash punished that the hard way, with no revert and no compat layer. WordPress just gave you both, plus ten weeks. That difference — a governance layer that can pull the release back within forty-eight hours versus a vendor that simply ends support — is the difference I keep pointing at when I say WordPress wins on maturity.

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.

Here is the one-line test I would give any developer on the team: if your build output contains its own copy of React, you are carrying the runtime instead of borrowing it, and you are on the wrong side of this change. Fix that first. Everything else on the list is downstream of getting the runtime ownership right.

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.