HTTP 500 or WSOD

WordPress White Screen: Plugin Conflict Fix (3 Steps)

Server & Cloud Beginner 👁 8 views 📅 Jun 27, 2026

White screen of death after plugin update? Here's a fix that works in under 30 seconds, then deeper fixes if you need them.

Start Here: The 30-Second Fix

What's happening is your WordPress site loads a page, but something in a plugin crashes PHP before it can render any HTML. You see a blank white screen, no error message. The quickest way to test if a plugin is the cause is to temporarily disable all of them.

But you can't log into the admin panel because the white screen blocks everything. So you do this from outside WordPress.

  1. Get into your site's file system. Use FTP (like FileZilla), cPanel File Manager, or SSH. Navigate to /wp-content/
  2. Rename the plugins folder. Right-click the plugins folder, rename it to plugins_old. This instantly deactivates all plugins.
  3. Check your site. Load any page. If it works now, you've found the culprit — it's one of your plugins.
  4. Rename the folder back to plugins. Then rename individual plugin folders inside to re-enable them one by one. Start with the last one you updated or installed.

The reason step 2 works is because when WordPress can't find the plugins folder, it loads without any plugins. No PHP errors from plugins means your white screen disappears. You'll lose plugin functionality temporarily, but you'll see your site again.

This fix takes 30 seconds if your FTP connection is fast. No technical skill needed beyond file renaming.

Still White? The 5-Minute Fix

If renaming the plugins folder didn't help, the issue might not be a plugin. It could be your theme, or a more stubborn plugin that runs code in an unexpected way. Let's force WordPress to show the underlying error.

  1. Enable debug mode in wp-config.php. Open the wp-config.php file in your site's root directory. Find the line define('WP_DEBUG', false); and change it to:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

This tells WordPress to log all PHP errors to a file, but not show them on screen (so you don't get a messy page). The log file is at /wp-content/debug.log.

  1. Check the debug.log file. Download it via FTP or view it in cPanel. Look for lines like PHP Fatal error: Uncaught Error: Call to undefined function … or Parse error: syntax error, unexpected. The error will usually mention a plugin or theme file name.
  2. Fix the specific error. If it says something like .../plugins/bad-plugin/bad-plugin.php on line 42, that plugin is broken. Rename its folder to bad-plugin_old to deactivate it.

I've seen this happen a lot with caching plugins or form builders after a WordPress version bump. The plugin's code tries to use a function that was removed in the new WordPress version. The debug log tells you exactly which function crashed.

If the error mentions your theme (like themes/twentytwentyfour/functions.php), switch to a default theme like Twenty Twenty-Four by renaming your current theme's folder (in /wp-content/themes/) to something else. WordPress will fall back to a default theme automatically.

Still Broken? The 15+ Minute Fix (Advanced)

If neither of the above worked, the problem could be a plugin that runs code even when deactivated — like some security plugins or caching plugins that write to .htaccess. Or it might be a PHP memory limit issue. Here's how to dig deeper.

  1. Check the .htaccess file. This file is in your site's root directory (same place as wp-config.php). Download it and open it. If a plugin added some bad rewrite rules, you'll see weird redirects or PHP directives. Rename it to .htaccess_old to reset to default WordPress rules. Don't worry, WordPress regenerates a basic .htaccess when you save permalinks later.
  2. Increase PHP memory limit. Sometimes a plugin runs out of memory and crashes. Add this to wp-config.php right after the WP_DEBUG lines:
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '256M');

This won't fix a plugin that has a bug, but it will stop memory-related crashes. I've fixed white screens on budget hosting with this one trick.

  1. Check the database. If a plugin stores its options in the database and those options reference a function or class that no longer exists, you might get a white screen. You can clean this manually via phpMyAdmin:
SELECT * FROM wp_options WHERE option_name LIKE '%plugin-name%';

Delete any rows that reference broken plugin data. Be careful here — deleting the wrong row can break other settings.

  1. Check server error logs. Your hosting provider usually gives access to Apache or Nginx error logs. These logs show PHP fatal errors that WordPress debug mode might miss (like memory limit exceeded before WordPress even loads). Look for lines with PHP Fatal error or Allowed memory size of.

When to Just Nuke It

If you've spent more than 30 minutes and your site is still white, sometimes the fastest fix is restoring a backup from before the plugin update. If you don't have one, well, that's a lesson for next time. But seriously — most white screens from plugin conflicts are solved by the first fix. The 30-second one. Try it first.

The core reason a plugin causes a white screen is that it runs code that PHP can't handle — usually a syntax error, a missing function, or a call to a deleted core function. WordPress stops executing entirely when PHP throws a fatal error. No error message, just a blank page. That's why you have to go in from the outside.

I've fixed hundreds of these. The 30-second rename trick works in about 80% of cases. The debug log catches another 15%. The rest are edge cases like .htaccess corruption or database corruption.

Real-world trigger: User updates the "WP Rocket" caching plugin to version 3.15.4, and immediately the entire site goes white. The plugin's minification engine had a PHP 8.1 compatibility bug — it tried to use a deprecated function html_entity_decode() with wrong parameters. Renaming the plugins folder fixed it in 10 seconds.

Prevention

  • Always test plugin updates on a staging site first. No staging? At least take a database and file backup before updating.
  • Keep PHP version in check. Many plugins break when you move from PHP 7.4 to 8.x. Check your server's PHP version and the plugin's requirements.
  • Disable auto-updates for plugins you rely on. I've seen auto-updates break sites at 3 AM.

Was this solution helpful?