Fix a WordPress plugin conflict

Symptoms

A plugin conflict is a bug that is invisible with either plugin disabled and appears the moment two specific ones run together. Typical results: a white screen or 500, a fatal PHP error naming a function that exists in two plugins, duplicate add_action output (two identical menus), a script or style loaded twice, or a feature that works on staging but fails only when the second plugin activates. Conflicts cluster around plugins that register the same function, enqueue the same asset (two cache plugins, two SEO plugins, two security suites), or both claim the same hook.

The code smell that makes a conflict differ from a plugin that is merely broken: with a broken plugin, disabling it fixes the site and re-enabling it immediately breaks it again at the same spot. With a conflict, removing one side fixes it and the other plugin keeps working alone. The plugin causes error article covers the broken-plugin branch; this one assumes you have a pair.

Find the pair

The fast, deterministic way is the same isolation ladder but aimed at pairs, not singles:

1. Deactivate all plugins and confirm the site loads.
2. Reactivate a small base (theme-compatible set) and test the broken screen.
3. Activate plugins in two halves and binary search by group load. The conflict is on a specific pair when you add one new plugin and the site leaves the healthy group.
4. The plugin that made it break is the second half of the pair, so the two that were both active when the screen broke are the two halves you need to investigate.

The debug log is your friend: enable WP_DEBUG_LOG and watch for a Fatal error: Cannot declare ... already in use or a duplicate function name. That names the file, and knowing the file is the plugin, so the pair is usually obvious from the file path.

The safe confirmation on a copy

Before you touch the live site with a second, ideally conflicting plugin, test the exact pair on a staging copy:

Use the staging to live flow; the important part is that you confirm the pair on the copy, so the live site is never the first place the conflict is proven. When the pair is proven staging-broken, there is no live site left to fix, only the decision of which plugin wins.

Which side to keep

The pair logic for the fix:

• Same function: keep the plugin that defines it correctly and newer; delete or deactivate the other.
• Same enqueued asset: keep the one with the correct version, dequeue the second in a small functions.php snippet instead of deleting a plugin you rely on.
• Same hook with wrong priority: raise or lower the add_action priority of one plugin, which is legitimate when only the order misbehaves, not the function itself.

When neither can be removed (a payment gateway and an analytics plugin both need the scripts), the workaround is isolating them in time (the gateway fires on the checkout page only) or a code-level wp_dequeue_script conflict resolution that the maintainer can review.

Prevention

• Install one plugin per job: two caching plugins, two security suites, or two SEO plugins is the classic conflict seed.
• Keep plugins in a healthy version pinning cadence, updating individually in staging first, as the update rollback guide describes.
• When adding a plugin, activate it for a week on staging with the rest of the stack before it ever touches a live checkout.

The conflict is a bug in the interaction, not in either plugin by itself. The skill is naming the pair, proving it on a staging copy, and then choosing which side owns the behavior, which is the heart of WordPress plugin isolation.