WordPress plugin conflict: how to find the cause

You updated something. Or you installed something. Or you didn’t do anything at all, and your site started behaving differently. A page that worked yesterday doesn’t work today. A form stopped submitting. The checkout throws an error it didn’t throw before. The admin area does something unexpected.

You have 30 plugins, or 40, and no obvious way to know which one is responsible.

The standard advice is to deactivate all your plugins and reactivate them one by one until the problem comes back. That works, and it’s the right method when you’re truly stuck, but it’s a last resort: it takes time, it disrupts a live site, and it skips a faster first pass that eliminates suspects before you start touching anything. This post covers the full sequence, starting with what to check before you deactivate a single plugin.

Before you touch anything: anchor the timeline

The single most useful question you can answer before starting any plugin conflict investigation is: when did this start, and what changed right before it? A plugin conflict that appeared after an update session has a very short suspect list. A conflict that appeared without any obvious trigger is harder, but still answerable.

In your WordPress dashboard, go to Dashboard, then Updates. This doesn’t give you a full history, but your hosting control panel or a plugin like WP Activity Log will show you a timestamped log of plugin installs, updates, and deactivations. If the problem started at 2pm yesterday and you updated three plugins at 1:45pm, those three plugins are your suspects. You’ve already eliminated the other 37.

If you can’t anchor the timeline precisely, check your PHP error log. A conflict that’s actively breaking something usually produces a PHP error, and that error has a timestamp. Match the timestamp to any activity you can recall, and the suspect list gets shorter. Setting up your WordPress debug log before the next time this happens is one of the best investments you can make in your diagnostic infrastructure.

Read what the error log is already telling you

Before the deactivation marathon, open your debug log. If it’s running, it may already have the answer. A PHP fatal error or warning from a specific file path tells you exactly which plugin produced it. Look for entries that appeared around the time the problem started.

The file path in any PHP error entry is what matters. /wp-content/plugins/[plugin-name]/ names the plugin directly. If you see a plugin named in the log at a timestamp that matches when the problem appeared, that’s your primary suspect. Test by deactivating that one plugin and checking whether the problem resolves. If it does, you found it in one step instead of thirty.

If the log is empty, or if there’s nothing in it that maps to the problem you’re seeing, keep going.

Check whether this is a theme conflict first

Temporarily switch to a default WordPress theme (Twenty Twenty-Four or Twenty Twenty-Five). If the problem disappears, it’s the theme or a theme-plugin interaction, not a plugin-plugin conflict. This takes thirty seconds and eliminates an entire category of cause before you start working through plugins.

If the problem persists with a default theme active, the theme is clear. Back to plugins.

The deactivation sequence: work in halves, not one at a time

The one-by-one reactivation method works but it’s slow. A faster approach when you have a long plugin list is binary elimination: deactivate half your plugins, test. If the problem is gone, the culprit is in the half you deactivated. If it persists, the culprit is in the half still active. Reactivate the deactivated half, deactivate the other half, test again. Each round cuts the suspect list in half. With 40 plugins, you can get to the culprit in about five rounds instead of forty.

The complication is that some plugins have interdependencies: deactivating one may break something else unrelated to your original problem, which muddies the test. If you hit this, fall back to the one-at-a-time method for the suspects you’ve already narrowed down.

When you find the plugin that triggers the problem on reactivation, don’t stop there. Check whether that plugin has an update available, whether its support forum mentions your specific symptom, and whether the conflict appeared after a WordPress core update. A plugin that worked for a year can start conflicting after WordPress changes how it loads scripts or processes hooks.

When the conflict is a plugin-plugin interaction, not a single bad plugin

Some conflicts only appear when two specific plugins are active at the same time. Neither one causes a problem alone. Together they do. This is harder to find because deactivating either one in isolation makes the problem disappear, which can lead you to wrongly blame whichever one you happened to deactivate first.

The signal for this pattern: you deactivated the “culprit” and reactivated it again to verify, and the problem didn’t come back. Or it comes back intermittently. When that happens, the conflict is between two plugins, and you need to identify the pair. The binary method still works here, but you’re looking for the combination rather than a single plugin.

The PHP error log is especially useful for this pattern. A conflict between two plugins often surfaces as one plugin calling a function the other plugin also registered, or as a JavaScript conflict in the browser console where two plugins are loading different versions of the same library. Check both the PHP log and your browser’s console for errors that name more than one plugin.

If you can’t access the admin dashboard

A fatal error during the plugin activation process can lock you out of the dashboard entirely. If that happens, you need to deactivate plugins at the file level. Connect to your server via FTP or your hosting file manager. Navigate to wp-content/plugins/. Rename the folder of the plugin you suspect to something like plugin-name-OFF. WordPress will automatically deactivate it because it can’t find the folder. Try loading the dashboard again.

If you don’t know which plugin to target, rename the entire plugins folder to plugins-OFF. WordPress deactivates everything. Your dashboard becomes accessible. Rename the folder back to plugins, then reactivate plugins one by one from inside the dashboard.

After you find it: what to do besides delete it

Before you delete the conflicting plugin, check whether an update is available. Plugin conflicts often get resolved in a subsequent release once the developer hears about the incompatibility. Check the plugin’s support forum on WordPress.org for your specific issue. If other users hit the same conflict, there may already be a workaround or a scheduled fix.

If the plugin is essential and there’s no update, the plugin’s developer needs the specific conflict details: which WordPress version, which other plugin, what the exact error message is, what the debug log shows. The more of that you can provide, the faster they can reproduce and fix it. That’s also exactly the information Loupely captures automatically: active plugin list, PHP error output, hook execution order. When you do need to hand this to someone, the file already contains what they need.

The investigation above takes longer to describe than to run. Most plugin conflicts resolve in under an hour when you work from the error log first and use the timeline to narrow suspects before touching a single plugin setting. The deactivation marathon is the fallback, not the first move.

For the broader pattern of what to do when your site breaks after an update, the same diagnostic thinking applies: the problem is almost never where the visible symptom appears, and the log is the fastest path to where it actually is.