If you run a WooCommerce store with product blocks and a custom settings screen or two, the phrase React 19 in WordPress sounds like the week your editor breaks. It won’t be that week. WordPress 7.1 ships with React 18.3, the same version your site runs today, and the upgrade now sits behind a checkbox in the Gutenberg plugin.
How it got here changes what you should do. The React 19 dev note on Make WordPress Core from May laid out the whole upgrade and targeted it at WordPress 7.1. In July the team reverted that decision after finding unexpected incompatibilities in how old and new React interact on real sites. React 19 is now an experiment in Gutenberg 23.4+, enabled under Settings, then Gutenberg, then Experiments.
What the revert changed
For anyone maintaining client sites this is a longer runway, and I’d take it. Nothing in 7.1 forces the upgrade on you. The removed APIs the dev note lists (render and hydrate replaced by createRoot, unmountComponentAtNode, findDOMNode, defaultProps on function components, string refs) were deprecated a long time ago. WordPress deprecated its wrappers in 6.2 in March 2023, and React deprecated string refs and legacy context back in 16.3 in 2018. Code still using them has been printing console warnings for years, and the official upgrade guide covers most of the mechanical fixes with codemods.
Old APIs alone wouldn’t have held the upgrade back. The blocker named in the July post is plugins that bundle react/jsx-runtime into their own JavaScript.
Why bundled React is the risk
WordPress wants to hand every plugin the same copy of React. When a build step bundles its own react/jsx-runtime instead of treating it as external, the browser ends up with React 18 inside the plugin and React 19 from core on the same page, so structures built by the old runtime get handed to the new one. The follow-up lists this as the first failure mode, and core cannot shim its way out of it, because the second copy of React lives inside your asset file.
const defaultConfig = require( '@wordpress/scripts/config/webpack.config' );
module.exports = {
...defaultConfig,
// add your tweaks after the spread, not before
};Extend the default config like this and React stays external, so the browser loads the copy WordPress enqueues. Plugins that roll their own webpack config, or use Vite or esbuild without dependency extraction, are the ones core is worried about. For simple blocks you can also skip React entirely and register server-rendered blocks in PHP, which sidesteps the question.
The old-API side still matters, to be fair. Plenty of store plugins haven’t been rebuilt since 2019. The compat layer in @wordpress/element polyfills some of it, findDOMNode included, so those keep working without anyone running a codemod. But plugins with an active build pipeline, which is most custom agency work, can fix the bundling problem now, before any deadline exists.
How to test React 19 in WordPress safely
None of this needs production. On a staging copy:
- Install the Gutenberg plugin, 23.4 or newer.
- Open Settings, then Gutenberg, and tick the React 19 experiment.
- Set SCRIPT_DEBUG to true in wp-config.php so warnings are loud.
- Click through every React surface you own: the editor, product blocks, checkout blocks, custom admin pages.
- Watch the console, and test anything that renders inside iframes, since that area changed subtly.
There is also work underway to catch the bundled jsx-runtime problem automatically in Plugin Check. Once that check lands, run it against every custom plugin you ship, because that is the one failure mode WordPress cannot fix for you.
What I’d check this week
On a client store, I’d search the plugin build folders for a second copy of React before touching any deprecated API, since bundling is what delayed React 19 in WordPress. It’s a short job per site, and much easier now than the week core ships the upgrade. If you’re not sure what your plugins ship, send me a build folder or a plugin zip and I’ll tell you whether it bundles its own React.
