The fourth Release Candidate for WordPress 7.0 was published on 14 May 2026, six days before the scheduled final release on 20 May 2026. If you run a website that takes orders, generates leads, or represents your business to customers, that date proximity might tempt you to update quickly once the final version drops. I’d encourage you to resist that instinct, and here is why.
The WordPress 7.0 RC4 announcement states explicitly that this software is still under development and is not suitable for production or mission-critical websites. That language is precise and deliberate: the RC phase exists so developers can catch remaining bugs before the public release. When a fourth candidate is needed, it tells you the team has been working through a meaningful volume of issues right up to the final week.
WordPress 7.0 is also not a routine update. In March 2026, the release cycle was extended specifically because the database architecture underpinning the new real-time collaboration feature needed more time to get right, and the April 2026 developer blog set out what that extension meant in practice. The core team made the right call by taking the time, but a release cycle pushed back due to unresolved technical complexity carries more risk than a standard point release. This version touches deeper infrastructure than most.
WordPress 7.0 changes the API surface that your plugins and themes depend on
The WordPress 7.0 technical overview identifies several breaking changes arriving simultaneously: DataViews API changes, conflicts between classic meta boxes and the new collaborative editing system, Block API v3 alignment requirements, and updated PHP version requirements. Any one of those could cause a plugin you rely on to stop working. All four arriving together in a single update raises the probability of a conflict considerably.
PHP version requirements deserve particular attention if you are on managed hosting. If WordPress 7.0 requires a PHP version your hosting environment does not currently run, you may see a white screen, broken admin access, or a site that loads incorrectly for every visitor. Your hosting provider may need to act before the WordPress update can safely proceed, and that coordination takes time you will not have if you update on the day of release without planning ahead.
Plugin and theme developers have had access to the beta and release candidate builds throughout the testing cycle, as the release tracker at AttoWP confirms is standard practice for major versions. Some will have updated their products already. Others will not have done so by 20 May, and those are precisely the ones most likely to be installed on your site without you realising they are a problem.
The cost of a site going down after an untested update is not just a technical inconvenience
Every hour your website is broken is revenue that does not arrive. A site that goes down on a Tuesday morning and takes until Wednesday to recover has cost you whatever you would normally earn in that window, and customers who encounter a broken checkout will not wait. They will go elsewhere, and most will not come back to try again. Reputational damage compounds that loss: a broken site signals to visitors that the business behind it is not being looked after, and for a business that has invested in its brand and its customer relationships, that impression is hard to walk back.
There is one consequence that business owners rarely consider until it has already happened. If a WordPress update breaks a plugin that handles customer data, such as a booking system, a membership platform, or a WooCommerce extension, the failure goes beyond a display error. Corrupted data, incomplete transactions, or failed order records can take hours to untangle and may require manual reconciliation, taking time away from running the business, and in some cases the data loss cannot be fully recovered.
The correct approach is to test the update in a staging environment before it touches your live site. A staging environment is an identical copy of your website, running separately from the version your customers see. You apply the update there first, check that every plugin, theme, and integration still works as expected, and only then promote the change to the live site. If something breaks in staging, it breaks privately, with no customer impact and no revenue lost.
If you want the 7.0 update applied safely, with staging testing completed before anything touches your live site, get in touch with The WordPress Guy. I handle the technical side so you can take the update on your terms, not under pressure from an automatic update prompt.
