The Plugin That Broke the Site: Finding It Without Damage

#What "a plugin conflict" means

WordPress runs your theme and every active plugin together on every page load. Each is written by a different team. Most of the time they coexist. When one is updated and changes something another one relied on, or two of them try to do the same job, the result ranges from a layout glitch to a white screen with "There has been a critical error on this website".

The cause is nearly always the most recent change: a plugin update, a new plugin, a theme update, or a PHP version change on the host. Finding which plugin is a process of elimination, and the goal is to do it without turning a broken checkout into a broken site.

#First: stop making it worse

• Do not update anything else to "see if that helps".
• Do not delete plugins. Deactivating is reversible; deleting can lose settings.
• Take a backup now, or confirm the host's most recent backup exists and note its time.
• If the site is down entirely and you have a backup from before the change, restoring it is a valid fix. Restore, then investigate on a staging copy at leisure.

#Read the error before guessing

The critical error email. Since WordPress 5.2, a fatal error triggers an email to the admin address with the error message and, crucially, the file path where it happened. That path contains the plugin's folder name. If you have that email, you likely have your answer already.

Recovery mode. The same email contains a link that logs you in with the offending plugin paused. Use it. You can deactivate the plugin from there and the site comes back.

The PHP error log. On the host's control panel, or in wp-content/debug.log if debugging is on. The last fatal error names the file. On a managed host, support will read it for you.

The browser console for problems that are not fatal: a layout broken, a slider not moving, a form not submitting. The console (right-click, Inspect, Console) shows JavaScript errors with the file that caused them, which again names the plugin.

Nine times out of ten, one of those four tells you the plugin without any elimination at all.

#If the error does not name it: eliminate on staging

Elimination means deactivating plugins until the problem stops. Doing it on the live site takes the site through every combination in front of visitors. Do it on a staging copy.

Most managed hosts create a staging copy in a click. If yours does not, a backup restored to a subdomain works. If neither is possible and the site is already down, elimination on live is defensible; if the site is up with a partial fault, wait for staging.

The halving method. With twenty plugins, deactivating one at a time is twenty tests. Instead:

1. Deactivate half. Is the problem gone?
2. If yes, the culprit is in the deactivated half. Reactivate half of those. Test.
3. If no, it is in the still-active half. Deactivate half of those. Test.
4. Repeat. Twenty plugins takes five rounds.

Keep a list of what is active at each step. It is easy to lose track.

Start with the suspects. Before halving, deactivate the plugins that were updated most recently (the Updates or Plugins screen shows versions; the host's log shows when). If the problem disappears, you are done in one step.

Check the theme too. Switch to a default theme for one test. If the problem vanishes, the conflict involves the theme, and the plugin is only half the story.

#When you have found it

You have a plugin whose deactivation fixes the problem. Now decide:

• Is there a newer version? Plugin authors often fix a conflict within days. Check the plugin's changelog.
• Can you roll it back? WP Rollback or the plugin's own download page gives the previous version. Reinstalling the previous version, on staging first, is usually the immediate fix.
• Is it essential? If it is a slider on the home page, you can live without it for a week while the author fixes it. If it is the booking system, you need a rollback or a replacement today.
• Is it abandoned? A plugin not updated in two years that has just broken under a newer WordPress or PHP is telling you it is time to replace it.

Apply the fix on staging, confirm, then on live. Then take a fresh backup.

#Preventing the next one

• Update on staging first, always.
• Update one thing at a time, or in small groups, so the cause is obvious.
• Remove plugins you do not use. Every inactive plugin is one you do not need to test.
• Keep a changelog: date, what was updated, from which version to which. When something breaks, the answer is on the list.
• Have a backup from before every update, and know how to restore it.

Those five habits are most of what a care plan is, and they are why sites on one rarely have this problem. If you are in the middle of it now, the error email and recovery mode link are the fastest way out, and a diagnosis is the fastest way to a fix when they do not point at anything.