Troubleshooting

How to find which plugin broke your site without taking it offline

Deactivating everything works, and it is also why people put off diagnosing a WordPress plugin conflict until the weekend. There are better ways to do it.

Illustration: finding which WordPress plugin broke the site

Read the error before you touch anything

A white screen is not information. The error behind it is. With error logging on, the site will usually name the file and the line responsible, which often identifies the plugin immediately and saves the entire isolation process.

Set WP_DEBUG and WP_DEBUG_LOG to true in wp-config.php and the detail goes to a log file rather than to your visitors. The WordPress debugging documentation covers the constants worth setting.

Your host’s PHP error log is worth reading too. It frequently holds the fatal error with a full stack trace already waiting for you.

Isolate a WordPress plugin conflict without going offline

The Health Check and Troubleshooting plugin lets you disable plugins and switch themes for your own logged-in session only. Every visitor carries on seeing the working site while you test.

This is the single most useful trick for a live site, and it removes the main reason conflict isolation gets postponed until nobody is watching.

Then bisect rather than going one at a time

With twenty plugins installed, disabling them one at a time can take twenty tests. Splitting the list in half takes about five.

Disable half of them. If the problem disappears, it lives in that half. Split that half again. Each round halves the remaining candidates, so bisection is the fastest way to find a WordPress plugin conflict even on a large site.

Reproduce it on staging before you fix it

Once you know the culprit, reproduce it somewhere that does not matter. A staging copy lets you confirm the diagnosis and test the fix without an audience watching.

It also tells you whether the conflict is genuinely between two plugins, or between a plugin and your PHP version, your theme, or something specific to this one site.

Write down what you found

The same conflicts recur, on the same site and across different ones. A short note about what broke, what caused it and what resolved it turns an afternoon of diagnosis into a five minute fix next time.

In support work I document recurring issues so colleagues can resolve them without repeating the diagnosis. It is worth doing even when the only colleague is you in six months.

Questions people ask about this

Yes. Health Check’s troubleshooting mode disables plugins for your logged-in session only, so the live site keeps working normally for everybody else while you test.

Enable WP_DEBUG and WP_DEBUG_LOG in wp-config.php and read the debug log, or read your host’s PHP error log. A fatal error normally names the exact file and line responsible.

Then it is probably not a plugin. Switch to a default theme to rule the theme out, then check PHP version, memory limits and any recent server side changes.

Site broken and no idea why?

Send it over. I diagnose from server logs, SSH and WP-CLI rather than guesswork.