WordPress 7.0 Critical Error After Update: Why It Happens and How to Fix It Fast

Since WordPress 7.0 shipped on May 20, 2026, our ticket queue has filled up with a familiar message: “There has been a critical error on this website.” If you clicked update and your site went white, broke the dashboard, or knocked out checkout, you are not alone — and it is almost never bad luck. It is usually one of four specific things, and three of them you can check in the next ten minutes.

Why WordPress 7.0 is breaking more sites than a typical release

Most core updates are boring on purpose. WordPress 7.0 isn’t, because it quietly raised the floor on what your server needs to run it.

The minimum PHP version is now 7.4. Sites still on PHP 7.2 or 7.3 don’t get force-updated to 7.0 — WordPress holds them back on the 6.9 branch instead. If your host auto-updated you anyway, or you manually forced the update, a PHP mismatch is the first thing to rule out.

The minimum MySQL version jumped to 8.0, up from 5.5.5 in WordPress 6.9. This is the one catching people off guard, because nobody reads database changelogs. WordPress 7.0’s new DataViews admin screens rely on query patterns — common table expressions and window functions — that only work correctly on MySQL 8.0. Run those same queries against MySQL 5.6 or 5.7, which is still what a lot of budget shared hosting ships by default, and they fail outright or return silently wrong data. That is a critical error waiting to happen the moment you touch certain admin screens.

Plugins and themes built against the old admin hooks. Anything that adds custom columns, filters, or bulk actions to wp-admin screens was written for the pre-DataViews interface. WordPress 7.0 changes enough underneath that outdated plugins throw fatal errors instead of just looking a little off.

Classic meta boxes and collaboration mode. If your theme or a plugin still registers classic meta boxes, WordPress 7.0 quietly disables real-time collaboration for that post type — not usually a critical error on its own, but it compounds with the other three when a site is already running old code.

Put those together and the sites most at risk are exactly the ones you’d guess: older themes, a stack of plugins nobody has audited in a year, and hosting that has not moved off MySQL 5.7. If that describes your setup, an update that looks routine can take the whole site down.

How to tell which one hit you

Before you touch anything, get a real answer instead of guessing. Two ways in:

1. Check your inbox. WordPress emails the site admin when a fatal error is detected, usually with the exact file and line. Check spam — it gets filtered constantly.
2. Turn on debug logging. Add this to wp-config.php above the line that says “That’s all, stop editing”:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Reload the site, then check /wp-content/debug.log. The top entry after the reload is almost always your culprit — a plugin file path, a database error, or a PHP version mismatch spelled out in plain text.

The fast fixes, in order

1. Confirm your PHP and MySQL versions. Most hosting control panels show this on the main dashboard. You need PHP 7.4+ (8.3 recommended) and MySQL 8.0+. If you’re below either, that is very likely your critical error, full stop — and no amount of plugin deactivation will fix a database version mismatch.

2. Use WordPress Recovery Mode. If you got the recovery email, the link inside deactivates the offending plugin automatically without touching anything else. This is the least destructive fix and works even if you can’t reach wp-admin normally.

3. Deactivate plugins manually via file manager or SFTP. No recovery email, no dashboard access? Rename /wp-content/plugins to /wp-content/plugins-off through your host’s file manager. This deactivates everything at once. If the site comes back, rename it back and reactivate plugins one at a time until the error returns — that last one is your problem plugin.

4. Switch to a default theme. If plugins aren’t the cause, do the same trick with your theme folder, or activate a fallback theme like Twenty Twenty-Five via the database if wp-admin is reachable.

5. Roll back to WordPress 6.9 if you’re on incompatible infrastructure. If the real issue is your host’s MySQL version and they can’t upgrade it quickly, rolling back core is the fastest way to get a revenue-critical site back online while you sort out hosting separately. This is not a permanent fix — 6.9 will eventually lose security support — but it buys you time.

6. Ask your host directly about MySQL 8.0. If they’re still on 5.6 or 5.7, get a timeline in writing before you update anything else on that account. Some hosts treat this as a full server migration, which means planning around downtime rather than a quick patch.

The bigger risk: this won’t be the last one

WordPress 7.0 is a preview of where core is headed — tighter database requirements, a rebuilt admin, and less patience for legacy code. If this update took your site down, the same gap will catch you again on 7.1 or 7.2 unless the underlying stack gets fixed, not just patched around.

That means auditing plugins against current WordPress standards, confirming your host’s roadmap for PHP and MySQL versions, and testing major updates on staging before they touch production — every time, not just this once.

If your site is down right now

Every hour a critical error sits on a live site is lost traffic, lost trust, and for WooCommerce stores, lost sales. If you don’t have the time or patience to dig through debug logs and hosting control panels tonight, send us the URL and what broke — we diagnose fatal errors and white screens fast, usually the same day, and we’ll tell you plainly if the real fix is a plugin, a rollback, or a hosting conversation you need to have.

And if you’d rather not do this again on WordPress 7.1, our maintenance plans cover core, plugin, and theme updates on staging first, so the critical error happens on a test site instead of your live one.

FAQ

Is it safe to update to WordPress 7.0 yet?
Testing so far hasn’t turned up widespread core bugs — most breakage traces back to outdated plugins, old themes, or hosting that hasn’t caught up to the new PHP and MySQL minimums. Test on staging first if your site runs custom code, multiple plugins, or revenue-critical workflows.

Why does WordPress 7.0 need MySQL 8.0?
The new DataViews admin screens use common table expressions and window functions that require MySQL 8.0’s query engine. Older MySQL versions either error out or return incorrect results on those queries.

Can I downgrade from WordPress 7.0 back to 6.9?
Yes, via a plugin like WP Downgrade or by manually reinstalling the 6.9 core files after a full backup. It’s a valid short-term fix if your hosting isn’t ready for 7.0’s requirements yet.

What does “There has been a critical error on this website” actually mean?
It means PHP hit a fatal error and WordPress caught it before showing a raw error to visitors. The real cause — a plugin conflict, a database mismatch, a PHP incompatibility — is in your debug log or the recovery email, not in that generic message.