Sorting the WordPress June 2026 update into work and noise

The usual advice after a month like June is to read the roundup, then test everything. I don’t do that. The WordPress June 2026 update on the Developer Blog covers a new media modal, a browser-side upload pipeline, a React revert, theme style states, Playground changes, and a dashboard experiment. Roughly half of it touches code I maintain this week. The rest is worth knowing, and it doesn’t earn a staging pass yet.

So this is the split I use: what gets tested now on real sites, and what gets filed until it’s closer to shipping. If you maintain client plugins and stores, the sorting matters more than the reading, because June moved a React deadline closer.

What to test now from the WordPress June 2026 update

1. Audit your React bundle, even with the revert in

The biggest June item for plugin authors is the React 19 rollback. Gutenberg 23.3.0 shipped React 19, and several plugins that bundle their own React 18 JSX runtime helpers crashed alongside it. The team reverted in 23.3.2. The revert post explains the failure mode: React 19 actively rejects elements produced by the React 18 runtime, so one plugin shipping its own jsx-runtime can take the whole editor down. Core still wants React 19 in WordPress 7.1, this time behind an experimental flag with a compat layer for already-released plugins.

That makes the audit you’ve been postponing the cheapest it will ever be:

grep -rn --include='*.js' -E "unmountComponentAtNode|findDOMNode|ReactDOM\.(render|hydrate)" assets/

# Does your build ship its own JSX runtime?
grep -rl "jsx-runtime" build/ | head

The upgrade note lists the other removals worth searching for: render(), hydrate(), ref cleanup, and props changes. Plugins built entirely on @wordpress/element are mostly fine here, since the crashes came from shipped, compiled JSX. I’m not sure how the promised compat layer will treat string refs, so I’d fix them now rather than wait for the flag. I wrote up the rollback when it landed if you want the longer version.

2. Upload real images, then check your CSP

Client-side media processing is the most concrete call for testing this cycle. It runs a VIPS/WASM pipeline in the browser to generate image sub-sizes and falls back to the server when it can’t. The call for testing wants feedback on AVIF, WebP, HEIC, JPEG XL, and GIF-to-video.

The limits matter more than the feature. It’s Chromium only for now, disabled by default in Firefox and Safari, skipped on devices with 2GB RAM or less, and bypassed on slow connections or when a restrictive worker-src Content Security Policy blocks the worker. That CSP limit is the one that will bite on WooCommerce stores, where hardening plugins and host firewalls often ship locked-down headers. Fast uploads in your browser prove nothing about your client’s staff until you know what their CSP allows.

Related, and already shipped: the media editor modal is the default crop experience in 23.3. If a plugin customizes image editing or reads attachment metadata, run the crop flow with keyboard and touch, not just the mouse.

3. Fix the PHP labels in your readmes and CI

Core retired the “beta support” label for PHP 8. WordPress 6.9 and 7.0 are documented as fully supporting PHP 8.5, the minimum is PHP 7.4 as of 7.0, and the recommended version stays 8.3. If your readme, your hosting requirements page, or your CI matrix still treats PHP 8.x as experimental for WordPress, that’s wrong now, and it’s the kind of wrong that surfaces in presales replies.

What I’d park until it settles

4. Pseudo states on single block instances

Gutenberg 23.3 can style :hover, :focus, or :visited on one instance of a block without changing every instance, which closes an issue that sat open for years. Useful, and I’d still keep state styles in theme.json for client themes. Per-instance hovers drift: one CTA gets its own hover color, and three months later nobody remembers why. The responsive style states work keeps moving toward 7.1, so if your themes lean on theme.json presets and layout presets, watch the tracking issue rather than guessing. My pre-update checklist for 23.3 still covers this release.

5. Collaborative editing outreach

The outreach effort for 7.1 has started. It’s worth twenty minutes if your plugin stores editor state, registers meta boxes, or depends on save behavior. Install the latest Gutenberg on a copy, run your normal editor workflow, and report what feels off while the team is still asking. Don’t build anything against it.

6. wp-now deprecation and the Playground side

wp-now is deprecated in favor of Playground CLI. If it’s part of your local workflow, move now, before muscle memory makes the migration annoying. The saved Playgrounds and Sites API work is good news for demos and support screens, and you can now boot historical versions like WordPress 0.7, but none of it changes client sites this month.

One last markup change to fold into a maintenance pass: WordPress 7.0 removed the default “Posts by Author” title attributes from author post links and from wp_list_authors(), so any test comparing that output needs a small update. Between that and the grep above, sorting June across a typical plugin set is about a day of work. If you’d rather hand the triage to someone who does this every cycle, that’s work I take on.

author avatar
Ahmad Wael
I'm a WordPress and WooCommerce developer with 15+ years of experience building custom e-commerce solutions and plugins. I specialize in PHP development, following WordPress coding standards to deliver clean, maintainable code. Currently, I'm exploring AI and e-commerce by building multi-agent systems and SaaS products that integrate technologies like Google Gemini API with WordPress platforms, approaching every project with a commitment to performance, security, and exceptional user experience.

Leave a Comment