How to Find and Fix a WordPress Plugin Conflict

A WordPress plugin conflict is two pieces of code that each work alone and fail together. That is what makes it slow to get fixed. Each author tests on a clean site, sees nothing wrong and says so, and the site owner is the only person holding the combination that breaks.

Your job is to produce evidence: which two components, which action, which error message. With that in hand the fix is usually small. What follows is a way to collect that evidence without taking a live site apart in front of customers.

Signs of a WordPress plugin conflict, as opposed to a plain bug

Four patterns suggest that two components are clashing:

• The fault began right after you installed or updated something else.
• The feature works on the plugin's demo or on a fresh install, and not on your site.
• Switching off a plugin that seems unrelated makes the fault go away.
• It shows only in one situation: logged out, on one page builder layout, at checkout.

If the fault also appears on a clean copy with only that one plugin active, it is a bug in that plugin, and you can skip straight to reporting it. If Tools > Site Health shows an old PHP version or a low memory limit, deal with that first, because both imitate conflicts.

Test on a copy, or only for yourself

Deactivating plugins on a live site interrupts whatever they do: checkout, enrollment, forms, caching. There are three ways to avoid that, in order of preference.

A staging copy. Most hosts create one with a button. Everything below can be done there with no risk to visitors, which is one of the reasons a staging site is worth having.

Troubleshooting mode. The Health Check & Troubleshooting plugin can disable all plugins and switch to a default theme for your logged-in session only, while visitors keep seeing the normal site. You then enable plugins one by one from the admin bar. Two cautions: check the "Tested up to" line on its page against your WordPress version before installing it on a live site, and remember that it cannot reproduce faults in requests that are not yours, such as scheduled tasks, payment callbacks and anything a logged-out visitor does.

The live site, carefully. If neither is available, take a full backup of files and database, pick the quietest hour and keep the test short. Deactivation does not delete a plugin's settings, but it can clear caches, remove scheduled tasks or rewrite .htaccess, and the backup is your way back.

Halve the plugin list until one is left

Switching plugins off one at a time works, slowly. Halving is faster: thirty-two plugins take five rounds.

1. Write down the exact steps that trigger the fault. If you cannot trigger it on demand, you cannot test anything.
2. Save the list of active plugins so you can restore it.
3. Deactivate everything. If the fault is still there, no plugin is involved: test the theme by activating a default one, then look at must-use plugins and the server.
4. Activate the plugin where the symptom shows and confirm it works alone.
5. Activate half of the others. If the fault returns, the second party is in that half. If not, it is in the other half.
6. Repeat with the guilty half until one plugin remains. Keep add-ons together with the plugin they extend.
7. Confirm the pair: both active means broken, either one off means working.

With WP-CLI on the staging copy, the commands are short:

wp plugin list --status=active --field=name > active-plugins.txt
wp plugin deactivate --all
wp plugin activate my-form-plugin
wp plugin activate plugin-a plugin-b plugin-c
wp plugin activate $(cat active-plugins.txt)

The last line puts everything back when you are done. The wp plugin command reference lists the rest.

Read the browser console and the PHP log

Knowing which two plugins clash is half the evidence. The error message is the other half, and it comes from one of two places.

JavaScript errors in the browser

Open the developer tools, select the Console tab, reload the page and repeat the action. Red entries matter. "jQuery is not defined" or "$ is not a function" means a script ran before the library it depends on, which is typical after an optimization plugin defers or combines scripts. A message that some method "is not a function" often means two plugins each loaded their own copy of the same library and one overwrote the other. The file path at the right of each entry contains the plugin's folder name. On the Network tab, look for requests to admin-ajax.php or /wp-json/ that return 400, 403 or 500.

If every script arrives in one combined file, switch off the combine, minify and delay options of the optimization plugin for the duration of the test. On sites we take over, a script-delay setting that breaks another plugin's JavaScript is the most common "conflict" of all, and the fix is an exclusion rule in that plugin's settings.

PHP errors on the server

Set WP_DEBUG and WP_DEBUG_LOG to true and WP_DEBUG_DISPLAY to false in wp-config.php, repeat the action and read wp-content/debug.log. "Cannot redeclare" means two plugins define a function or class with the same name. Warnings that begin when the second plugin is activated are evidence too, even when nothing crashes.

Why plugins collide over hooks, priorities and names

Plugins change WordPress by attaching callbacks to hooks. Callbacks on one hook run in order of priority. The default is 10, lower numbers run earlier, and callbacks with equal priority run in the order they were added. When two plugins filter the same value, the one that runs last wins. That is how a checkout field added by one plugin is wiped out by another.

The repair is often a single line that makes one callback run later:

// Apply our change after the other plugin, which uses the default priority of 10.
add_filter( 'woocommerce_checkout_fields', 'mysite_adjust_checkout_fields', 20 );

Removing another plugin's callback is possible too. The priority has to match the one it was added with, and your code has to run after the callback was attached:

add_action( 'init', function () {
    remove_action( 'wp_head', 'other_plugin_print_meta', 10 );
}, 20 );

The plugin handbook explains how actions and priorities work. Hooks are not the only shared ground. Plugins also collide over:

• Names: the same shortcode tag, the same custom post type or URL slug, an unprefixed function name.
• Libraries: two versions of one JavaScript library registered under different handles.
• Jobs: two SEO plugins, two caching plugins or two SMTP plugins each doing the whole task. One plugin per job is the rule.
• Gatekeeping: a security or firewall plugin that blocks another plugin's AJAX or REST requests.

Report it so the authors can fix it

We build and maintain our own plugins, so we know what a report has to contain before a developer can act on it:

• The names and exact versions of both plugins, plus WordPress, PHP and the theme. Tools > Site Health > Info has a button that copies all of this.
• Numbered steps to reproduce the fault from a clean state.
• The console error or the log lines, as text and not as a screenshot.
• What you have ruled out, for example "it happens with only these two plugins active and a default theme".

Post it on the support forum of each plugin's WordPress.org page, or in the vendor's ticket system for paid plugins, and give each author the link to the other thread. Never put admin logins in a public forum.

Choosing between a setting, a replacement and a custom fix

Try the cheap answers first: a setting or an exclusion, an update, a short rollback of one plugin while its author works on the problem, or a replacement for one of the two. A custom fix comes next. It belongs in a small compatibility plugin of its own. Never edit either plugin's files, because the next update erases the edit.

Sometimes the conflict is a symptom. Two large plugins have each been stretched past their purpose to cover one business process, and they keep stepping on each other. Replacing both with one plugin written for that process is then the cheaper path over a few years. We cover those cases in signs you need a custom plugin, and it is the kind of work our WordPress plugin development team does. If the conflict sits in checkout or enrollment and you need it handled now, our maintenance service covers diagnosis and the temporary fix.

Frequently asked questions

How many plugins is too many?

There is no number. Conflicts come from overlap and code quality, not from the count. Forty focused, well-maintained plugins can be calmer than ten that each try to do everything. Every plugin does add update work, though, so remove the ones you no longer use.

Can two plugins conflict when both are up to date?

Yes. Authors test against WordPress core and a few popular plugins, not against every combination. A new release of one plugin can break its coexistence with another that has not changed at all.

Is the theme ever one side of the conflict?

Often. Themes bundle sliders, builders and template overrides that behave like plugins. A theme that carries outdated copies of WooCommerce templates is a frequent case, and the WooCommerce status report lists them.

Why does the problem show only for logged-out visitors?

Guests get cached and optimized pages, and logged-in users usually do not. Test in a private window, purge the cache, then switch the script and style optimization features off one at a time until the fault disappears.