On June 10, 2026, the official WordPress developer blog published "What's new for developers? (June 2026)" — the first full developer briefing since WordPress 7.0 "Armstrong" shipped on May 20. The single most important line in the entire report is just one sentence, yet it deserves the full attention of anyone whose livelihood depends on WordPress: the React 19 upgrade was emergency-reverted in Gutenberg on June 5. The cause was not core. It was the plugins. For the huge number of Taiwanese business sites still running on WordPress, that one line dictates the maintenance schedule for the next six months.
Zoom out on the timeline and this is no ordinary rollback. In 2018, WordPress 5.0 introduced the Gutenberg block editor, embedding React deep inside the world's largest CMS; the project simultaneously shipped the @wordpress/element abstraction layer, hoping plugin authors would never depend on a specific React version directly. React 19 has been stable since December 2024. The Core team waited roughly 18 months and planned to make the jump in one move during the 7.0 cycle — the May 27 dev note even laid out a complete migration checklist for plugin authors. Two weeks after launch, the team announced the revert: multiple plugins ship their own bundled React 18 JSX runtime helpers, and loading them alongside React 19 crashes the editor outright. The strategy changed from "all at once" to "a more gradual upgrade across the 7.1 cycle."
The blast radius extends far beyond Gutenberg itself. According to W3Techs, WordPress powers roughly 43% of all websites; a large share of Taiwanese SMEs' corporate sites, campaign pages, and storefronts live inside this ecosystem. Every item on the dev note's mandatory-change list — deprecate ReactDOM.render() and hydrate(), switch to createRoot()/hydrateRoot(), remove unmountComponentAtNode(), avoid findDOMNode() — points to the same fact: some plugin on your site may still be written in 2022-era React, and that debt will come due. Worse, clients rarely distinguish between core and plugin responsibility — when the site breaks, the first phone call goes to the agency maintaining it, not the plugin author.
Below you will find a CLI to detect which plugins bundle their own React, a render-to-createRoot migration example, a cost comparison of four response strategies, and one judgment that runs against the mainstream: the real risk was never that WordPress core is too old. By the end, you should be able to make a clear keep-or-migrate decision for every WordPress site you manage within a week.
Technical details: what was reverted, and what plugins must change
First, the version coordinates: WordPress 7.0 requires PHP 7.4 minimum, officially recommends 8.3, and fully supports PHP 8.5 (see the official PHP support clarification); Gutenberg 23.3 shipped alongside this month's report. The revert was triggered by React 19's API breaking points — the official React 19 Upgrade Guide and the WordPress dev note converge on the same mandatory changes. Start by hunting down plugins that bundle their own React:
# Run from the WordPress root: find plugins whose build output contains react-dom / jsx-runtime
grep -rl --include="*.js" -e "react-dom" -e "jsx-runtime" wp-content/plugins
| cut -d/ -f3 | sort -u
# Cross-check plugin versions and available updates with WP-CLI
wp plugin list --fields=name,version,update_version --update=availableFor every hit, check whether the code still uses the legacy APIs, and migrate as follows:
// React 18 style (removed in React 19)
import ReactDOM from 'react-dom';
ReactDOM.render(<App />, container);
ReactDOM.unmountComponentAtNode(container);
// React 19 style
import { createRoot } from 'react-dom/client';
const root = createRoot(container);
root.render(<App />);
root.unmount();
// The correct approach for WordPress plugins: import from @wordpress/element
// and let core manage the React version centrally
import { createRoot } from '@wordpress/element';Other threads worth following in the monthly report: the call for testing on client-side media processing (VIPS compiled to WASM generates image sub-sizes directly in the browser, supporting AVIF, WebP, HEIC, Ultra HDR, JPEG XL, and even GIF-to-video conversion); Gutenberg 23.3 makes the media editing modal the default cropping experience and introduces pseudo-state styles for individual block instances; wp-now is officially deprecated in favor of Playground CLI; and the collaborative editing outreach effort for 7.1 has kicked off. Core is moving fast — keep that in mind, it foreshadows the opinion section below.
Immediate actions for three kinds of readers
- Engineers: run the grep above on staging and list every plugin bundling react-dom; in your own plugins, switch imports to @wordpress/element, complete the createRoot migration, and while you are at it check ref callback return values and TypeScript types.
- Tech leads: add "plugin JS dependencies" to your asset inventory, classify each plugin as officially maintained / commercially licensed / abandoned, put abandoned ones that bundle React on the replace-before-7.1 list, and freeze automatic major-version updates in production.
- Founders and agencies: audit every WordPress site under your maintenance contracts and proactively send clients a 7.x compatibility notice — this is a natural entry point for converting one-off builds into recurring maintenance revenue.
Comparison and trade-offs: four response strategies
| Strategy | Pros | Cons | Migration cost |
|---|---|---|---|
| Wait for the official gradual 7.1 upgrade | Zero effort, follows the official cadence | Control sits with plugin authors; 7.1 may hit the same wall | Near zero, but the risk is deferred |
| Update plugin builds yourself | Pays the debt down now, fully controllable | Only works for plugins you own or can modify; commercial plugins are off-limits | Roughly 0.5–2 person-days per plugin |
| Pin versions and stop upgrading | Easiest in the short term | Security updates gradually dry up; the debt compounds | Zero now, most expensive once it accumulates |
| Migrate off WordPress to a custom build (e.g. Laravel) | Dependencies fully under your control; predictable long-term maintenance cost | High upfront investment; content workflows must be rebuilt | Roughly a 1–3 month project for a mid-sized site |
What nobody tells you
- Contrarian point one: the revert is a painkiller, not a cure. Plugin authors lose their sense of urgency, and the debt is merely postponed until it blows up again in 7.1. @wordpress/element has never been an enforced rule — commercial plugins actually have an incentive to keep bundling their own React for backward compatibility with older WordPress versions.
- Contrarian point two: the report's headline features are less usable than they look. Client-side media processing is currently enabled by default only in Chromium; Firefox and Safari ship with it off, and devices with 2GB of RAM or less are skipped entirely — Taiwanese e-commerce sites dominated by mobile traffic should not treat it as dependable infrastructure in the short term.
- The dev note's checklist only covers the APIs officially named; page builders and form plugins often run their own React portals and event systems, so runtime conflicts invisible to grep can still exist. The only real insurance is testing on staging.
What happens in the next 3 months
The 7.1 cycle will restart the React 19 upgrade gradually, likely trialed first through the Gutenberg plugin channel; the collaborative editing outreach interviews will shape 7.1's headline features. Indicators worth watching: the volume of React 19-related tickets, whether the changelogs of major form and page-builder plugins start mentioning createRoot, the default on/off status of client-side media processing in Firefox and Safari, and how quickly developers migrate from wp-now to Playground CLI.
FAQ
Will my WordPress 7.0 site break right now?
No. The revert means 7.0 still runs React 18, so the current state is stable. The risk arrives when the upgrade restarts in 7.1: if plugins bundling React 18 still have not updated by then, the editor may crash again. This is the window for taking inventory, not for panic.
How do I find out which plugins bundle their own React?
Use the grep command in this article to scan wp-content/plugins for the strings react-dom and jsx-runtime; for every hit, check the changelog for mentions of React 19 or createRoot. If there are none, email the author or put the plugin on a watchlist.
What are WordPress 7.0's PHP version requirements?
Minimum PHP 7.4, officially recommended 8.3, with full PHP 8.5 support. If your host is still on 7.4, schedule the PHP upgrade and the plugin audit into the same maintenance window and clear two pieces of technical debt at once.
I am a plugin author — what should I do right now?
Switch your React imports to @wordpress/element immediately, drop render(), hydrate(), unmountComponentAtNode(), and findDOMNode(), check ref callbacks and TypeScript types, then run a test pass against nightly using Playground CLI. Do not wait for the 7.1 beta.
My take
The mainstream narrative says WordPress's risk is that "core is aging and will eventually be displaced by headless solutions." This incident proves the opposite: the pace of core modernization — React 19, WASM media processing, Playground CLI, collaborative editing — has already outrun the plugin ecosystem's ability to digest it. The real unexploded ordnance is the plugins' JS dependency debt: a 43% market share means this is the world's largest installed base of JavaScript outside the core team's control. The React 19 revert is not a failure of core; it is the first time this ecosystem debt has been forced onto the balance sheet.
Two implications for ScriptWalker. First, a "WordPress 7.x compatibility health check" can be packaged as a fixed-price maintenance product: scan the plugins, deliver a report, recommend replacements and upgrades — low delivery cost, highly repeatable. Second, when a client's site depends heavily on three or more abandoned plugins that bundle their own React, that is the right moment to propose a custom Laravel migration — what you are selling is not a rewrite, but swapping uncontrollable dependencies for controllable ones. For a health check or a migration assessment:
- Email: [email protected]
- Phone: 0916-224-047
- LINE: @ufv9089p
Sources
- First-hand: What's new for developers? (June 2026) — developer.wordpress.org
- First-hand: React 19 upgrade temporarily reverted in Gutenberg — make.wordpress.org
- First-hand: React 19 upgrade in WordPress (dev note) — make.wordpress.org
- First-hand: Call for testing: client-side media processing — make.wordpress.org
- Third-party: W3Techs — WordPress usage statistics
- Third-party: React 19 Upgrade Guide — react.dev