Update the Gutenberg plugin on a site with custom editor code and you may open the post editor to find a plugin’s sidebar panel gone. The console shows warnings about defaultProps on function components, or a string ref that no longer resolves. Gutenberg 23.3 is where that starts, because the editor bundle is now built against React 19.
The release post on Make WordPress Core has the full changelog, and most of it is interface work: a modal media editor as the default crop experience, responsive styles for individual blocks, and a lot of polish on an experimental dashboard. The React 19 upgrade is the change most likely to generate support tickets, so that’s where I’d start.
Why editor plugins break after this update
Gutenberg bundles its own React, and 23.3 bumps that bundle to React 19 (pull 61521). The release notes say most code keeps working unchanged, which matches what the React team documented: the removals are a short list. String refs, ReactDOM.render fallbacks, and defaultProps on function components are gone.
If your plugin registers blocks with registerBlockType and sticks to the standard @wordpress/components set, you’re probably fine. The risk sits in older code that renders its own React roots, especially modals and settings pages built a few years ago. This grep finds the usual suspects:
grep -rn "ReactDOM.render\|defaultProps\|createRoot" assets/src --include="*.js" --include="*.jsx"Everything ReactDOM.render touches, move to createRoot. defaultProps on a function component becomes a default parameter or a destructured fallback. React’s upgrade post lists the rest, and it’s short enough to read in one sitting. I wrote about React 19 arriving as a Gutenberg experiment earlier, and this release is that work landing for everyone running the plugin.
What responsive block instance styles mean for themes
23.2 put responsive styles into Global Styles, so a theme could define different values per viewport in theme.json. 23.3 extends the Block Style States API down to single block instances (pull 78384), layout styles included (pull 78543). A user can now give one specific block a different border, color, or layout per breakpoint without touching custom CSS.
For theme authors this cuts both ways. The mobile CSS you ship in style.css still loads, but a user who sets per-instance responsive values now has two rules competing for the same element, and the editor output tends to win on specificity. My rule is to keep responsive values in theme.json wherever the feature supports them, and save custom CSS for the pieces the editor will never control. If you missed it, Gutenberg 23.2 brought real responsive design to the Site Editor, and this is the continuation.
What ships in Gutenberg 23.3, and what stays an experiment
The media editor modal is the new default crop experience, and it isn’t experimental. The Crop button stays as the entry point, but freeform and aspect-ratio cropping, flip, rotation, and metadata editing now live in one modal. Clients will notice, mostly in a good way.
The customizable dashboard is the opposite case. Welcome, Quick Draft, Activity, Site Health, and Site Preview widgets on a grid or masonry layout, all behind WP-Admin, Gutenberg, Experiments, New Dashboard experience. It changes fast enough that I wouldn’t build against it. Turn it on a test install, look around, and leave it there. I haven’t seen how third-party widgets register into it yet, so I’d promise clients nothing.
Real-time collaboration got proper error handling in this release: the connection lost modal now appears when /wp-json/wp-sync/v1/updates passes its 16 MiB payload limit, and a protocol mismatch gets a named PROTOCOL_MISMATCH error instead of silence. And the image block finally has a Mark as decorative toggle, so decorative product shots stay out of screen reader output.
All of this applies only to sites running the Gutenberg plugin. Core users get none of it until the pieces merge into a WordPress release, so check what a site runs before worrying about React 19. Test on staging with the full plugin list before touching production, because an editor plugin that uses removed patterns breaks loudly mid-edit. If you maintain editor plugins and want a second pair of eyes on the React side before an update reaches client sites, that’s work I do; send me the repo and I’ll flag what React 19 removed.
