WordPress 7.0 lands on 20 May 2026. That is a firm date, but it is also a revised one. The core team’s March announcement confirmed that the original 9 April release was pushed back because the database architecture underpinning Real-Time Collaboration could not be resolved in time. That delay matters beyond the calendar: it tells you something about the complexity sitting inside this release and how much was still in flux just weeks before launch.
Release Candidate 3 arrived with 143 or more issues addressed since RC2. That volume of late-cycle fixes is not a sign of polish. It is a sign of a release that has been under sustained pressure, and one that deserves careful handling before it touches a live site.
The official RC3 notice is unambiguous: this build must not be installed on production or mission-critical websites. Testing only, on a staging server. That guidance applies to the release candidates, but the same discipline should carry through to the full release for any business that cannot afford downtime.
Real-Time Collaboration has been pulled from 7.0, and that creates a specific risk for sites built around it
The headline feature of this release cycle, Real-Time Collaboration, will not ship in 7.0. The RC3 announcement confirmed it has been removed entirely and will be re-evaluated during the 7.1 release cycle. The reason given was the same one that caused the April delay: the underlying database architecture was not ready.
For most sites, this is simply a feature that did not arrive on time. For sites where developers or agencies built plugins, custom blocks, or theme functionality in anticipation of collaborative editing being present in 7.0, the situation is different. If any code on your site was written to hook into Real-Time Collaboration infrastructure that no longer exists in this version, that code will either fail silently or throw errors. You may not know about it until a customer or staff member hits a broken page.
The technical changes in 7.0 add further complexity: DataViews API changes, classic meta box conflicts with collaborative editing remnants, Block API v3 alignment, and PHP version requirement changes all have the potential to break plugins and themes that have not been updated to account for them. A plugin that worked perfectly on 6.7 may behave differently under 7.0’s revised API surface. That is not a worst-case scenario; it is a predictable outcome when major API versions change.
PHP version requirement changes deserve particular attention. If your hosting environment is running a PHP version that falls below the new minimum, your site will not function correctly after the upgrade. This is the kind of issue that goes unnoticed during casual testing but brings down a checkout page or a membership portal on a Tuesday morning.
What a staged upgrade should look like before 20 May
The time between now and 20 May is the window to test. Applying a major WordPress version directly to a live, trading website without prior testing is a choice that routinely results in broken functionality, failed payments, or locked-out admin areas. The 7.0 release has had a complicated development cycle, which makes skipping the testing stage a higher-risk decision than it might be with a minor point release.
A staging environment should be a current copy of your production site, not a clean install. It needs your actual plugins, your actual theme, and your actual content, because compatibility failures almost always appear in the interaction between components, not in isolation. Once you have applied 7.0 to staging, the things worth checking include:
- Any plugin or custom code that was built to work with collaborative editing features
- Classic meta boxes in the editor, which have a documented conflict with the collaborative editing architecture even in its removed state
- Plugins that interact with the DataViews or Block APIs, particularly page builders, custom block libraries, and admin UI plugins
- Your PHP version at the server level, confirmed against the new minimum requirement
- WooCommerce or any e-commerce layer, tested end-to-end through checkout
If your site has not had a proper staging environment set up, now is the right time to build one. Running a major update on a copy of your site before touching the live version is standard practice for any site where downtime costs money.
One angle that often gets overlooked: automatic updates. Many managed hosting platforms apply WordPress core updates automatically, sometimes within hours of a release. If your site is set to update automatically and you have not tested 7.0 on staging, the decision about when to upgrade may be made for you. Checking and, where appropriate, pausing automatic updates before 20 May gives you control over the timing rather than discovering a broken site after the fact.
If you want a second pair of eyes on your site before 7.0 arrives, or if you need a staging environment set up and tested properly, get in touch with The WordPress Guy. I work directly with business owners to make sure major WordPress updates do not become an unplanned incident on a trading site.
