WordPress 7.1: What's New, When It Launches, and How to Prepare

WordPress 7.1 is due out on August 19, 2026, and it's a bigger release than its point-number suggests. Where WordPress 7.0 focused on AI foundations and a modernized admin, 7.1 shifts the spotlight to collaboration: multiple people editing and reviewing content together, new blocks for media-heavy pages, and a round of styling controls that finally bring hover and responsive states into the block editor without custom CSS. It also carries a meaningful set of deprecations that theme and plugin developers need to know about before update day.

This article covers what's confirmed for 7.1 as of its beta cycle, what's still in flux, and how to get a site ready for it without surprises.

TL;DR

• WordPress 7.1 is scheduled for final release on August 19, 2026, following Beta 1 (July 15), Beta 3 (July 22), and RC1 (August 5).
• Headline features include collaborative Notes with suggestion mode and reactions, a new "Guidelines" system for encoding editorial rules, responsive and pseudo-state (hover/focus) styling for blocks, and three new blocks: Playlist, Table of Contents, and Tabs.
• Developers should watch for the hard deprecation of __next40pxDefaultSize across roughly 20 core components, the deprecation of the @wordpress/reusable-blocks package, and continued movement away from the Classic block and TinyMCE.
• Test any production site on a staging copy before updating, especially if it relies on older plugins, custom blocks, or theme.json overrides.

WordPress 7.1 Release Timeline

WordPress follows a public beta cycle for every major release, and 7.1 is no exception. Based on the schedule published by the WordPress core team:

• Beta 1: July 15, 2026
• Beta 3: July 22, 2026 (the most recent beta as of this writing, with over 71 tickets addressed since Beta 1)
• Release Candidate 1: August 5, 2026
• Final release: August 19, 2026

As with any release still in beta, the WordPress core team is explicit that features "actively pursued" don't all guarantee a spot in the final build. A few items below, most notably Unicode email address support, have already been pushed out of 7.1 during the beta cycle, so treat anything not yet in RC as tentative until the release candidate ships.

What's New in WordPress 7.1

Collaboration Features

The centerpiece of 7.1 is a set of collaborative editing tools aimed at teams and agencies that manage content together rather than solo. The existing Notes feature gains a suggestion mode, so a reviewer can propose a change without directly editing the content, plus emoji reactions for lighter-weight feedback on drafts. Real-time, simultaneous editing (multiple people typing in the same post at once) is also part of the roadmap discussion, though the core team has flagged that the underlying implementation decisions are still being worked out, so it may land in a more limited form than initially discussed.

For agencies managing client sites, or in-house teams with an editor and a reviewer working the same content calendar, this closes a real gap: right now, most of that back-and-forth happens in Slack or Google Docs before content ever touches WordPress.

Guidelines: Editorial Rules for an AI-Assisted Editor

7.1 introduces a persistent "Guidelines" system that lets a site define its editorial rules and brand voice directly inside WordPress. It's positioned specifically for sites using AI-assisted writing tools (a category WordPress 7.0 expanded significantly by building AI features into core): instead of repeating "always use active voice" or "never use the Oxford comma" in every AI prompt, a site can encode that once and have it apply consistently.

This is worth watching even for sites that aren't using AI drafting today. As more plugins and third-party tools tap into WordPress's AI foundations, a central place to define editorial standards is likely to become a shared convention rather than a one-off feature.

Responsive and Pseudo-State Styling

Until now, giving a block different styles at different breakpoints, or a different look on hover or focus, generally meant writing custom CSS. WordPress 7.1 adds native support for both: responsive style values keyed to viewport size using an "@" prefix syntax, and pseudo-state styling (hover, focus, active) exposed directly in the block style controls.

Beta 3 also refined how "Apply globally" works when pushing local block style changes out to the whole site. Instead of an all-or-nothing action, it now includes a review step so an editor can selectively apply changes while keeping specific local overrides intact. That's a small change with an outsized practical benefit: it's the difference between confidently pushing a site-wide style tweak and being afraid to touch it because the last attempt overwrote something unrelated.

Three New Blocks

7.1 adds three new core blocks:

• Playlist — for audio content, with waveform visualization built in.
• Table of Contents — auto-generated navigation for long posts, useful for the kind of in-depth articles that benefit from jump links.
• Tabs — a native tabbed-content block, replacing what has historically required a third-party plugin.

None of these are groundbreaking individually, but they continue a pattern from recent WordPress releases: functionality that used to require a plugin is steadily moving into core, which is generally good news for site performance and long-term maintainability.

Media Handling Improvements

Several fixes and additions target the media library specifically:

• HEIC support and GIF-to-video conversion happen client-side.
• Uploads gain retry logic, so an interrupted upload doesn't just fail silently.
• A new freeform image cropper replaces the previous inline cropping tool.
• Beta 3 specifically fixed long animated GIFs hanging during upload, incorrect EXIF-based image rotation, and duplicate entries when uploading a single HEIC image in Safari.

If your site or your clients' sites deal with a lot of visual content (WooCommerce product photography is the obvious example) these are the kind of unglamorous fixes that quietly save real time.

Workspace and Navigation Updates

A few interface changes round out the release: a persistent admin bar (sometimes referred to as an "omnibar") that stays accessible across different editing contexts, a reorganized command palette with recent and suggested items grouped separately, an "On This Day" dashboard widget that surfaces older content for potential updates or reshares, and a dedicated Identity section for managing core site details like title, tagline, and icon in one place.

What's Changing Under the Hood

WordPress 7.1 also carries a meaningful set of technical changes that mostly matter to developers and anyone maintaining custom themes or plugins.

Component and Package Deprecations

The __next40pxDefaultSize prop, used across roughly 20 core UI components including TextControl, RangeControl, and CustomSelectControl, is hard-deprecated in 7.1. The 40px control size that prop used to opt into becomes the permanent default. If a theme or plugin passes that prop explicitly, it will start logging deprecation warnings.

The @wordpress/reusable-blocks package is also deprecated, with its store actions and selectors now logging warnings rather than being removed outright. The useResizeCanvas() hook is deprecated and no longer functional, though the related getDeviceType() and setDeviceType() functions remain available.

Classic Block and TinyMCE

The long, slow deprecation of the Classic editor continues: TinyMCE will no longer load by default, which improves editor performance for the majority of sites that don't rely on it. Sites still using the Classic block for specific content, plugin compatibility, or legacy workflows should confirm before updating that it still behaves as expected, since "no longer loads by default" is a meaningfully different condition than "still fully supported."

Abilities API and Icons API

7.1 proposes expanding WordPress's newer Abilities API with three read-only abilities: core/read-settings, core/read-content, and core/read-users. These build on existing capability checks and are a building block for more granular, permission-aware integrations, including AI tools that need to read (but not necessarily write) specific parts of a site. "Manage" (write) variants are planned for a future release, not 7.1.

A new REST endpoint, /wp/v2/icon-collections, surfaces WordPress's icon system programmatically. All 330 bundled icons now use fill="currentColor" instead of hardcoded fill values, which means developers who need to change an icon's color should do it with the CSS color property going forward rather than targeting fill directly.

Unicode Email Addresses: Postponed

Support for Unicode (internationalized) email addresses, originally planned for 7.1 and backed by a new WP_Email_Address class handling UTF-8 local parts and Punycode domains, has been postponed. The core team wants broader testing through a standalone plugin first. It's a good example of the beta process working as intended: a feature that touches something as fundamental as email handling gets more scrutiny before merging into core, not less.

Should You Update to WordPress 7.1 on Launch Day?

For most production sites, the honest answer is: not on day one, and that's not a criticism of the release. It's standard practice for any WordPress major version. The deprecations above are exactly the kind of change that can surface compatibility issues in older plugins or custom code that nobody has touched in a while, and those issues are much cheaper to find on a staging site than on a live one.

A reasonable approach:

• Personal blogs and low-complexity sites with a current, well-maintained theme and a small plugin list can generally update within the first week or two, once RC1 feedback has settled and the final release has had a few days in the wild.
• Business sites, WooCommerce stores, and anything with custom development should wait for a staging test first, specifically checking any plugin or custom code that touches block editor components, reusable blocks, or the Classic block.
• Agencies managing multiple client sites should treat this like any major release: batch-test on staging, prioritize sites with custom blocks or heavy plugin use, and roll out on a schedule rather than all at once.

How to Prepare Your Site for WordPress 7.1

A few concrete steps make this update lower-risk regardless of when you apply it:

1. Back up before you touch anything. This applies to every core update, not just major ones. MagicWP's on-demand backups let you take a full snapshot immediately before an update, so a rollback is a restore away rather than a rebuild.
2. Test on a staging copy first. Clone the live site, apply WordPress 7.1 there, and click through the admin, the editor, and the front end before touching production. MagicWP's one-click staging tools make this a same-session task rather than a separate project.
3. Audit plugins and custom code for the specific deprecations above, particularly anything that references __next40pxDefaultSize, the reusable blocks package, or useResizeCanvas(). A search through your theme and any custom plugins for those strings takes a few minutes and can save a broken editor screen after the update.
4. Check performance after updating, not just functionality. New editor and media features can shift how a site performs under real traffic. MagicWP's global edge cache and auto-scaling infrastructure absorb most of that variability, but it's still worth a quick check on page load after any core update.
5. Keep security patching separate from feature updates in your head, even when they arrive close together. WordPress 7.0.2 shipped as a critical security fix in July 2026, and 7.1 is a feature release; treat urgent security patches as immediate regardless of your staging schedule for feature releases, since managed security monitoring reduces exposure but doesn't replace applying critical patches promptly.

Frequently Asked Questions

When does WordPress 7.1 come out? WordPress 7.1 is scheduled for final release on August 19, 2026. It's currently in beta, with Release Candidate 1 planned for August 5, 2026.

What are the biggest changes in WordPress 7.1? The most visible changes are collaborative editing features (Notes with suggestion mode and reactions), responsive and hover/focus styling for blocks without custom CSS, and three new blocks: Playlist, Table of Contents, and Tabs. Under the hood, several core components and the reusable blocks package pick up deprecation warnings.

Will WordPress 7.1 break my plugins or theme? It can, though usually not catastrophically. The main risk is for themes or plugins that reference now-deprecated props and functions like __next40pxDefaultSize or useResizeCanvas(), or that lean heavily on the Classic block. Testing on staging before updating production is the reliable way to find out.

Should I update to WordPress 7.1 as soon as it's released? For simple, well-maintained sites, updating within the first couple of weeks is usually fine. For business-critical sites, WooCommerce stores, or anything with custom development, test on staging first and update on your own schedule rather than on release day specifically.

Is the Classic block being removed in WordPress 7.1? Not removed, but further deprecated. TinyMCE, the editor the Classic block depends on, will no longer load by default in 7.1, which improves performance for most sites but means Classic block behavior should be verified before updating if your site still relies on it.

What happened to Unicode email address support in WordPress 7.1? It was postponed. The feature, which would let WordPress accept internationalized email addresses on utf8mb4 databases, is being tested through a separate plugin first so it can get broader community testing before merging into core in a future release.

What is the Abilities API in WordPress 7.1? It's an expansion of a newer WordPress permissions system that lets integrations, including AI tools, request specific read access (settings, content, or users) rather than broad capability checks. 7.1 adds three read-only abilities; write ("manage") variants are planned for later.

Do I need to rewrite my custom CSS because of the new responsive and hover styling? No. The new styling options are additive, exposed through block style controls using an "@" prefix syntax for responsive values. Existing custom CSS continues to work; the new system just gives editors a way to do some of that styling without writing CSS at all.

Conclusion

WordPress 7.1 is a release aimed squarely at how content actually gets made: by more than one person, often with AI tools somewhere in the workflow, and increasingly without hand-written CSS for basic responsive or interactive styling. None of it demands an urgent update the way a security release does, but the deprecations around older block editor components are worth taking seriously if you maintain custom themes or plugins.

The practical move is the same one that applies to every WordPress major release: back up, test on staging, and update on a schedule that fits the site rather than the release date. If you're managing that process across a hosting setup, one-click backups and staging cut most of the friction out of the "test before you touch production" step, which is really the only step that matters here.