WordPress 7.0 delayed to late May: what it means for your update plan

April 9 has come and gone, and WordPress 7.0 is not here. On March 31, release lead Matias Ventura posted "Extending the 7.0 Cycle" on the core team blog, confirming that the release would slip by "a few weeks to finalize key architectural details." No specific new date has been announced yet. An updated schedule is expected by April 22.

If you scheduled a staging rehearsal, briefed your team, or already started nudging clients toward April 9, here is what happened and how I would adjust. For the full feature set of 7.0, my earlier WordPress 7.0 preview still stands. Only the timeline has shifted.

TL;DR:

• WordPress 7.0 was delayed from April 9 to late May 2026. No exact date yet; a new schedule lands by April 22
• The cause: real-time collaboration stored its sync data in postmeta, which broke persistent post caches on every active edit. A new wp_collaboration database table is being designed to replace it
• Pre-releases are paused through April 17. The current stable production version is WordPress 6.9.4
• This is good news. A delayed release is almost always a better release. WordPress 5.9 and 6.5 both slipped for similar reasons and shipped stronger
• Action items: stay on 6.9.4, check your PHP version, re-time your staging rehearsal, and keep Beta Tester nightlies running on staging

What actually broke

The delay is not a mystery. Ventura and Matt Mullenweg wrote about it openly.

Real-time collaboration, the headline feature of 7.0, needs somewhere to store its sync data: cursors, presence info, and incremental content changes. The original implementation used WordPress's postmeta table and transients. Every time two people typed together, it wrote to postmeta several times per second.

WordPress fires cache-invalidating hooks whenever postmeta changes. That meant any post with active collaborators had its persistent object cache invalidated every second or so. Any post being edited would lose its cache entirely. For a CMS that leans heavily on Redis and Memcached for speed, that is a problem you cannot ship.

The fix proposed in Trac #64696 is a dedicated wp_collaboration table, with fields for room, client ID, user, data payload, and a timestamp for cleanup. Mullenweg, quoted in the ticket discussion, said:

"I'm generally against new tables, but this is a useful primitive for all our future real-time collab and sync work."

He wanted time to get the schema right. That is the whole story: a new database table being designed carefully instead of bolted on at the last minute. Ventura's post concludes the same way. The team paused pre-releases, closed trunk to anything that isn't a 7.0 stability fix, and will announce the revised schedule by April 22.

The new schedule (or lack of one)

As of today, the only firm dates are:

• Pre-releases paused through April 17, 2026
• New release schedule announced no later than April 22, 2026
• General release target: late May 2026

Jonathan Desrosiers's follow-up, "The Path Forward for WordPress 7.0", also notes an unusual technicality: RC3 and RC4 will keep their "release candidate" version labels even though they behave more like betas in practice. This is a PHP version_compare() workaround, not a hidden concern. If you see RC3 land in the download directory over the coming weeks, do not assume the final release is imminent.

Why a delayed release is good news

I get it: delays are annoying when you have planned your week around a release. But the pattern is consistent. WordPress delays are almost always the right call.

WordPress 5.9 slipped roughly a month, from December 2021 to January 25, 2022, because Full Site Editing was not ready. A core contributor wrote at the time that the team was "rushing things in a dangerous way" and that it was "better to miss the expected target date than to rush potentially regrettable decisions." FSE would have shipped broken.

WordPress 6.5 slipped one week in 2024 because the Font Library was about to write into /wp-content/fonts, which many servers silently blocked. Release lead Aaron Jorbin defended the call: "This isn't a rash decision, it's about making the best decision for the users of WordPress with the information that is available at this point in time." The storage path was changed to /wp-content/uploads/fonts and the feature worked.

The 7.0 delay fits the same mold. A specific, identifiable regression (dead object caches on every live-edited post) was caught before release. I would rather read this article now than write the "WordPress 7.0 kills your Redis cache" post in June.

What to do with your staging rehearsal

If you already scheduled your staging test for the first week of April, reschedule it for the first week of June. Block a morning on the calendar and leave it there. The update will come when it comes.

A few practical things to do between now and then:

1. Stay on WordPress 6.9.4. The 6.9.x line had a rough patch cycle in March. 6.9.2 landed 10 security fixes, 6.9.3 repaired a template-loading regression introduced by 6.9.2, and 6.9.4 completed three CVE patches that weren't fully applied in the previous two releases. If you are on 6.9.3 or lower, update now.
2. Check your PHP version. WordPress 7.0 drops PHP 7.2 and 7.3. Sites on those versions will be blocked from updating. Tools > Site Health > Info > Server shows your current version. I wrote a separate piece on why PHP 8.1 reaching end of life matters even though WordPress core still supports it.
3. Keep testing nightlies on staging. If you have the WordPress Beta Tester plugin installed on a staging copy, leave it on the Bleeding Edge / Nightlies channel. The trunk is currently frozen to 7.0 stability fixes only, which makes nightly builds unusually useful for regression testing right now. My general take on staging workflows for WordPress updates still applies.
4. Re-test classic meta box plugins specifically. Real-time collaboration silently disables itself on any post that uses classic meta boxes. That is a deliberate design choice, not a bug, but also not something most plugin authors are aware of. If a client relies on an ACF-heavy edit screen, that screen will not get RTC. Better to discover that now than to explain it on launch day.
5. Do not rush 7.0 on day one. This has always been my advice for major WordPress releases, and the delay does not change it. Wait a week or two for the first point release. 7.0.1 typically lands 10 to 14 days after a major and fixes the things everyone missed.

Key takeaways

• WordPress 7.0 has been delayed from April 9 to late May 2026. The exact date will be announced by April 22
• The cause is a real-time collaboration storage design issue that was breaking persistent post caches. A new database table is being built to fix it
• The current stable production version is WordPress 6.9.4. Make sure you are on it
• A delayed WordPress release is almost always a better release. 5.9 and 6.5 followed the same pattern and shipped stronger for it
• Reschedule your staging rehearsal to early June, keep nightlies running on a staging copy, and check your PHP version while you wait