Plugin Conflict Checker

The instinct when a plugin conflict is suspected is to deactivate plugins one by one from the top of the list. On a site with forty plugins that is up to forty deactivations, forty page loads and forty reactivations, and it is easy to lose track of which state you are in halfway through. Splitting the list in half instead finds the culprit in about six steps on the same site: disable half, test, and whichever half still shows the fault contains the problem. Halve that group and repeat until one plugin is left.

This matters because conflicts are rarely about a plugin being badly written. More often two plugins load different versions of the same library, or both hook the same filter and the second one overwrites the first, or one enqueues a JavaScript file that breaks the block editor for everything after it. Those symptoms move around depending on which plugins load together, which is exactly why halving the set is more reliable than reasoning about which plugin looks suspicious.

The Health Check and Troubleshooting plugin from the WordPress team gives you a troubleshooting mode that disables plugins for your logged-in session only. Visitors keep seeing the working site while you test. This is the safest way to isolate a conflict on a site that is still serving traffic, and it should be your default when the fault is in wp-admin or the editor rather than a full outage.

If the site is already down and you cannot log in, do the same work over FTP. Inside wp-content/plugins each plugin has its own folder; rename an individual folder and that plugin alone is deactivated. To disable a group quickly, create a folder called plugins-off inside wp-content and move the folders you want disabled into it, then move them back in batches. Never delete plugin folders during a conflict hunt, because deleting removes the plugin's settings on some plugins and you lose configuration you may not be able to rebuild.

Front-end and editor conflicts are often JavaScript rather than PHP, and PHP logs stay completely silent. Open the browser console on the broken screen and read the first error, not the last one. A single uncaught error stops every script queued after it, which is why one small plugin can break the block editor, a slider and a contact form all at once, and why the visible symptom rarely points at the real cause.

The file path in the console error names the plugin directly. If the error comes from a bundled library such as jQuery, look for a plugin loading its own copy of that library; two copies on one page is a classic cause. Once identified, the fix is usually to update the plugin, change its script loading option if it offers one, or replace it. Report the conflict to the plugin author with the console error text, because these are typically fixed quickly when someone actually reports them.