Isolating a WordPress plugin that breaks the site

Symptoms

A WordPress site breaks on a page, on login, or after an update, and the timing lines up with a plugin: a new one was installed, one was updated, or an unrelated update exposed an incompatibility. The failure can be a white screen, a 500, a fatal error in the log, or a conflict where two plugins fight over the same hook. The goal of this article is to prove which plugin is responsible before considering the theme, so a one-line change restores service.

Why plugin isolation is the first step

More WordPress breakage comes from plugins than from themes or core. Plugins run on every request (hooks on init, content filters, admin screens), so a single incompatible plugin is felt everywhere. Core rarely fails by itself. When you answer "which piece changed last", a plugin is more likely than the theme, which is why the order to work through is plugins first, theme second, cache third.

The isolation plan

1. Disable every plugin at once. This is the single move that restores the site fastest. You can do it without touching the dashboard, which matters when the admin is already down:

- If WP-CLI is available: wp plugin deactivate --all

- If not, rename the whole folder (Linux/Unix):

mv wp-content/plugins plugins_off

In both cases the site comes back with the theme and no extra code. Confirm it loads, meaning the plugin world caused the outage, not the theme or core.

1. Restore the folder and reactivate in halves. Rename the folder back and re-enable plugins in groups (first half, then half of the broken half, and so on), with a page load between groups:

wp plugin activate plugin-a plugin-b plugin-c

After each half, load the site or the page that failed. When the page breaks, the offender is in the last half you added. Divide that group in two and repeat. Logging every test in a table keeps it repeatable:

The offender ends the run named with one test left.

1. Bring the offender back with the dashboard route. On a working admin use Plugins, and deactivate names one at a time, then reactivate. The earlier filesystem method is identical, just faster and available without a working admin.
2. Name the real fix, not just the exit. The plugin did not throw because it is evil; it either conflicts with a co-installed plugin or with the theme's use of the same hook. Two possibilities:

- True conflict: two plugins register the same name or hook carelessly. Check plugins with overlapping features, such as caching, security, SEO, and image optimisation stacked together.

- Theme conflict: the theme's functions.php and the plugin both define a shared function, or both enqueue a conflicting script.

1. Read the fatal error that names it. Enable the debug log exactly once on a copy:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Read wp-content/debug.log; the line names the plugin file, for example Fatal error: Call to undefined function my_fancy_plugin_init. That is the answer. Remove the debug lines and delete the log after diagnosing.

1. Confirm the final integration. Keep the offender disabled for a week, then reintroduce the exact two components (plugin and co-dependent plugin, or plugin and theme) in a controlled test. If it errors again, the pair simply does not work; keep the old version, wait for the developer to ship a fix, or cleanly remove the plugin from the backup with the log proof.

Prevention

• Install one plugin per job. Stacking two caching plugins, or two security suites, is the number one cause of the 'suddenly broken after nothing changed' class.
• Activate a dangerous or complex plugin on staging, not on the live site.
• Keep the debug log on quietly in production (WP_DEBUG_DISPLAY false) so the next mystery has a file trail, as described in the troubleshooting order.