SiteRepairManual

WordPress fixes reproduced in a disposable install, verified end to end.

Fix a WordPress white screen of death

Checked 9 November 2026 · WordPress 7.1.4 · PHP 8.3.6 · MariaDB 10.11.14 · WP-CLI · Read time: 6 minutes

A white screen of death means a PHP fatal error stopped WordPress before it could print anything. The page gives you nothing to work with, so the first job is to make WordPress write the error down somewhere you can read it. That is what WP_DEBUG and WP_DEBUG_LOG do: the official debugging guide says WP_DEBUG_LOG saves errors to debug.log in the content directory, and that the log is the place to look when the error happens off-screen. The most common cause is a plugin — the official list of common errors says a plugin causing compatibility issues is the first thing to check, and to deactivate plugins and reactivate them one by one.

This guide reproduces the break first. A disposable install ran a small plugin that worked, then received a bad update that calls a function that does not exist. The homepage went from HTTP 200 to HTTP 500, the log named the plugin file and line, and deactivating that plugin brought the site back.

What you need

1. Confirm the symptom

Load the homepage and note the status code, not just what the browser shows. In the reproduction, the healthy site returned HTTP 200. After the bad plugin update it returned HTTP 500 with this message:

Output — homepage after the bad plugin update

HTTP 500, 2704 bytes
There has been a critical error on this website.

Key result: HTTP 500 plus “There has been a critical error on this website” is the modern white screen. The page itself names nothing — the cause is in the log, which is the next step.

WordPress 5.2 and later shows this critical-error page instead of a literal blank page. Older installs show a genuinely blank page. Either way, the diagnosis is the same.

2. Turn on WP_DEBUG and read the log

Add three lines to wp-config.php, before the line that reads /* That's all, stop editing! Happy blogging. */. The official guide is explicit that the defines must go before that line. With WP-CLI:

Command — enable debug logging

wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_LOG true --raw
wp config set WP_DEBUG_DISPLAY false --raw

WP_DEBUG_DISPLAY false keeps errors out of the page HTML while the log still records them. The official guide recommends this pairing on any site visitors can reach, and warns against leaving WP_DEBUG on live sites — it is a local and staging tool.

Then load the homepage once so the error is written, and read wp-content/debug.log:

Output — wp-content/debug.log

[09-Nov-2026 21:15:16 UTC] PHP Fatal error:  Uncaught Error: Call to undefined
function srm_broken_call_to_a_function_that_does_not_exist() in
.../wp-content/plugins/srm-broken/srm-broken.php:7

Key result: the log names the exact file, line, and function: wp-content/plugins/srm-broken/srm-broken.php, line 7. The plugin folder srm-broken is the culprit — no guessing, no deactivating everything at random.

Trap: a plugin that fatals the moment it loads cannot be activated in the first place — WP-CLI and the admin screen both refuse, because activation runs the plugin file. So if the site broke right after an update, the file changed after activation. That is the realistic trigger, and it is the one reproduced here: the plugin worked at version 1.0, and the 1.1 update broke it.

3. Deactivate the plugin that caused it

The obvious command does not work here, and the reproduction proved it. Plain deactivation loads WordPress, WordPress loads the active plugins, and the broken plugin fatals before WP-CLI can do anything:

Output — plain deactivation fails

$ wp plugin deactivate srm-broken
Fatal error: Uncaught Error: Call to undefined function
srm_broken_call_to_a_function_that_does_not_exist() in
.../wp-content/plugins/srm-broken/srm-broken.php:7
Error: There has been a critical error on this website.

The fix is --skip-plugins, a documented WP-CLI global parameter that loads WordPress without loading any plugins, so the fatal never fires:

Command — deactivate while skipping plugin loading

wp plugin deactivate srm-broken --skip-plugins

Output

Plugin 'srm-broken' deactivated.
Success: Deactivated 1 of 1 plugins.

Key result: with --skip-plugins, deactivation succeeds and the fatal error never runs. This is the step most guides skip — and the reason “just deactivate it with WP-CLI” fails on exactly the sites that need it most.

4. Verify the site is back

Load the homepage again and check the status code:

Output — homepage after deactivation

HTTP 200
<title>SRM Test</title>
StepHomepage status
Healthy site, plugin workingHTTP 200
After the bad plugin updateHTTP 500 — critical error page
After wp plugin deactivate --skip-pluginsHTTP 200

Then decide what to do with the plugin: leave it off and find a replacement, roll it back to the previous version, or report the fatal to its author with the log line. Do not just reactivate it — the same file will fail the same way. When the site is healthy, turn WP_DEBUG back off: it is meant for local testing and staging installs, not live sites.

Fallback: rename the plugin folder

If you have no WP-CLI access, the manual method in the official common-errors guide works too: rename the plugin folder, which deactivates it because WordPress can no longer find it. The reproduction verified this independently — a clean re-break (HTTP 500) followed by renaming wp-content/plugins/srm-broken to srm-broken-OFF returned the homepage to HTTP 200:

Command — rename the plugin folder

mv wp-content/plugins/srm-broken wp-content/plugins/srm-broken-OFF

If the white screen survives deactivating every plugin, the theme is the next suspect: the official guide says to switch to a default theme such as Twenty Twenty-Five, or rename the active theme folder the same way.

Summary

A white screen is a PHP fatal error with nowhere to show itself. Turn on WP_DEBUG with WP_DEBUG_LOG and WP_DEBUG_DISPLAY off, load the page once, and read wp-content/debug.log — it names the file and line. Deactivate that plugin with wp plugin deactivate --skip-plugins, because plain deactivation fatals on the same error you are trying to remove. Verify the homepage returns HTTP 200, then turn debugging off. If you have no WP-CLI, rename the plugin folder instead.

Sources