WordPress 7.1: WASM Media, React 19, Classic Block End

The WordPress 7.1 roadmap landed on June 19, and the headline is not the new Tabs block or the waveform playlist feature. It is the deadline. Beta 1 hits July 15. Release is August 19. If you maintain custom blocks, ship a plugin that touches the editor, or still let users insert Classic blocks, the clock is running. WordPress 7.0 introduced the new rules. WordPress 7.1 removes the safety nets.

Client-Side Media Processing Finally Ships

The most technically significant change in 7.1 is also the least discussed: WordPress will process images inside the browser before they ever reach your server. Using wasm-vips — the libvips image processing library compiled to WebAssembly — the block editor now decodes, resizes, and re-encodes all image sub-sizes locally. Your server receives finished products, not the 24-megapixel original from someone’s phone.

The format support is the real story. AVIF, WebP, HEIC, UltraHDR, and JPEG XL all work natively, both as inputs and outputs. Animated GIFs convert to MP4 or WebM automatically. None of this required a plugin before. The WASM bundle loads on first upload, not with the initial editor, so there is no performance penalty for sites that do not use it.

Two caveats developers need to know. First, this is Chromium-only for now — Firefox and Safari lack the Document-Isolation-Policy support required. Both browsers silently fall back to server-side processing with no user-visible error. Second, if your site sets a restrictive worker-src CSP header that blocks blob: URIs, the feature silently falls back too. Verify activation in the browser console: window.__clientSideMediaProcessing === true.

React 19: Second Attempt, With a Compat Layer

Gutenberg 23.3.0 shipped React 19. Within days, it was reverted. The problem was predictable: React 18 and React 19 generate JSX elements with different internal shapes, and React 19 actively rejects elements built by the React 18 runtime. Plugins that bundle their own react/jsx-runtime helper — a common pattern — crashed immediately.

The new strategy for WordPress 7.1 includes two changes: a compatibility layer that bridges the React 18 to React 19 element format for already-released plugins, and an experimental feature flag so developers can opt into the React 19 runtime before it becomes mandatory. This is the right approach. It also means you have no excuse for not testing early.

The breaking API changes are well-documented: replace render() with createRoot(), replace hydrate() with hydrateRoot(), remove any calls to findDOMNode(), and review your TypeScript types. Enable the Gutenberg experimental React 19 flag as soon as it ships and run your plugins against it before Beta 1.

Classic Block: Gone from the Inserter

The Classic block — the TinyMCE wrapper that let editors avoid Gutenberg since 2018 — will no longer appear in the block inserter. Existing posts using Classic blocks are unaffected: they still render and edit correctly. The change is about new insertion. Users can no longer reach for Classic as a fallback. TinyMCE itself becomes lazy-loaded, shipping only to pages that already contain Classic block content.

For plugin authors, this is the migration clock starting. If your plugin depends on the Classic block being available, you need a plan. The Block Transforms feature handles conversion of existing Classic block content into native blocks, but you need to implement deprecation versions in your block.json to give users a forward path. This is the formal end of the 2018 Gutenberg transition. Core committers are using the language of making TinyMCE “fully opt-in” — which is how WordPress signals eventual removal.

Block API v3 Is Now Mandatory

WordPress 7.0 introduced the iframed editor but kept a fallback: if any inserted block used API v1 or v2, the iframe was disabled for the entire session. WordPress 7.1 removes that fallback. The iframed editor becomes fully mandatory for block-based themes, regardless of which blocks are present.

Blocks that do not declare "apiVersion": 3 in block.json may break in ways that are hard to predict. More specifically, anything that assumed the editor DOM was part of the admin page will break: styles targeting editor wrapper classes, globally initialized scripts, meta boxes using editor DOM references. Audit your block.json files. Add "apiVersion": 3. Remove any code that touches the editor DOM from outside the iframe boundary.

New Blocks Worth Knowing

Three new blocks in 7.1 will displace plugins for common use cases: a Table of Contents block that auto-generates heading navigation, a Tabs block for organizing content into panels, and a Playlist block with waveform audio visualization. For most sites, these replace lightweight dedicated plugins. For plugin authors who currently sell these features, it is time to find differentiation — core just commoditized your MVP.

Four Actions Before July 15

Beta 1 is three weeks away. Here is what to do before it arrives:

• Test client-side media in Chromium with the latest Gutenberg plugin. Verify your CSP headers allow blob: URIs in worker-src.
• Enable the experimental React 19 flag in Gutenberg when it ships. Run your custom blocks and editor plugins against it before Beta 1.
• Audit every block.json in your codebase. Blocks missing "apiVersion": 3 need updating before August 19.
• If your plugin depends on the Classic block being insertable, start your migration to Block Transforms or a native block equivalent.

The full WordPress 7.1 roadmap is public. August 19 is the hard deadline. This is not the release to skip the prep work on.