WordPress 7.0 Delay Explained: The Real Reasons Behind the Postponement

In our previous article, we covered the original WordPress 7.0 release date, April 9, 2026. Since then, the story has shifted significantly. WordPress 7.0 did not ship on April 9. The core team has extended the release cycle, and for the first time in the project’s modern history, a release that had already entered the Release Candidate phase is effectively being held back for additional stability work.

We’ll go deep into why 7.0 was delayed, the specific technical problem that forced the decision, what’s different about the process this time, what’s still in the release, and what site owners, agencies, and hosting customers should be doing right now to prepare.

The Short Version: What Actually Happened

On March 31, 2026, WordPress project leadership announced that the final 7.0 release would be delayed by a few weeks to finalize key architectural details. Release lead Matias Ventura framed the delay as a matter of “weeks, not months,” and the core team committed to publishing a revised schedule no later than April 22, 2026.

WordCamp Asia 2026 in Mumbai went ahead as planned on April 9–11, with over 3,000 attendees, but the live 7.0 release that was supposed to be the headline moment didn’t happen. Instead, the event became a working session: Contributor Day focused on testing 7.0 RC builds, James LePage delivered a keynote on AI inside WordPress, and Matt Mullenweg closed the event with a clear message about AI being central to WordPress’s future.

The delay is described by the core team as a one-off deviation from WordPress’s standard date-driven release schedule, not a new norm.

The Core Problem: Real-Time Collaboration and the Database

The flagship feature of WordPress 7.0 is real-time collaborative editing (RTC); the ability for multiple users to work on the same post or page simultaneously, with live cursors and instant syncing, in a way that will feel familiar to anyone who has used Google Docs. It’s the centerpiece of Gutenberg Phase 3, the third stage of Gutenberg’s four-phase roadmap (block editor, full site editing, collaboration, multilingual).

RTC has been in private beta since October 2025, available to enterprise-level WordPress VIP customers through Automattic. The feature itself has actually tested well. Feedback from large-scale tests, dozens of simultaneous editors, large content copying in parallel, entire research-institution teams hammering on the same post, was broadly positive. One technical lead reportedly told testers their team had “not run into any issues” with the editing experience itself.

So what went wrong?

The data storage layer

The problem wasn’t the editor. It was what happened underneath.

The original implementation reused WordPress’s existing post meta system to store collaborative editing events. On paper, that’s a sensible starting point; post meta is a well-understood, well-supported mechanism that already has caching, relationships, and plugin hooks around it. In practice, at the scale and frequency RTC demands, it broke down fast:

• Cache invalidation storms. RTC generates a constant stream of small writes as people type. Post meta writes trigger cache invalidation across the object cache, which meant every keystroke was eroding cache hit rates for the entire site, not just the document being edited.
• Performance ceilings. What worked for a handful of editors fell over as concurrent users scaled up.
• Bug surface. Reusing a general-purpose table for a very specific real-time workload introduced multiple bugs that were hard to isolate.

The fix isn’t a patch. It’s a dedicated database table built specifically for RTC, with schema, indexing, and write patterns designed for high-frequency, low-payload collaborative events. That’s a foundational change, and it’s exactly the kind of decision a project wants to get right before it ships to tens of millions of sites, not after.

Why this couldn’t just be punted to a later release

A natural question: why not ship 7.0 with RTC as experimental or behind a flag, and fix the storage layer in 7.1?

The short answer is that the team considered this and rejected it. Database schema changes shipped in a major release create migration obligations, once sites upgrade, you own the data model. Getting RTC’s storage wrong in 7.0 and then changing it in 7.1 would mean a forced data migration affecting every site that had enabled the feature, with real risk of corruption or data loss on production.

The delay is the safer path. A few extra weeks to nail the schema is cheaper than a migration headache that lasts years.

Something Unprecedented: Going Back to Beta After RC

Here’s a detail that’s getting less attention than it deserves: returning to beta-like testing after entering the Release Candidate phase is unprecedented in WordPress’s modern release history.

Normally, once a release hits RC1, the project is in lockdown mode: no new features, no enhancements, only bug fixes for regressions introduced in the current cycle. The path from RC to final is a narrowing funnel, not an expansion. Reopening architectural work at this stage is a significant break from process.

The release candidate numbering decision

The team considered formally rolling back to beta numbering (7.0-beta5, etc.) but decided against it for a very specific reason: PHP version comparison rules. WordPress’s own upgrade logic, plugin update tooling, and dependency managers all use PHP’s version_compare() function, which treats “beta” as lower than “RC.” Rolling back the version string would break expected ordering and confuse everything from automated update systems to staging deployment pipelines.

The decision: stay in the RC sequence (RC1, RC2, RC3, and onward as needed), but treat this phase with beta-level scope. In practice, that means more RCs than usual, with meaningful change between them, while preserving tooling compatibility across the ecosystem.

What’s allowed during the extended cycle

The core team has published specific policies for what can land during the extension:

• No new features or enhancements. Full stop.
• Only fixes for regressions introduced during the 7.0 cycle. Fixes for older bugs that existed in 6.9 go to 7.1.
• Trunk is closed to 7.1 commits until further notice, to avoid merge conflicts with backports.
• Double sign-off on backports. Core committers must use dev-feedback to request review and dev-reviewed to indicate approval before merging to the 7.0 branch.

This is tighter than a normal RC lockdown and reflects how seriously the team is taking stability for this milestone.

The PHP Requirements Change: A Critical Detail

One of the most operationally significant parts of the 7.0 release has nothing to do with RTC or AI. It’s the PHP version bump.

WordPress 7.0 drops support for PHP 7.2 and PHP 7.3. Sites running either version will not receive the automatic update to 7.0. They will remain on the WordPress 6.9 branch, which receives security backports where possible but is not the actively maintained security release branch.

The core team’s published rationale: combined usage of PHP 7.2 and 7.3 has dropped below 4% of monitored WordPress installations globally. That’s the number that matters for the project overall. But it is not the number that matters for any individual site or hosting customer. The relevant figure for you is your own PHP distribution.

Who is most likely to be affected:

• Older small-business sites that haven’t been touched in years
• Legacy e-commerce stores still running on provisioning scripts from 2018–2019
• Plugins or custom code with explicit PHP 7.2/7.3 dependencies
• Sites on cheap shared hosting where PHP upgrades weren’t automated

If you manage WordPress sites at scale, this is the single most time-sensitive item on your 7.0 preparation checklist. Customers who end up on an unsupported branch after a release they didn’t consciously opt out of are a support ticket and, worse, a trust problem.

What the Delay Means for You: A Practical Checklist

Here’s what we recommend doing in the window between now and the revised release date.

If you run a single WordPress site

1. Check your PHP version. Anything below 7.4 needs to be upgraded before 7.0 ships. If your host offers PHP 8.2 or 8.3, use that.
2. Stand up a staging environment. If you don’t have one already, now is the moment. You want to test 7.0 RC builds against your theme and plugins before production sees them.
3. Audit your plugins. Check for 7.0 compatibility notes on any plugin you depend on, especially ones that touch the block editor, REST API, or post meta.
4. Back up before the release lands. Not a snapshot from three months ago. A fresh, verified backup you’ve actually tested restoring.

If you manage multiple sites or run an agency

1. Fleet-wide PHP audit. Pull PHP versions for every site you manage. Anyone on 7.2 or 7.3 needs outreach before the release, not after.
2. Prioritize client communication. Especially for non-technical clients who won’t understand why their site suddenly isn’t updating itself.
3. Test RC builds in a controlled environment. Use the WordPress Beta Tester plugin on a staging site that mirrors your most complex client setup.
4. Plan your rollout windows. Don’t plan to push 7.0 to every client site on release day. Stagger it.
5. **Document the “what if.” ** Have a rollback plan for clients whose sites don’t play nicely with 7.0. Snapshots, database backups, and a tested restore procedure.

If you’re a developer or plugin author

1. Test against the latest RC. Nightly builds from the 7.0 branch are still available via the WordPress Beta Tester plugin.
2. Watch the Abilities API and MCP surfaces. If you’re building anything that touches AI, these APIs are the long-term integration points.
3. Don’t ship new features during the freeze. If you maintain a plugin that hooks into areas under active 7.0 development (block editor internals, post meta at high frequency, etc.), expect the surface to move between RCs.

When Will WordPress 7.0 Actually Ship?

The honest answer: we don’t know yet, and neither does the core team; precisely, anyway.

What we do know:

• The delay is measured in weeks, not months (Matias Ventura’s words).
• A revised release schedule will be published by April 22, 2026.
• Current speculation in the community suggests a mid-to-late May 2026 release, though this is not an official date.
• The release will ship through an extended RC sequence rather than a formal return to beta numbering.

Our recommendation: check back around April 22 for the official revised schedule, and plan your upgrade window from there.

The Bigger Picture

Pull back from the immediate detail, and the WordPress 7.0 delay tells a specific story about where the platform is heading.

WordPress is making a real architectural investment , a new database table, a new AI client layer, a new protocol adoption, a new collaboration primitive, all in a single release, against a backdrop of AI-native competitors entering the market and a two-decade-old codebase that critics increasingly argue needs modernization. Shipping all of that on schedule would have been impressive. Shipping it well is more important.

The delay is short. The features are still landing. The release will ship. But when it does, it will ship on a foundation the team is actually willing to stand behind for the long term, rather than a schedule they were willing to hit and patch later.

For site owners, the question isn’t whether WordPress 7.0 matters. It will reshape how teams work in WordPress, how AI gets integrated, and what the next five years of the platform look like. The question is whether you’ll be ready for it when it lands.

The next few weeks are the window to make sure the answer is yes.