WordPress Plugin Conflict: How to Find What's Breaking

Something on your WordPress site broke right after an update — a page looks wrong, a form stopped submitting, the admin bar shows a JS error in the console, or the dashboard just feels sluggish. Nothing as dramatic as a white screen or a "critical error" message, so the usual fixes don't apply. Nine times out of ten, this is a plugin or theme conflict, and there's a reliable way to find the culprit without guessing.

Symptom

Conflicts show up in more shapes than outright fatal errors. Common patterns:

• A page layout breaks or a section disappears after installing/updating a plugin
• Buttons, sliders, or forms stop responding — usually a JavaScript conflict, visible as red errors in the browser console (F12 → Console)
• The WordPress dashboard becomes slow to load, especially on pages like Posts or Plugins
• Styling looks broken only on certain pages, or only for certain user roles
• A feature works on staging but not production, or vice versa

If your site is fully down with a fatal PHP error or a blank white screen, that's a different, more urgent fix — see our posts on the critical error message and the white screen of death. This guide is for the subtler stuff: things that are broken but not fatal, where the error log doesn't tell you much.

Cause

WordPress loads every active plugin's PHP on every request, and most themes and plugins also enqueue their own JavaScript and CSS. Conflicts happen when two of these pieces step on each other:

• Function or class name collisions — two plugins define the same function name, or one plugin extends a class the other modifies
• JavaScript library version clashes — one plugin loads jQuery UI 1.12, another expects 1.13, and something silently fails
• CSS specificity fights — a theme's stylesheet overrides a plugin's, or the other way round, breaking layout
• Hook priority collisions — two plugins hook into the same action/filter and one's output overwrites the other's
• Caching plugins serving a stale combined/minified JS or CSS file after an update, which looks exactly like a conflict but isn't one

The error log usually stays quiet for this class of bug because nothing is throwing a PHP fatal error — it's a logic or front-end clash, not a crash.

Fix

1. Rule out caching first

Before touching any plugin, clear every layer of cache: your caching plugin (WP Rocket, LiteSpeed Cache, W3 Total Cache, etc.), any server-side cache in cPanel, and Cloudflare if you're using it. Also hard-refresh the browser (Ctrl/Cmd + Shift + R). A surprising number of "conflicts" are just an old minified JS file still being served.

2. Use the built-in Health Check plugin (works even on a live site)

Install the free Health Check & Troubleshooting plugin from WordPress.org. Its Troubleshooting tab puts your site into a mode that disables all other plugins and switches to a default theme — but only for you, while logged in. Visitors still see the site normally, so you can debug on production without an outage.

1. Activate Health Check, go to Tools → Site Health → Troubleshooting
2. Click Enable Troubleshooting Mode
3. Re-enable plugins one at a time from the troubleshooting bar at the top of the screen, checking the broken behavior after each one
4. When the problem reappears, the plugin you just re-enabled is the conflict

3. No live-site tool available? Do it manually on staging

If you can't install a plugin (e.g. the dashboard itself is affected), do this on a staging copy instead of production:

• Deactivate all plugins from Plugins → Bulk Actions, or rename the wp-content/plugins folder via File Manager/SFTP if you can't reach wp-admin at all
• Confirm the issue is gone with everything off
• Reactivate plugins one at a time, testing the specific broken behavior after each
• Once you land on the culprit, reactivate everything else you'd already cleared and leave only that one off, to confirm it's isolated

Do the same with the theme if disabling all plugins didn't fix it: switch to a default theme like Twenty Twenty-Four temporarily. If the problem vanishes, it's theme code or a theme/plugin interaction, not the plugin alone.

4. For JavaScript errors, use the browser console and Query Monitor

Open DevTools (F12) → Console tab and reload the broken page. A red error naming a specific script file or function narrows things down fast — the filename usually includes the plugin's slug (e.g. /wp-content/plugins/some-plugin/js/script.js:42).

For a more precise view, install Query Monitor. It shows, per page load: every hook fired and by which plugin, every enqueued script and style with its source, database query counts per plugin, and PHP warnings/notices that never made it into the error log. It's the single most useful diagnostic plugin for this kind of issue.

5. Once you've found it: fix, don't just disable

Command-line shortcut with WP-CLI

If you have SSH access, WP-CLI makes bisecting plugins faster than clicking through the dashboard:

wp plugin deactivate --all
wp plugin activate plugin-one
wp plugin activate plugin-two
# repeat, testing after each, until the issue returns

Prevention

• Keep the plugin count lean — every extra plugin is another point of failure and another maintainer's release schedule you're depending on
• Test major plugin and theme updates on staging before applying them to production, especially for anything touching checkout, forms, or page builders
• Leave Query Monitor installed (but only active for admins) so you have visibility ready when something does break
• Read plugin changelogs before updating anything that's had trouble before — "Fixed conflict with X" entries are a hint the plugin has a history
• Avoid installing two plugins that solve the same problem; redundancy causes more conflicts than it prevents