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

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 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 and React 19, and watch the medium-confidence ones (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.

#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: 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, 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: 11 July 2026.