WordPress Is Moving to React 19. Your Plugins Will Break.

On May 27, 2026, Jarda Snajdr published the React 19 dev note on Make WordPress Core. The post was quiet. The implications are not. WordPress 7.1 ships Beta 1 on July 15 — two days from now — and it includes the full React 18-to-19 migration. If your plugin touches the block editor, the admin UI, or anything that imports from @wordpress/element, you have roughly five weeks before 43 percent of the web picks up a new React version that removes APIs your code probably still uses.

WordPress 6.6, released in June 2024, shipped React 18.3 with deprecation warnings. That was the polite phase. The warnings told you which functions were going away. React 19 is the phase where they are actually gone.

Four APIs that no longer exist

The removals are not surprises. They have been deprecated since WordPress 6.2 in March 2023. But deprecated and removed are different states, and the jump from one to the other is where plugins break.

ReactDOM.render() and ReactDOM.hydrate() are gone. If your plugin mounts a React component into the admin — a settings page, a meta box, a custom block editor panel — and you are still calling render(), it will fail silently or throw. The replacement is createRoot():

// Before.
import { render } from '@wordpress/element';
render( <App />, document.getElementById( 'root' ) );

// After.
import { createRoot } from '@wordpress/element';
const root = createRoot( document.getElementById( 'root' ) );
root.render( <App /> );

ReactDOM.unmountComponentAtNode() is also removed. Use root.unmount() instead. If your plugin dynamically mounts and unmounts components — a modal, a sidebar panel, a conditional UI element — this one catches you.

findDOMNode() is removed from the react-dom package. WordPress is shipping a polyfill through @wordpress/element as a transition aid, so code that calls findDOMNode through the WordPress package will still work for now. But the polyfill is a bridge, not a permanent solution. Migrate to refs.

defaultProps for function components is no longer supported. If your component defines defaults through the static property, switch to ES6 default parameters:

// Before.
function MyComponent( { size } ) {
    return <div style={ { width: size } } />;
}
MyComponent.defaultProps = { size: 100 };

// After.
function MyComponent( { size = 100 } ) {
    return <div style={ { width: size } } />;
}

This one is easy to miss because it does not always throw. It just silently stops working, and your component receives undefined where it used to get a default value.

Three behavior changes that bite harder

The removed APIs are mechanical fixes. The behavior changes are where bugs hide.

The inert attribute is now a boolean. If your code sets inert="" or inert="true" as a string, React 19 treats it differently. Update to <div inert /> or <div inert={true} />. This matters if your plugin disables interactive elements during loading states or form submissions.

Ref callbacks can now return cleanup functions. This is a new pattern — React 19 treats the return value of a ref callback as a cleanup function, similar to useEffect. If your existing ref callbacks happen to return something other than undefined, React will try to call it as a cleanup function when the element unmounts. This is the kind of bug that shows up as a cryptic error in production while working fine in development.

forwardRef is technically deprecated. Function components can now accept ref as a regular prop directly. forwardRef still works, but the pattern is on its way out. You do not need to change this today, but new code should skip forwardRef entirely.

What to do before August 19

The timeline is tight. Beta 1 is July 15. Release Candidate 1 is August 5. The final release is August 19 at WordCamp US. That gives you one beta cycle and one RC cycle to test.

Search your plugin codebase for ReactDOM.render, ReactDOM.hydrate, unmountComponentAtNode, findDOMNode, and defaultProps. If you find any of them, fix them now. The React 18.3 deprecation warnings have been shipping for two years — if your plugin was still using these APIs as of WordPress 7.0, the warnings were already firing for every user on the latest WordPress version. The fact that users did not report them does not mean they were not happening. It means users ignore console warnings.

Spin up a WordPress Playground instance at playground.wordpress.net and load the Gutenberg plugin with React 19. Test every screen your plugin renders. Check the browser console for errors. The Playground integration means you can test without touching a production site, and it takes about thirty seconds to spin up.

If your plugin depends on third-party React libraries, check their compatibility. Some libraries — particularly older UI component packages — still use findDOMNode internally. The WordPress polyfill covers @wordpress/element, but it does not cover libraries that import directly from react-dom.

The bigger picture

React 19 is not just a cleanup release. It introduces ref callback cleanup, forwardRef deprecation, and new concurrent rendering patterns that will shape how WordPress admin UI is built over the next two years. The removals are the immediate pain. The new patterns are the long-term payoff. If you are starting a new plugin today, build on React 19 patterns from day one. If you are maintaining an existing plugin, fix the removals this month and adopt the new patterns gradually.

The WordPress core team gave developers two years of deprecation warnings. The grace period ends August 19.

---

Sources: React 19 Upgrade in WordPress — Make WordPress Core, May 27, 2026. What's new for developers (July 2026) — WordPress Developer Blog, July 10, 2026.