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.

#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, and Beta 1 on 15 July.
• 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, React 19, Classic block deprecation, and the Guidelines plus AI workflow features.
• Core committers floated a Chrome-style canary deployment model, a signal they think the testing and feedback process itself needs rethinking.
• With under four weeks from Beta 1 to release, expect some roadmap items to slip or ship behind flags.

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

#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 and Classic block deprecation: under the hood

Two items on the roadmap are invisible to end users and important to developers. WordPress is upgrading the editor from React 18 to React 19, landing first in the Gutenberg plugin before an eventual path to core. For most sites this changes nothing visible. For anyone maintaining custom blocks or editor interfaces, it is a reason to test against React 19 before August rather than after.

The Classic block deprecation is the more interesting one, because it is a performance decision dressed as housekeeping. The Classic block carries TinyMCE, a heavy editor, and the plan is to lazy-load it and phase the block out. Existing content does not break, but sites still leaning on the Classic editor or Classic block should treat this as the formal start of a migration clock. For performance-sensitive builds, especially WooCommerce stores where every kilobyte of editor and front-end weight is measured, shedding TinyMCE from pages that never needed it is a real gain.

#Guidelines and AI: the workflow bet

The roadmap leans into AI, but in a more disciplined way than “add a chat box.” 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 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 is planned for 15 July, and release is 19 August. That is under four weeks to lock down a roadmap this large. McCarthy inherits an ambitious list and a short runway, and the realistic outcome is 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.

For site owners the practical takeaway is to treat the roadmap as intent, not a guarantee. Plan around the high-confidence items, responsive styling, React 19, the Classic block clock, and watch the medium-confidence ones 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.

#What to do before 19 August

• Developers: test custom blocks and editor extensions against React 19 now, using the Gutenberg plugin, not after the core release.
• 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 1 from 15 July. 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 genuinely useful platform release: responsive styling that removes daily friction, a React 19 modernisation, a Classic block deprecation that helps performance, and a disciplined first step on AI through Guidelines.

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. 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: 20 June 2026.