WordPress not working after a PHP upgrade: error 500, blank page or critical error

By CompatNav · Published · Last reviewed · 4 min read

Short answer

After a PHP upgrade, a WordPress site fails in one of three ways, and all three answer with HTTP error 500: WordPress’s critical error page (a plugin or theme stopped on the new version), a “Requirements Not Met” page or a one-line message (a PHP extension is missing in the new version), or a blank page (the error happened before WordPress could show its own page). In every case, switch back to the previous PHP version first: the site works again at once. Then find the cause from the message or the error log, fix it, and check every plugin and theme before switching again.

First: get the site back

Open your hosting control panel and set PHP back to the version the site ran before. The site works again at once, and nothing is lost: how to downgrade PHP shows where the setting is and what to watch out for. Then come back and find the cause calmly.

What you see, and what it means

What you seeHTTP statusWhat it means
“There has been a critical error on this website.”500A plugin, the theme or other code stopped with a fatal error on the new PHP version
“Requirements Not Met” and a line about the MySQL extension, or “WordPress … requires the … PHP extension”500The new PHP version lacks an extension WordPress can’t run without
A blank page500A fatal error before WordPress could show its own page, or with WordPress’s error page turned off
Your host’s own error pagedependsSomething on the server, before PHP ran: ask your host

We reproduced the second and third on the official PHP 8.4.26 build, with WordPress 7.1.2 for the second:

  • Without the mysqli extension, WordPress answered status 500 with a page titled “Requirements Not Met” saying “Your PHP installation appears to be missing the MySQL extension which is required by WordPress.” (WordPress 7.1.2 source)
  • A fatal error with PHP’s error display turned off gave status 500 and a completely empty page.

WordPress’s critical error page also comes with status 500 (WordPress 7.1.2 source). So “error 500” alone doesn’t tell you which case you have; the message, the email and the error log do.

Find the cause

A critical error

WordPress emails the site’s administrator with the plugin or theme that stopped, and a link to log in and pause it. The error message in the log names the file. “There has been a critical error” after a PHP update walks through both, and the PHP changes that cause it most.

A missing extension

This is a server setting, not your code. Ask your host to enable the extension for the new PHP version (mysqli for the database, json on PHP 7.4). Once the site loads, Site Health lists the other extensions it needs: “One or more required modules are missing”. For json: WordPress requires the json PHP extension.

A blank page

There’s no message on screen, so read the error log. If your site has none yet, the WordPress debug log shows how to write one without showing errors to visitors; developer.wordpress.org recommends exactly that: debug tools “are meant for local testing and staging installs” (developer.wordpress.org), not for display on a live site. One place to look first: wp-config.php, and any file it loads. That code runs before WordPress has its error page ready, so a fatal error there shows as a blank page.

Before you switch again

The plugin that stopped the site is the first one PHP reached, not necessarily the only one. Check all of them for the version you’re moving to, on the site that now runs the old version again:

  1. Check every plugin and your theme for the new PHP version.
  2. Update, replace or fix everything marked “Will break”.
  3. Switch again at a quiet time, and watch the error log for a week.

CompatNav is a free plugin on wordpress.org for step 1: it reads the code of every plugin and theme on your own server and reports only what changes between the PHP version the site runs and the one you choose (8.0 to 8.5). One example of what it finds: a function PHP 8.0 removed, which stops the page at its first call:

It reads code without running it, so it can’t see a missing extension or problems that depend on data; that’s what the week of watching the log is for. The upgrade checklist has every step on one page.

Key takeaways

  • Critical error page, “Requirements Not Met”, or a blank page: all three are HTTP 500.
  • Switch back to the previous PHP version first; it changes no content.
  • A critical error names its cause in WordPress’s email and in the error log: usually a plugin or theme.
  • A missing extension (mysqli, json) is a server setting for your host, not a code problem.
  • Before switching again, check every plugin and theme for the new version, not only the one that stopped.

Frequently asked questions

Why do I only see an error 500, without a message?

500 is the HTTP status the server sends with the failed page. WordPress’s own pages carry it too; with a blank page, it’s all you get. The error log has the actual message.

Can the PHP upgrade have damaged my site?

No. Changing the PHP version doesn’t change your posts, pages, settings or files. Switch back, and the site is as it was.

Only some pages fail. Is that the same problem?

Usually yes: a plugin’s code runs only where it’s used, such as a form, a shop page or the admin area. The error log shows which file failed.

Check your own site before you upgrade

CompatNav is a free WordPress plugin. It reads the code of your plugins and themes on your own server and tells you, in plain words, what will break and what will only show notices on the PHP version you choose. It never changes your code. It can’t see problems that only appear while code runs with real data, so a quick check of your site after the upgrade still matters.

Get CompatNav on wordpress.org How it works

Sources

About the code examples: each output is the real output of the code shown, run with the official PHP builds, without a php.ini, with all errors reported and displayed. Only the file path was replaced by a neutral server path.