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 was 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 returned in the 7.1 roadmap wrapped in “big, open strategy questions” rather than a ship date. At WordCamp Europe 2026, core committers openly questioned whether the full feature even belongs in core. The honest read of 7.1 is two releases in one: a solid set of styling, media and platform improvements that shipped on 19 August, and a collaboration story that is still being argued about in the open.

Update, 20 August 2026: WordPress 7.1 Mary Lou shipped on 19 August, on the date. The React 18 to React 19 upgrade, Unicode email, Guidelines / wp_knowledge, real-time collaboration, and the Classic block phase-out all left the release. What landed is responsive styling, client-side media, a persistent admin bar, an always-iframed post editor, Playlist and Tabs, and richer Notes. The 28 July Beta 3 note still stands for the two items that left first.

#The short version

• Anne McCarthy led 7.1 for the first time. WordPress 7.1 Mary Lou shipped on 19 August 2026, the closing day of WordCamp US in Phoenix.
• The release was framed around collaboration, but real-time collaboration (RTC) was punted again after being cut from 7.0.
• What actually landed: responsive styling, client-side media, persistent admin bar, always-iframed post editor, Playlist and Tabs. Guidelines and Classic block deprecation did not. React 19 slipped past 7.1.
• Unicode email address support was pulled 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.
• The short stabilisation window did what it always does: the June list was intent. The 19 August zip is the delivery.

#What actually shipped, 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. 7.1 puts per-breakpoint block styling into the editor itself, alongside interactive-state styling for hover, focus and active states. Theme authors can set their own breakpoints in theme.json. Beta 4 added an opt-out after UX complaints, so this is not forced on every site.

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 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. The Classic block still appears in the inserter in 7.1 exactly as it did in 7.0. Automattic engineering director Marin Atanasov said 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 never started. If you maintain Classic-block content, nothing in 7.1 forces your hand.

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. It did not ship. Matt Mullenweg vetoed the merge in July, saying AI features need real-world adoption with impressive week-to-week growth before they land in core. The experiment stays in Gutenberg and at Automattic. Treat it as a proposal, not as a 7.1 capability. We covered the merge debate in WordPress 7.1 AI guidelines and the wp_knowledge custom post type.

#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 split held for this cycle. 7.1 delivered neither the plumbing nor the visible feature. Collaboration as a throughline stayed aspiration. 7.2 is currently targeted for 9 December 2026. Do not sell a client live multi-user editing on that date either, until a field guide says it shipped.

#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 15 July, release was 19 August, and Beta 3 carried 71 fixes. That was 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 came off before Beta 3. Guidelines, RTC and Classic block phase-out came off around it. The zip that shipped is the shorter list.

For site owners the practical takeaway is unchanged: treat a published roadmap as intent, not a guarantee. Plan around what actually shipped, responsive styling, client-side media, Playlist and Tabs, and the iframed editor. Do not promise a client a feature that still carried “big, open strategy questions” six weeks before release, and do not assume a merged feature is a shipped one. Unicode email was merged and then pulled. That is the same lesson.

#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 now

• Developers: the post editor is always iframed. Blocks on API v2 or lower need a v3 pass. Details are in our iframed post editor note. React 19 is still not in core. Keep testing against it in the Gutenberg plugin.
• Sites on WP Rocket: a type error in the Cloudflare compatibility module has been taking sites offline on 7.1 (wp-media/wp-rocket#8596). Staging first, then production. If you maintain stores, this is a WooCommerce performance and reliability check, not a cosmetics pass.
• Legacy sites: the Classic block is still in the inserter. There is no forced migration in 7.1. Audit it when you next touch the content, not because this release started a clock.
• Editorial teams: Guidelines did not ship. Do not redesign a workflow around a Gutenberg experiment.
• Everyone: auto-updates to 7.1 are rolling. Test on staging, especially if you run object cache, a page cache plugin, or custom editor JavaScript.

#Conclusion

WordPress 7.1 Mary Lou is a useful platform release with a slightly misleading name. The collaboration framing was real intent. The collaboration feature did not ship, for the second consecutive cycle. Strip the framing away and what you got on 19 August is smaller and still worth taking: responsive styling that removes daily friction, client-side media that stops HEIC uploads hitting PHP memory limits, Playlist and Tabs as stable blocks, a persistent admin bar, and an always-iframed post editor. Guidelines did not land. Classic block deprecation did not land. React 19 and Unicode email stayed out. That gap between the June roadmap and the August zip is now measured, not predicted.

The deeper story is still 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 releases long after this one. Plan around what shipped. Test staging. Treat the next roadmap the same way this one deserved to be treated: intent, until the zip exists.

Last updated: 20 August 2026.