June 10, 2026 — The monthly developer roundup landed today on the WordPress Developer Blog, and it reads like a status report on everything publishers have been tracking since 7.0 “Armstrong” shipped: the media pipeline is moving into the browser, the React 19 upgrade got pulled back for repairs, and real-time collaboration — which missed the 7.0 train — now has an organized push toward 7.1. For media organizations, this month’s items are less about new toys and more about timing: what to test now, what to audit on a longer runway, and where to get a newsroom’s requirements into the process early.
Key Themes
- Client-side media processing moves image sub-size generation into the browser via a VIPS/WASM pipeline — with constraints (Chromium-only, CSP, low-RAM bypass) that enterprise publishers specifically need to test.
- The React 19 upgrade was temporarily reverted after plugins bundling React 18 runtime helpers crashed editors — the compatibility audit stands, but the deadline moved to WordPress 7.1.
- Real-time collaboration did not ship in 7.0; a new outreach effort is recruiting testers for the 7.1 cycle — an open door for newsroom workflows to shape the test matrix.
- Per-block style states keep compounding: pseudo-states on single block instances join responsive styles, with a dedicated 7.1 iteration now tracked.
- Platform housekeeping worth a ticket: PHP 8.5 is now fully supported (8.3 recommended), wp-now is deprecated in favor of Playground CLI, and a Unicode email proposal is open for feedback.
Jump to: 🖼️ Media Processing · ⚛️ React 19 Pause · 👥 Collaboration · 🎨 Style States · 🧪 Playground · 🔧 Housekeeping · 💡 Takeaways
🖼️ Media Processing Moves Into the Browser
A call for testing went out June 4 for client-side media processing: image sub-size generation running in the browser through a VIPS/WASM pipeline, with the server as fallback. The feedback scope covers the formats that matter to modern image workflows — AVIF, WebP, HEIC, Ultra HDR, JPEG XL — plus GIF-to-video conversion, large-image handling, and fallback behavior.
The constraints are as important as the feature: it’s active in Chromium only (disabled by default in Firefox and Safari), skipped on devices with 2GB of RAM or less, and bypassed on slow connections or when a restrictive worker-src Content Security Policy is in place.
Why this matters: Media organizations are the heaviest upload workloads WordPress hosts — photo desks pushing hundreds of images a day, each fanning out into a dozen sub-sizes of server work. Moving that to the uploader’s browser cuts server CPU exactly where publishers feel it, and first-class AVIF and JPEG XL support feeds straight into Core Web Vitals and CDN-bill conversations. The catch is in the fine print: enterprise publishers are precisely the organizations running restrictive CSPs, which silently bypass the new pipeline. This is a joint test for the photo desk and the platform team — run it against your actual security headers before assuming the benefit applies to you.
⚛️ The React 19 Pause
An update to a story from this morning’s Gutenberg 23.3 recap: the React 19 upgrade was temporarily reverted in Gutenberg on June 5. The cause is instructive — plugins shipping compiled JSX had bundled React 18’s runtime helpers, and those helpers crashed against React 19. An incremental approach is now planned for the WordPress 7.1 cycle.
The required changes haven’t changed: move off render() and hydrate(), replace unmountComponentAtNode(), avoid findDOMNode(), check ref callback behavior, and review the TypeScript updates. The May 27 dev note remains the canonical checklist.
Why this matters: The deadline moved; the work didn’t. The revert is, if anything, validation of the audit — it was plugin code carrying legacy React patterns that broke the upgrade in the wild, exactly the category of risk flagged for enterprise stacks with years of custom editor code. Publishers just got a grace period measured in one release cycle. The right response is to keep the audit moving at the same pace and arrive at 7.1 with nothing left to find. Priority targets per the dev note: plugins shipping compiled JSX, anything using @wordpress/element, and code reaching into private editor internals.
👥 Collaboration’s Road to 7.1
Real-time collaboration did not ship in WordPress 7.0. On June 3, the project announced a collaborative editing outreach effort for the 7.1 cycle: structured testing on the latest Gutenberg plugin, with production workflows explicitly not yet supported. The compatibility surface being probed is broad — plugins that store editor state, use meta boxes, modify block editor data, or depend on save behavior.
Why this matters: Newsrooms are the canonical use case for co-editing, and outreach phases are when requirements get baked in. A distributed editorial team’s reality — breaking-news handoffs, edit locks during legal review, a producer and a writer in the same draft at deadline — is exactly what the test matrix needs and rarely gets. Publishers who volunteer a staging environment now get two things: early warning on how their editorial plugin stack behaves under sync, and a voice in what “working” means before the feature hardens. The alternative is adapting to someone else’s definition in 7.2.
🎨 Style States Keep Compounding
The block style states arc — responsive styles in 23.2, per-instance overrides in 23.3 — picked up two more pieces this month:
- Pseudo-states on single block instances (#76491):
:hover,:focus, and:visitedstyles on one block without touching every instance site-wide — the standardization sought in #38277 since 2022. - A dedicated 7.1 iteration (#77817) tracking responsive style states toward core, with layout responsive styles already in (#78543).
Why this matters: The dependency list in the tracking issue — theme.json presets, layout presets, block supports, custom responsive controls — is a map of what design-system teams should be watching. Multi-brand publishers with custom breakpoint tooling built into their themes are the ones with migration exposure here; the governance question from the 23.3 recap (how much per-instance freedom to allow) now extends to interaction states too.
🧪 Playground Grows Into Real Tooling
A quiet but meaningful tooling shift: wp-now is deprecated as of June 8, with Playground CLI the recommended path for local WordPress environments. Around it, Playground shipped v3 of the PR Preview GitHub Action, a Sites API with persistent saved sites, autosave-restore UX, and a guide to running PHP frameworks in the browser.
Why this matters: Publisher dev teams using wp-now in local setups or CI have a migration ticket to file — small, but the kind that bites when ignored. The more interesting piece is the PR Preview action: a Playground link on every pull request means editorial stakeholders can click into a working preview of a block or theme change without a staging deploy. For teams where “can someone from editorial sanity-check this?” is a deploy-queue bottleneck, that’s a real workflow upgrade.
🔧 Platform Housekeeping
PHP support, clarified. The “beta support” label for PHP 8 is retired: WordPress 6.9 and 7.0 fully support PHP 8.5, the minimum is PHP 7.4, and the recommended floor is 8.3. Update CI matrices and internal docs that still treat newer PHP as experimental.
Unicode email proposal. A feedback period is open on extending Unicode support in email addresses, usernames, and slugs — touching is_email(), sanitize_email(), storage, and normalization. Publishers running subscription and membership stacks that validate or deduplicate email addresses should read it with their identity flow in mind.
Abilities API follow-ups. A steady stream of Core refinements landed: lifecycle and validation filters, filtering for wp_get_abilities(), keyword allow-listing, and REST schema hardening. Anyone building on the API — including the AI governance layer covered in the WordPress AI 1.0.0 recap — should re-verify against trunk before relying on earlier behavior.
Dashboard experiment. The customizable dashboard added five widgets (Site Health, News, Events, Quick Draft, site preview) plus layout polish — still no stable admin extension API, still worth watching (#77616).
Accessibility polish. Admin color-scheme contrast improvements, frontend toolbar focus outlines, and high-contrast button fixes landed in core trunk — relevant to anyone shipping custom admin screens against compliance requirements.
💡 Takeaways
- Test client-side media processing against your real CSP. The pipeline silently falls back on restrictive
worker-srcpolicies — enterprise publishers should verify they actually get the benefit before counting on it. - Keep the React 19 audit moving. The revert bought one release cycle, not a cancellation — clear string refs,
ReactDOM.render, and bundled JSX runtime helpers before the 7.1 re-landing. - Volunteer a newsroom workflow for collaboration testing. The 7.1 outreach effort is the window to get editorial realities — handoffs, locks, deadline co-editing — into the test matrix.
- Update your PHP posture. PHP 8.5 is fully supported and 8.3 is the recommended floor — retire “beta” caveats from CI configs, runbooks, and support documentation.
- File the wp-now migration ticket. Local and CI environments should move to Playground CLI — and look at the PR Preview action while you’re in there; it may remove a staging bottleneck for editorial review.
The full roundup is available on the WordPress Developer Blog.