If your site showed "There has been a critical error on this website" or a blank white screen right after your host upgraded (or you manually upgraded) PHP to 8.1, the fastest safe move is to revert the PHP version first to get the site back online, then diagnose the actual cause afterward. PHP 8.1 introduced stricter deprecation and type-handling behavior — most commonly, passing null to internal PHP function parameters that no longer accept it implicitly — which older plugins and themes not yet updated for 8.1 can trip over hard enough to cause a fatal error instead of just a warning.

Symptoms

  • "There has been a critical error on this website. Please check your site admin email inbox for instructions" shown to visitors, or a blank white screen with no message at all.
  • This started immediately after a PHP version change — either you changed it manually in your hosting panel, or your host auto-upgraded PHP on your account.
  • wp-admin may be equally broken, or in some cases still partially accessible (this depends on where exactly the fatal error occurs in the request).
  • The site worked fine on the previous PHP version with no changes to plugins, themes, or content.

Likely causes, in order of how often they actually happen

  1. A plugin or theme not yet updated for PHP 8.1 compatibility hits a fatal type error. PHP 8.1 made several previously-tolerated patterns throw deprecation notices instead of silently working — most commonly, passing null where a function parameter expects a string, array, or other non-nullable type. On PHP 8.0 and earlier this was often just a silent warning; on 8.1 and later, in some configurations and with error-reporting settings that surface these as fatal, it can bring down the whole page. Plugins with lower long-term maintenance (abandoned or infrequently updated ones) are the most common source.
  2. A theme's functions.php or a custom code snippet uses an outdated PHP pattern. Same root cause as above, but in custom or lightly-maintained theme code rather than a well-known plugin, which makes it slightly harder to identify by just checking a changelog.
  3. A required PHP extension isn't enabled on the new PHP 8.1 environment. Less common, but when hosts provision a new PHP version, not every extension the site depended on (e.g., certain image, mail, or database extensions) is necessarily enabled by default under the new version, which can also present as a fatal error immediately after the switch.

A laptop screen showing programming code and debugging tools, ideal for tech topics.

Fix it: lowest-risk steps first

Step 1 — Revert the PHP version via your hosting panel to get the site back up immediately

This is the fastest way to stop the bleeding and costs nothing — reverting doesn't lose any data, it only changes which PHP interpreter runs your existing files.

  1. Log in to your hosting control panel (cPanel's "Select PHP Version," Plesk's PHP settings, aaPanel's site settings, or your host's equivalent).
  2. Find the PHP version selector for your specific site/domain.
  3. Switch it back to the PHP version the site was running before the upgrade (commonly PHP 8.0 or 7.4, depending on your prior setup).
  4. Reload the site and confirm it's back to working normally.

With the site back online, you now have breathing room to diagnose the real cause without visitors seeing a broken page in the meantime.

Step 2 — Enable WP_DEBUG_LOG to capture the exact fatal error and its source file

Do this on a staging copy of the site if you have one, or during a low-traffic window on the live site if you don't — the goal here is just to read the log, not to display errors publicly.

  1. Connect via FTP/SFTP or your file manager and open wp-config.php in the WordPress root.
  2. Find the line define('WP_DEBUG', false); (or add it near the top if it isn't present) and set it to: 
    define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
    Setting WP_DEBUG_DISPLAY to false keeps errors out of the public-facing page while still logging them.
  3. Switch the PHP version back to 8.1 temporarily on a staging site (or briefly on live, if that's your only option, during low traffic) so the actual fatal error under 8.1 gets logged.
  4. Reproduce the critical error by loading the site once.
  5. Open wp-content/debug.log via FTP/file manager and look at the most recent entries — the fatal error line will typically name the exact file and line number where the error occurred (for example, a specific plugin's file path under wp-content/plugins/), and often the specific function and argument type involved.
  6. Once you've captured the relevant log lines, switch PHP back to your stable/reverted version (Step 1) if you were testing on the live site.

Step 3 — Identify whether the fatal error is from a plugin, theme, or core, and decide: update, replace, or wait

With the exact file path from the debug log in hand:

  • If the error points to a file under wp-content/plugins/[plugin-name]/: check that plugin's page in the WordPress plugin directory (or its changelog) for a note about PHP 8.1 compatibility, and check whether a newer version is available. If yes, update just that plugin (ideally on staging first) and retest under PHP 8.1.
  • If no compatible update exists and the plugin appears abandoned (no updates in over a year, no response to support requests), look for an actively maintained alternative plugin that covers the same functionality, and plan a migration rather than waiting indefinitely.
  • If the error points to the active theme's functions.php or a custom code file: the specific line and function named in the log tells you exactly what needs a compatibility patch (commonly, adding a null-coalescing check like $value ?? '' before passing a variable into a function that no longer accepts null). This may need a developer if you're not comfortable editing PHP directly.
  • If you'd rather not touch code right now: it's entirely reasonable to stay on the reverted, working PHP version for a while longer and revisit the PHP 8.1 upgrade once the specific plugin or theme has published a compatible update — just be aware most hosts eventually stop supporting older PHP versions, so this isn't a permanent option.

Verify the fix

  1. With the fix applied (updated plugin, patched theme code, or extension enabled) and PHP set back to 8.1, load the site as a logged-out visitor and confirm no critical error appears.
  2. Check wp-content/debug.log again after reproducing the same page load — confirm the specific fatal error is gone (new unrelated notices may still appear; focus on the one you fixed).
  3. Turn WP_DEBUG and WP_DEBUG_DISPLAY back to false in wp-config.php once you're done debugging — leaving debug mode on publicly is a security and performance issue, not just a cosmetic one. You can leave WP_DEBUG_LOG on for a while longer if you want continued logging, since it doesn't display anything publicly.
  4. Spot-check a few key pages and any functionality tied to the plugin/theme you patched, not just the homepage.

If you need to roll back

If updating the plugin or patching the theme code doesn't resolve the fatal error, or introduces new problems, deactivate that specific plugin (Plugins → Deactivate) or switch back to a default theme temporarily, and confirm the site loads under PHP 8.1 without it — this confirms the diagnosis even if you're not ready with a permanent fix yet. If nothing short of reverting PHP works, staying on the older, stable PHP version (Step 1) is a completely valid medium-term choice while you plan the plugin/theme fix or replacement properly, rather than leaving the site broken in the meantime.

Related fixes

FAQ

Why did the site break only after a PHP upgrade, when nothing else changed?

PHP version upgrades change how the interpreter itself handles ambiguous code patterns — code that PHP 8.0 tolerated silently can become a hard fatal error under PHP 8.1's stricter type-handling rules, even though the plugin or theme file itself wasn't touched. The bug was arguably always there; PHP just stopped being lenient about it.

Is it better to just stay on an older PHP version permanently?

Not long-term. Older PHP versions eventually stop receiving security updates, and most hosts phase out support for them, sometimes forcing an upgrade later with even less notice. Reverting is the right immediate fix, but plan to actually resolve the plugin/theme compatibility issue rather than treating the older PHP version as a permanent solution.

Can I find the problem without enabling WP_DEBUG_LOG?

It's much harder. Some hosts provide their own PHP error logs accessible through the control panel (look for "Error Log" or "PHP Error Log" in cPanel or your host's panel) which can sometimes show the same fatal error without touching wp-config.php at all — check there first if you'd rather not enable WordPress's own debug logging.

Do I need a staging site to do this safely?

It's strongly recommended but not strictly required. If you don't have one, do the PHP 8.1 test-and-log step (Step 2) during your lowest-traffic period, keep WP_DEBUG_DISPLAY set to false so visitors never see raw error output, and revert PHP immediately after capturing the log entry you need.