React 19 in WordPress 7.1 won’t touch your plugin if you already load React the way core hands it over, and it might if you bundle your own copy. The June 3, 2026 dev chat agenda on Make WordPress Core is a quiet one, but it lists the upgrade to React 19 as targeted for WP 7.1. The item that changes my build habits sits in the comments: Mikey Binns points out that the @wordpress npm packages are no longer tagged per WordPress version, so matching your local packages to what a live site runs just got harder.
Whose React does your plugin load?
Editor code has a standard path. You build with @wordpress/scripts, the dependency extraction webpack plugin rewrites your imports to the site’s script handles, and WordPress hands your code whatever React it ships. Today that’s React 18; after the upgrade it’s React 19, and your bundle never carries React itself. The tradeoff is that you inherit the site’s version, so your code has to keep working across both. Most editor code is fine here because it never touches the removed APIs.
// webpack.config.js
const DependencyExtractionWebpackPlugin =
require( '@wordpress/dependency-extraction-webpack-plugin' );
module.exports = {
plugins: [ new DependencyExtractionWebpackPlugin() ],
};The other road is bundling react and react-dom yourself and never calling wp.element. You get identical behavior on any host and any WordPress version, which is why standalone dashboards and front-end widgets often do it. The cost is a second React on pages where the editor also runs. Two copies don’t always break things, but they do once components cross between them, and debugging that is painful because nothing fails at load time.
My split is straightforward. Anything that renders inside the editor, blocks and sidebar panels included, uses the core packages. A self-contained widget on the front end that never touches the block editor can bundle its own. Store owners feel that second copy on slow connections more than developers do.
Whichever side you’re on, pin your @wordpress package versions and check them against what shipped in the WordPress version you support. With the per-version tags gone from npm, that check is manual now, and it’s the sort of thing that quietly produces code written against an API the live site doesn’t have.
What to check before 7.1
The new version removed a batch of old APIs, and the upgrade guide on react.dev has the complete list. The ones worth grepping a plugin codebase for:
- ReactDOM.render and unmountComponentAtNode, already replaced by createRoot in 18
- string refs
- defaultProps on function components
- propTypes imported from the react package
forwardRef still works in 19; it’s deprecated rather than removed, and ref as a prop is the new default. I wouldn’t rewrite working forwardRef code for 7.1. The practical test is to install a current Gutenberg build, switch on the experiment, and click through your plugin’s screens on staging. Gutenberg shipped React 19 behind an experiment first, which is a good way to learn what breaks before every site gets it.
If you maintain editor plugins and want this settled before the 7.1 rollout, it’s the kind of work I take on: audit the build, fix the dependency extraction setup, and test against the experiment build. Point me at the repository and I’ll tell you which side of the bundling question you’re on.
Don’t act on a targeted milestone alone, though. Targets move, and interop details have shifted late in past majors. When the first 7.1 beta lands, run your plugin against it on a real staging copy before you call anything ready, and pin the Gutenberg version you test with, since I’m not sure the experiment flag will survive to RC.
