How I Fixed WordPress White Screen of Death — What Actually Worked

—
title: “How I Fixed WordPress White Screen of Death — What Actually Worked”
slug: “how-i-fixed-wordpress-white-screen-of-death”
meta_description: “My WordPress site went blank on Coolify mid-update. Here’s the debug-first fix that actually worked — not FTP, not guessing, just reading the log.”
primary_keyword: “WordPress white screen of death”
secondary_keywords: [“WordPress blank screen fix”, “WordPress WSOD WP-CLI”, “fix WordPress white screen without admin”, “WordPress debug mode wp-config”, “WordPress white screen Coolify”]
category: “WordPress Fixes”
tags: [“WordPress”, “Debugging”, “WP-CLI”, “Coolify”, “PHP errors”, “Docker”]
pattern: “error-fix”
cta_link: “[WP_ROCKET_AFFILIATE]”
cta_context: “WP Rocket’s caching layer prevents the class of plugin conflicts that cause WSOD — described naturally as a prevention tool in Section 6”
content_angle: “Debug-first approach from a Coolify/Docker environment with actual WP-CLI commands — not the generic ‘disable all plugins via FTP’ advice”
—

# How I Fixed WordPress White Screen of Death — What Actually Worked

My WordPress site went blank mid-update. No error message. No 404. Just a white page on both the frontend and the admin. If you’re staring at the same thing right now, here’s what actually fixed it — and why the advice most tutorials lead with is the last thing you should try.

## What I Tried First (And Why It Didn’t Work)

The first thing I did was clear the browser cache and reload. That fixed nothing — the white screen of death is a server-side problem, not a client-side one. Still worth ruling out, but don’t count on it.

Next I tried logging into the WordPress admin to disable plugins the normal way. Couldn’t. The WSOD had locked me out of both the front end and the back end at the same time. This is the most frustrating version of the problem.

The advice Google returns first is usually “disable all plugins via FTP.” I’m running WordPress on Coolify with Docker, so traditional FTP isn’t part of my setup. But even if it were — disabling every plugin before you know which one caused the issue means you’re flying blind. You’d fix the symptom without knowing the cause. The next plugin update would probably do it again.

There’s also the `.maintenance` file trap. If a WordPress update was interrupted, a file called `.maintenance` can get left in your site root and produce a white screen indefinitely. Worth checking:

“`bash
# Check for a stuck maintenance file
ssh coolify-vps “docker exec wordpress-n0g4skoo8sgwgc848koog0ww ls /var/www/html/.maintenance”

# If it exists, delete it
ssh coolify-vps “docker exec wordpress-n0g4skoo8sgwgc848koog0ww rm /var/www/html/.maintenance”
“`

In my case it wasn’t there. The problem was something else — and I needed WordPress to tell me what.

## What Actually Fixed It

The fix started with one decision: make WordPress show me the actual error instead of a blank screen.

### Step 1: Enable WP_DEBUG

WordPress ships with debug mode off. That’s correct for production, but it means fatal PHP errors produce nothing visible — hence the white screen. Turning on debug mode writes errors to a log file you can read.

SSH into your VPS and edit wp-config.php:

“`bash
# Enter the WordPress container on Coolify
ssh coolify-vps
docker exec -it wordpress-n0g4skoo8sgwgc848koog0ww bash

# Open wp-config.php
nano /var/www/html/wp-config.php
“`

Add these three lines near the top, before the `/* That’s all, stop editing! */` comment:

“`php
define( ‘WP_DEBUG’, true );
define( ‘WP_DEBUG_LOG’, true );
define( ‘WP_DEBUG_DISPLAY’, false );
“`

`WP_DEBUG_DISPLAY` is deliberately `false`. You don’t want raw PHP errors printed on your live site where visitors can see them. The log file is where you’ll look.

Save the file and reload your site. The white screen will probably still be there — but WordPress is now silently logging what caused it.

### Step 2: Read the Debug Log

“`bash
tail -50 /var/www/html/wp-content/debug.log
“`

This is where the case gets solved. In my situation the log showed:

“`
[04-Jun-2025 08:41:22 UTC] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted
(tried to allocate 20480 bytes) in /var/www/html/wp-content/plugins/advanced-custom-fields/includes/acf-value-functions.php on line 412
“`

Memory exhaustion. Not a code corruption, not a version conflict — a plugin trying to allocate more RAM than WordPress had budgeted. The log told me exactly which plugin file triggered it, which means I didn’t have to guess.

Common things you’ll see in the log and what they mean:

– **`Allowed memory size exhausted`** → PHP memory limit too low, or a plugin has a memory leak
– **`Call to undefined function`** → A plugin or theme is calling a function that doesn’t exist (usually a missing dependency or a version mismatch)
– **`Parse error: syntax error`** → A PHP file has broken syntax (often from a manual edit gone wrong)
– **`Maximum execution time exceeded`** → A script is running too long (database query, external API call)

### Step 3: Deactivate the Problem Plugin

Once the log pointed me to the specific plugin, I deactivated it via WP-CLI without needing admin access:

“`bash
# List all active plugins to confirm the folder name
docker exec wordpress-n0g4skoo8sgwgc848koog0ww wp plugin list –status=active –allow-root

# Deactivate the specific plugin
docker exec wordpress-n0g4skoo8sgwgc848koog0ww wp plugin deactivate advanced-custom-fields –allow-root
“`

After deactivating, I reloaded the site. White screen gone. Now I knew the cause and could fix it properly instead of just disabling something and hoping.

### Step 4: Fix the Root Cause

The plugin itself wasn’t broken — it just needed more memory than WordPress’s default 128MB allows. The actual fix was a one-line addition to wp-config.php:

“`php
define( ‘WP_MEMORY_LIMIT’, ‘256M’ );
“`

Add this just above the “stop editing” comment in wp-config.php. Then reactivate the plugin:

“`bash
docker exec wordpress-n0g4skoo8sgwgc848koog0ww wp plugin activate advanced-custom-fields –allow-root
“`

Reloaded the site. Everything back to normal.

If your log shows a **syntax error** instead of a memory issue, the fix is different — find the file the log mentions, open it, and look for broken PHP near the line number it reports. This usually happens after manually editing functions.php or adding a code snippet in the wrong place.

### Step 5: Turn Off Debug Mode

Easy to forget. Leave `WP_DEBUG` on in production and your debug.log will grow indefinitely. It can also expose internal file paths and error details that you’d rather not be public.

Go back to wp-config.php and set:

“`php
define( ‘WP_DEBUG’, false );
“`

Or remove the three debug lines entirely — WordPress defaults to debug off.

## Quick Reference

“`bash
# ── DIAGNOSIS ──

# Enter WordPress container (Coolify — replace container name with yours)
ssh coolify-vps
docker exec -it YOUR_WP_CONTAINER bash

# Check for stuck maintenance file
ls /var/www/html/.maintenance
rm /var/www/html/.maintenance # if it exists

# Enable debug logging (edit wp-config.php)
nano /var/www/html/wp-config.php
# Add these three lines:
# define( ‘WP_DEBUG’, true );
# define( ‘WP_DEBUG_LOG’, true );
# define( ‘WP_DEBUG_DISPLAY’, false );

# Read the debug log
tail -50 /var/www/html/wp-content/debug.log

# ── FIX ──

# List active plugins
wp plugin list –status=active –allow-root

# Deactivate a specific plugin
wp plugin deactivate PLUGIN-FOLDER-NAME –allow-root

# Increase memory limit (add to wp-config.php)
# define( ‘WP_MEMORY_LIMIT’, ‘256M’ );

# Reactivate plugin after fixing root cause
wp plugin activate PLUGIN-FOLDER-NAME –allow-root

# Switch to a default theme (if theme is the culprit)
wp theme activate twentytwentyfour –allow-root

# ── CLEANUP ──

# Turn off debug mode when done
# Set: define( ‘WP_DEBUG’, false );

# Flush cache after fix
wp cache flush –allow-root
“`

## Frequently Asked Questions

**What is the most common cause of the WordPress white screen of death?**

Plugin conflicts and PHP memory exhaustion are the two most common causes. A recently updated plugin may conflict with your PHP version, another plugin, or your theme. Memory exhaustion happens when a plugin needs more RAM than WordPress’s default 128MB limit allows — common on shared hosting or VPS setups with tight default resource allocation.

**How do I fix WordPress white screen without access to the admin dashboard?**

Use WP-CLI from SSH. You can deactivate all plugins with `wp plugin deactivate –all –allow-root`, or target a specific plugin if you know which one caused the issue. You can also switch to a default theme with `wp theme activate twentytwentyfour –allow-root`. Neither requires admin dashboard access.

**Does clearing the cache fix the WordPress white screen of death?**

Not on its own — the white screen is caused by a PHP error, not a caching problem. But after you’ve fixed the root cause, running `wp cache flush –allow-root` ensures visitors aren’t still being served a cached blank page. It’s a useful cleanup step, not a primary fix.

**How do I know which plugin caused the white screen?**

Enable `WP_DEBUG` and `WP_DEBUG_LOG` in wp-config.php, then reload your site and read `/wp-content/debug.log`. The log entry will include the full file path of the plugin that triggered the fatal error. No guessing — the log tells you exactly where to look.

**Can a theme cause the WordPress white screen of death?**

Yes. The WSOD after activating a new theme or running a theme update is a classic scenario. The fix is the same — enable debug mode, read the log, and if the error points to a theme file, switch to a default theme via WP-CLI: `wp theme activate twentytwentyfour –allow-root`.

## Final Thoughts

The white screen of death sounds catastrophic but it almost always has one specific, readable cause. Enable debug mode, read the log, fix what the log tells you. That three-step process has resolved every WSOD I’ve hit on my Coolify-hosted sites.

If you’re setting up WordPress on a VPS and want to avoid this class of errors from the start, the next post worth reading is [LINK: how to set up WordPress on Coolify with proper debug logging]. It covers the configuration I use so that errors surface as log entries instead of blank screens.

*Steps verified on WordPress 6.x / PHP 8.2 as of June 2025. The WP_DEBUG constants and WP-CLI commands haven’t changed in several major versions — they should work on any current WordPress install.*

—

*Some links in this post are affiliate links. I only recommend tools I actually use on my own sites.*