Finding and Fixing Plugin Conflicts
Every active plugin runs in the same PHP process, the same hook system and the same page of JavaScript. Conflicts are collisions in that shared space, and the collision type tells you which fix will hold.
Quick fix: open the browser console before you deactivate anything. A red JavaScript error naming a file inside wp-content/plugins/ identifies the conflict in seconds, and roughly half of "this button stopped working" reports are exactly that. Only if the console is clean do you start deactivating.
The trap is hunting for the broken plugin. A conflict almost always needs two participants that are each fine on their own, so switching one off proves nothing until you know which pair fights.
Why plugins collide at all
WordPress loads every active plugin into one PHP process on every request. They share one global function namespace, one hook system, one script queue and one database. There is no sandbox. That design is why plugins can do so much, and it is also the entire cause of conflicts.
Four collisions cover nearly everything you will meet:
- Name collisions. Two plugins declare a function or class with the same name and PHP fatals immediately. Usually a bundled third-party library included without a prefix.
- Hook order. Two plugins filter the same value; whichever runs last wins, and a priority change in an update silently reverses the outcome.
- Asset collisions. Two plugins enqueue different versions of the same script, or one throws an error early and the rest of the page's JavaScript never runs.
- Template and output overrides. Two plugins both replace the same template or both inject markup into the same hook, producing duplicates or blank regions.
Get the evidence before deactivating anything
Deactivation is the slow, disruptive step. Do these first:
- Browser console. Note the first error, not the loudest one. Later errors are usually consequences.
- Network tab. A failed admin-ajax or REST request with a 500 response means the error is in PHP, not JavaScript.
- Debug log. Enable logging as described in the WordPress debug mode guide and reproduce the fault once. A fatal error names two files — the one that declared the symbol first, and the one that tried to declare it again. That line is the whole answer.
- Timing. What changed immediately before? Update, new plugin, PHP version change. The change log is faster than bisection.
If the site is blank rather than merely misbehaving, work through the white screen procedure instead; a fatal has already stopped execution.
Isolate by halving, not one at a time
When the log names nothing, bisect. With twenty plugins, one-at-a-time testing takes up to twenty reloads; halving takes five.
- Deactivate half the plugins. Test.
- If the fault is gone, the culprit is in the half you switched off. If it remains, it is in the half still running.
- Halve the suspect group again and repeat until one plugin is left.
- Reactivate everything, then switch that one plugin off alone to confirm.
- Switch it back on and disable its likely partner to find the second half of the pair.
Do this in a per-user troubleshooting mode where you can, so visitors keep the working site. Where that is not available, use a staging copy. If you have lost admin access entirely, disabling plugins without admin access does the same job over SFTP, and wp-admin failing outright is a different diagnosis worth ruling out first.
One caution: deactivation preserves settings, but deletion does not. Never delete a plugin during diagnosis.
Match the fix to the collision
| Symptom | Likely collision | Fix that holds |
|---|---|---|
| Fatal naming two files | Duplicate class or function | Report to both vendors; keep only one until patched |
| Output correct until a plugin activates | Filter priority | Re-hook your change at a later priority |
| One script dead, rest of page fine | JS error earlier in the queue | Fix or dequeue the failing script |
| Duplicate blocks of markup | Two template overrides | Disable one plugin's override, not both |
| Setting reverts on save | Two plugins writing one option | Choose one owner for that setting |
The durable fixes are unhooking, re-prioritising and dequeuing from a child theme or small site plugin — not editing a vendor's files. Any change you make inside wp-content/plugins/ is gone at the next update, and you will be debugging the same fault in three weeks with no memory of the patch.
Stop the next one before it happens
Conflicts cluster around plugins that do overlapping jobs. Two caching plugins, two SEO plugins, two security plugins or two plugins each generating their own critical CSS will fight indefinitely, and no amount of configuration resolves it — pick one per job.
Beyond that, the practical defence is process: update on staging, update in small batches so a fault has an obvious owner, and take a restorable backup first. Updating WordPress plugins safely sets out that routine, and it turns most conflicts from an outage into a five-minute rollback.
Frequently asked
- Use a troubleshooting mode that disables plugins for your session only, so visitors keep seeing the working site while you test. If no such tool is available, do the isolation on a staging copy rather than production.
- Rarely. Most conflicts need two plugins that each behave reasonably alone — two copies of the same library, two filters fighting over the same output, two template overrides. The fix is usually to change how they interact rather than to blame one.
- An update can change a hook priority, bump a bundled library version or start loading a script on pages it previously skipped. Compare the changelog around the version you moved to, and test updates on staging before production.