The WordPress 7.1 roadmap

#Introduction

On 19 June 2026, Automattic’s Anne McCarthy published the WordPress 7.1 roadmap on the Make WordPress Core blog, her first cycle as release lead. Her framing on LinkedIn was characteristically warm: “I am so excited about what’s taking shape.” The roadmap is genuinely packed, and the headline word is collaboration, set up as the throughline that ties the release together.

There is a tension worth naming up front. The release is sold on collaboration, but the marquee collaboration feature, real-time collaboration, is the one thing that keeps getting deferred. It was pulled from WordPress 7.0 about two weeks before that release. It returns in the 7.1 roadmap wrapped in “big, open strategy questions” rather than a ship date. And at WordCamp Europe 2026, core committers openly questioned whether the full feature even belongs in core. So the honest read of 7.1 is two releases in one: a solid set of styling, media and platform improvements that will actually ship on 19 August, and a collaboration story that is still being argued about in the open.

Update, 28 July 2026: two items have left this release since the roadmap was published. The React 18 to React 19 upgrade has been punted beyond 7.1, and Unicode email address support has been pulled. Beta 3 is out, carrying 71 fixes. The 19 August release date has not moved. Both corrections are worked through in the sections below.

#The short version

• Anne McCarthy leads 7.1 for the first time, with release set for 19 August 2026, the closing day of WordCamp US in Phoenix. Beta 3 has shipped with 71 fixes.
• The release is framed around collaboration, but real-time collaboration (RTC) remains unresolved after being cut from 7.0.
• The genuinely confirmed wins are responsive styling, Classic block deprecation, and the Guidelines plus AI workflow features. React 19 was on that list and has now slipped past 7.1.
• Unicode email address support was pulled from the release on Matt Mullenweg’s call, over security concerns, six weeks after it merged into core.
• Core committers floated a Chrome-style canary deployment model, a signal they think the testing and feedback process itself needs rethinking.
• With a short stabilisation window, expect more roadmap items to slip or ship behind flags. Two already have.

#What actually ships, ranked by who cares

The roadmap lists a lot. For a site owner or agency, the useful question is not “what is on the list” but “what changes my work.” Here is the split.

The pattern is clear. The high-confidence items are infrastructural or builder-facing. The collaboration story, the one the release is named for, sits in the medium-to-low band.

Gutenberg 23.6 shipped as the final feature release heading into 7.1, and it is what firmed up the middle of that table. It promotes the Playlist and Tabs blocks from experimental to stable, adds inline text-selection notes with @mention autocomplete, a Dynamic Gallery variation that shows every media item attached to a post, an icon registration API for plugins and themes, and customizable viewport widths in theme.json, which is the responsive-styling work becoming configurable rather than fixed at three breakpoints someone else chose.

#Responsive styling: the quiet headline

If you build sites for clients, the most useful thing in 7.1 is not collaboration, it is responsive styling. Until now, controlling how a block looks at different screen sizes meant custom CSS, a plugin, or fighting the editor. The roadmap brings per-breakpoint block styling into the editor itself, alongside interactive-state styling for hover, focus and active states, and a “display inherited styles” view so you can see where a style actually comes from.

This is unglamorous and it matters more than most of the flashier items. Responsive control is a daily friction point in real client work, and moving it into core reduces the plugin count and the custom CSS that every site otherwise accumulates. It is the kind of platform maturity that does not make headlines but quietly removes a category of support tickets.

#React 19 slips, Classic block deprecation stays: under the hood

Two items on the roadmap are invisible to end users and important to developers. One of them has now left the release. The editor’s upgrade from React 18 to React 19 will not land in 7.1: plugin compatibility issues proved more stubborn than expected, and Automattic-sponsored contributor Jarda Snajdr said the upgrade needs “a considerable testing period” before it can ship.

That is the right call and an uncomfortable one. React 19 was one of the few items on this roadmap carrying high confidence, and it was also the single item most likely to break third-party code. Punting it makes 7.1 a smaller release than the roadmap advertised, and it pushes the compatibility work into someone else’s cycle. For developers the practical effect is a reprieve rather than a cancellation: the upgrade is still coming, so testing custom blocks and editor interfaces against React 19 in the Gutenberg plugin is still worth doing, just without an August deadline attached to it.

The Classic block is the more interesting one, because the plan changed mid-cycle. The original idea was to hide it from the block inserter in 7.1 and start phasing it out, since it carries TinyMCE, a heavy editor, and the community reaction was swift: some like Seth Rubenstein (Pew Research Center) reacted with a simple “good,” while veteran blogger Jeff Chandler saw disruption coming: “Holy shit. I didn’t see this coming. I know what this is gonna do.”

Update: that hide-from-inserter plan was reversed. Per the core discussion, the Classic block will keep appearing in the inserter in 7.1 exactly as it does today, with Automattic engineering director Marin Atanasov noting the original approach “had things largely backward” and that forcing users off it without a better alternative makes the experience worse for no direct gain. The performance angle still stands (lazy-loading TinyMCE off pages that never use it is a real gain for WooCommerce stores where every kilobyte of editor weight is measured), but the migration clock some people started is paused. If you maintain Classic-block content, nothing forces your hand in 7.1.

Update: Unicode email address support is also out of 7.1. It had been merged into core six weeks earlier, after eleven years of development, and Matt Mullenweg made the call to drop it over security concerns. Eleven years to land and six weeks to be reversed is a brutal result for the contributors involved, and it is worth reading next to the canary discussion below: a change that clears review, merges, and is then pulled late on a security judgement is exactly the feedback-loop problem the committers are trying to name. If you were counting on non-ASCII email addresses working in 7.1, plan for the current behaviour instead.

Two developer-facing changes worth tracking landed as merge proposals after the roadmap. Design system theming introduces a core-registered wp-theme stylesheet plus a React ThemeProvider, the groundwork for the long-promised admin redesign, with the first visible payoff being user colour schemes applied to the Site Editor. And the Abilities API gained three proposed read-only abilities (core/read-settings, core/read-content, core/read-users) that let agents and AI tooling read basic site data behind permission checks, though an Abilities maintainer has already pushed back that they are not ready for core. Both are the kind of plumbing that decides whether the AI and admin story ships clean or slips to 7.2.

#Guidelines and AI: the workflow bet

The standout is Guidelines, a feature that lets a site define editorial rules and brand voice in one place, which then feeds the editor’s AI tooling so generated content follows those rules. There is also an AI Client iteration adding generation streaming and embeddings, and a Connectors iteration that moves authentication beyond plain API keys.

This feature took a concrete step forward when Automattic-sponsored core committer Greg Ziółkowski published a formal merge proposal to bring the new wp_knowledge custom post type and AI Guidelines into core. The reception, however, has been highly polarized:

• George Stephanis (Bethink Studios) welcomed the feature, noting it solves editorial guidelines challenges that plugins have spent years working around.
• Aaron Jorbin (independent core committer) noted it establishes a good foundation but remains incomplete in its current state.
• Jon Brown (9seeds) argued it “should be worked out as a core plugin for a year or two, and then maybe still never merged to core.”
• Search Engine Journal picked up on the developer pushback, reporting that many feel the feature is out of touch with user needs, a sentiment echoed in independent community groups.

This is the right shape for AI in a CMS. The risk with AI writing assistance is uniform, off-brand output, the exact slop problem every content team is now fighting. A Guidelines layer that constrains generation to a site’s standards is a hedge against that, assuming it ships in a usable state. It is rated medium confidence here precisely because feature ambition and a four-week stabilisation window do not always agree.

#The RTC saga, and why it keeps stalling

Real-time collaboration is the feature WordPress keeps almost shipping. It was cut from 7.0 two weeks out. In the 7.1 roadmap, McCarthy frames it honestly, with “big, open strategy questions” still open: what to actually ship, and which storage mechanism to use. We covered the specifics of this second attempt in our piece on WordPress 7.1 real-time collaboration, and the roadmap does not resolve the questions raised there so much as restate them.

The more revealing development came from the core committers. At their WordCamp Europe 2026 gathering, a “strong opinion, loosely held” emerged that the full RTC feature set should not live in core at all, only the underlying architecture, with the rich feature layer left to plugins or hosts. That is a meaningful split. If it holds, 7.1 might deliver the plumbing for collaboration without the visible feature, which would make the “collaboration as a throughline” framing more aspiration than delivery for this cycle.

#The canary debate: a process problem in disguise

The most interesting thing committers discussed at WordCamp Europe was not a feature at all. They floated moving WordPress to a Chrome-style canary deployment model with feature flags, a fundamentally different way of building, testing and shipping core. The group itself acknowledged it was likely “a technical solution to a communications problem,” and raised obvious questions, like how canary builds would differ from what the Gutenberg plugin already offers, and whether there should still be a Gutenberg plugin at all.

It is a long way from happening. But that committers raised it says something about where they think the current model falls short, especially around testing and feedback. The RTC near-misses are the symptom: a major feature reaching two weeks from release before being pulled is a feedback-loop failure, not just a feature that was not ready. The canary idea is an attempt to catch that earlier. Whether or not it lands, the fact it is on the table is the most honest admission in the whole cycle that the build process, not the feature backlog, is the real constraint.

#The timeline problem

Here is the hard number. Beta 1 was planned for 15 July, release is 19 August, and Beta 3 is now out with 71 fixes behind it. That is under four weeks to lock down a roadmap this large. McCarthy inherited an ambitious list and a short runway, and the realistic outcome was always that some items ship, some slip to 7.2, and some arrive behind feature flags in a partial state. That is not a criticism of the release lead, it is the structural reality of a fixed date set to coincide with WordCamp US. React 19 and Unicode email are the first two names on that list, and they came off before Beta 3, not after.

For site owners the practical takeaway is to treat the roadmap as intent, not a guarantee. Plan around what is now genuinely confirmed, responsive styling and the Gutenberg 23.6 block work, and watch the medium-confidence items (Guidelines, the admin-redesign theming groundwork) rather than building plans on them. Do not promise a client a feature that is still carrying “big, open strategy questions” six weeks before release, and do not assume a merged feature is a shipped one.

#The 24-hour update delay: security vs. speed

In parallel to the Core release debates, the WordPress.org plugins team implemented a major infrastructure change: a 24-hour cooldown delay for all plugin and theme updates. While the announcement framed this cooldown around auto-updates to prevent supply-chain attacks, it turned out that the delay applies to all update paths, including manual dashboard installations.

This has drawn intense pushback from developers and agency maintainers:

• Miriam Schwab (Elementor) pointed out that this creates a dangerous “vulnerability window.” The moment a security release is committed, the patch code is public and bots can analyze it to build exploits, yet site administrators are blocked from applying the patch for up to 24 hours.
• Pavel Ciorici (theme developer) flagged that if a developer ships a quick bug fix during the cooldown, the 24-hour timer resets, compounding the delay.
• Steve Burge (PublishPress) provided a counterpoint, highlighting that the process successfully caught minor security reports on its first week and called it a good step forward.
• Francisco Torres (Plugins Team co-rep) acknowledged the friction, confirming that the team is actively reviewing feedback and that changes to the delay are likely.

For agencies and performance-oriented WordPress sites, this infrastructure shift changes the release and security patching rhythm, reinforcing the need for off-repo deployments or testing staging sites before public rollouts.

#What to do before 19 August

• Developers: React 19 is not in 7.1, so the deadline moved, not the work. Keep testing custom blocks and editor extensions against it in the Gutenberg plugin, because plugin compatibility is the reason it slipped in the first place.
• Legacy sites: audit where you still depend on the Classic block or editor and start a migration plan, because the deprecation clock has formally started.
• Performance builds: the lazy-loaded TinyMCE change is free performance once you are off the Classic block, worth factoring into a WooCommerce performance review.
• Editorial teams: watch Guidelines and the AI tooling, but do not redesign your workflow around a medium-confidence feature until it actually ships.
• Everyone: test against Beta 3, which is out now with 71 fixes behind it. A short stabilisation window means community testing matters more than usual this cycle.

#Conclusion

WordPress 7.1 is a strong release with a slightly misleading name. The collaboration framing is real intent, but the collaboration feature is still unresolved, and the committers are openly debating whether it belongs in core and whether the whole build process needs rethinking. Strip the framing away and what you get on 19 August is a smaller but still useful platform release: responsive styling that removes daily friction, the Playlist and Tabs blocks arriving stable through Gutenberg 23.6, a Classic block deprecation that helps performance, and a disciplined first step on AI through Guidelines. The React 19 modernisation and Unicode email support are both out of this cycle, which is the clearest evidence yet of how wide the gap between a published roadmap and a shipped release can get.

The deeper story is the canary debate. A project willing to question its own deployment model in public is a project that knows its feedback loops are straining, the same anxiety that fuels the recurring question of whether WordPress is losing market share. Watch that conversation, because it will shape WordPress releases long after 7.1 ships. For now, plan around what is confirmed, test early, and treat the rest of the roadmap as a statement of intent rather than a delivery promise.

Last updated: 28 July 2026.