WordPress 7.0 is scheduled to release on 20 May 2026. If your business runs on WordPress, that date is close enough to warrant action now rather than after the fact. The question is not whether to update, but how to do it without taking a trading site offline or breaking functionality your customers depend on.
The release has already been delayed once. On 31 March 2026, the WordPress core team announced it would not ship on 9 April as originally planned. The reason: the database architecture underpinning Real-Time Collaboration had not been resolved to a standard the team considered safe to ship. That delay pushed the cycle out by six weeks and produced three release candidates instead of the usual one or two.
Release Candidate 3 alone addressed 143 or more issues since RC2. That figure tells you something about the state of the codebase as it approaches final release. A version that requires that volume of fixes in a single candidate cycle deserves careful testing before it touches a live site.
Real-Time Collaboration has been pulled from 7.0, and that creates a specific risk for plugins built to expect it
Real-Time Collaboration will not ship in WordPress 7.0. It has been pushed to the 7.1 release cycle entirely. For most site owners that sounds like good news: one less moving part in a major update. The risk sits with plugin and theme developers who built features in anticipation of the Real-Time Collaboration infrastructure being present in 7.0. Any plugin that assumed those APIs would be available could behave unpredictably when it finds they are absent.
This is not theoretical. Plugin developers work to published roadmaps, and the original schedule put Real-Time Collaboration in 7.0. Developers who built integrations, editorial workflows, or admin interfaces on that assumption have had to adjust quickly. Some will have released compatibility updates. Others may not have done so before 20 May. If you are running editorial or collaborative tools inside WordPress, checking their current compatibility status before the update is the single most important thing you can do in the next two weeks.
Beyond the Real-Time Collaboration removal, WordPress 7.0 introduces DataViews API changes, Block API v3 alignment, classic meta box conflicts with collaborative editing, and PHP version requirement changes. Each of those has the potential to break something on a site that has not been tested. The PHP requirement change alone can bring a site down entirely if the hosting environment has not been updated to match.
Testing on a staging environment before 20 May is the only way to know what 7.0 will do to your specific site
The WordPress core team is explicit that release candidates must not be installed on production or mission-critical websites. That guidance applies to the release candidates, but the principle carries forward to the final release on any site where downtime has a cost. A staging environment is a copy of your live site running on a separate server. You apply the update there, confirm that your plugins work, your theme renders correctly, and your checkout or booking process completes without error. Then, and only then, you apply it to the live site.
The staging test should cover more than a visual check of the homepage. The areas most likely to fail after a major WordPress update are custom integrations, plugins that extend the admin interface, anything that touches the database directly, and forms connected to third-party services. If your site has any of those, they need to be tested against the new version explicitly.
PHP version compatibility deserves particular attention here. If your hosting account is running PHP 7.4 or 8.0, and WordPress 7.0 raises its minimum PHP requirement, your site will throw fatal errors the moment the update completes. Your host can tell you which PHP version your account is running. Checking that takes five minutes. Recovering from a fatal error on a live site takes considerably longer, and the damage to customer confidence in the interim is harder to quantify.
There is one angle that tends to get overlooked in pre-update planning: database backup timing. Most businesses back up their WordPress database on a schedule, often nightly. If a major update breaks something and the most recent clean backup is eighteen hours old, you lose eighteen hours of orders, form submissions, or user registrations when you restore. Taking a manual backup immediately before the update runs means the rollback point is current. This applies whether the update is applied manually or through automatic updates, which some hosts enable by default on major versions.
WordPress 7.0 is a significant release. The delay, the number of fixes in the final candidate cycle, the removal of a headline feature, and the underlying API changes all point to a version that warrants proper preparation before it is applied to a site that generates revenue. If you would rather not manage that process yourself, I can handle the staging test, the compatibility checks, and the controlled update on your behalf at The WordPress Guy.
Get in touch before 20 May and I will make sure the update goes smoothly.
