How To Check Plugin Conflict In WordPress?

A plugin conflict is what you get when two pieces of code that work fine alone break each other once they share a site. The symptoms range from a broken checkout button to a white screen, and the cause is almost never obvious from the symptom. The fastest way to find it is a controlled process of elimination, and this guide walks through that process in the order we use on client sites, from the five-minute checks to the tools that let you debug a live store without taking it offline.

Confirm it is actually a conflict

Before deactivating anything, spend two minutes ruling out the things that look like conflicts but are not.

• Caching. Clear your page cache (plugin, host and CDN) and test in a private browsing window. Stale cached CSS or JS explains a surprising share of “the plugin broke my layout” reports.
• Browser extensions. Ad blockers and privacy extensions block scripts from analytics, chat widgets and some payment gateways. Test in a clean browser profile.
• Recent changes. Check Dashboard → Updates and your host’s activity log. If a plugin, theme or PHP version changed in the last 48 hours, that is your first suspect.
• PHP version. A plugin that has not been updated in two years often fails outright on PHP 8.3 or 8.4. Your host’s control panel shows the current version.

If the problem survives all of that, it is time to isolate the cause.

Read the error before you guess

WordPress hides PHP errors by default, which is sensible for visitors and useless for debugging. Turn them on temporarily so you can see what is failing. Add these lines to the wp-config file, above the line that says “That’s all, stop editing!”:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Reproduce the problem, then open wp-content/debug.log. A fatal error names the file and line, and the file path tells you which plugin it lives in. Even a “deprecated” notice can point to the culprit. Set WP_DEBUG back to false when you are done; leaving it on forever fills your disk with log entries.

For JavaScript problems (buttons that do nothing, forms that will not submit, sliders that stay frozen), open your browser’s developer tools with F12 and check the Console tab. A red error that mentions a file under /wp-content/plugins/some-plugin/ gives you the answer without any deactivation at all. The Network tab shows failed AJAX requests, and clicking one shows the server’s response, which is frequently a PHP error in disguise.

Two other built-in sources are worth checking. Since WordPress 5.2, a fatal error triggers an email to the admin address with a recovery-mode link and names the offending plugin. And Tools → Site Health → Info lists every active plugin with its version, plus your PHP and MySQL versions, which you will want when you file a support ticket.

Troubleshooting Mode: debug a live site without breaking it

The official Health Check & Troubleshooting plugin, maintained by the WordPress core team, is the tool we reach for first. Its Troubleshooting Mode deactivates all plugins and switches to a default theme for your browser session only. Visitors and customers keep seeing the normal site. That makes it safe to use on a live store in the middle of the day.

1. Install and activate Health Check & Troubleshooting from Plugins → Add New.
2. Go to Tools → Site Health → Troubleshooting and click Enable Troubleshooting Mode.
3. Visit the broken page. If it now works, a plugin or the theme is the cause. If it is still broken, the problem is in WordPress core, the server, or the content itself.
4. Use the Troubleshooting Mode bar at the top of the admin to re-enable plugins one at a time, testing after each. When the problem reappears, the plugin you just enabled is involved.
5. Switch the theme back on last. If the problem only appears with your theme plus one specific plugin, you have a two-party conflict, which is the most common kind.
6. Click Disable Troubleshooting Mode when finished. Check Plugins → Installed Plugins afterwards, because there are occasional reports of plugins staying inactive after exit.

One caveat: Troubleshooting Mode does not sandbox payment gateways or external API calls. If you test a checkout while in this mode, a real charge can go through.

Manual deactivation (when you can reach the dashboard)

If you prefer not to install anything, or you are on a staging copy where downtime does not matter, the classic method still works.

1. Take a backup, or better, do this on staging.
2. Plugins → Installed Plugins, tick all, Bulk actions → Deactivate.
3. Test. If the issue is gone, reactivate plugins one by one, testing after each.
4. If deactivating everything does not fix it, switch to a default theme under Appearance → Themes. Use Twenty Twenty-Five or whichever Twenty theme ships with your WordPress version, not your production theme’s parent. The default themes have no dependencies and no custom code.

A faster variant for sites with many plugins: binary search. Deactivate half. If the problem goes away, the culprit is in the deactivated half; if not, it is in the active half. Repeat with the suspect half. Thirty plugins take five rounds instead of thirty.

When the dashboard is locked out

A fatal error on every page means you cannot reach Plugins to deactivate anything. You have three ways in.

Recovery mode

Check the admin email inbox for the “Your site is experiencing a technical issue” message. The link logs you in with the faulty plugin paused so you can deactivate it properly. Links expire after a day, so act on it quickly.

WP-CLI

If you have SSH access, this is the cleanest option:

wp plugin list --status=active
wp plugin deactivate --all
wp plugin activate woocommerce   # reactivate one at a time

Add --skip-plugins --skip-themes if the fatal error stops WP-CLI from loading at all.

File manager or SFTP

Rename wp-content/plugins to wp-content/plugins-off. WordPress silently deactivates everything it cannot find. Rename it back and WordPress will leave the plugins deactivated so you can re-enable them one by one. If you already know the culprit, rename only that plugin’s folder instead.

What to do once you have found it

Identifying the conflict is half the job. The fix depends on what kind of conflict it is.

Pattern	Typical symptom	Usual fix
Two plugins loading the same JS library	Sliders, modals or date pickers stop working	Check if one plugin has a “disable built-in jQuery/Swiper” setting; otherwise dequeue the duplicate in a small custom plugin
Same PHP function or class declared twice	Fatal “Cannot redeclare” error	One plugin is badly written; report it and choose the other
Hook priority collision	Output appears in the wrong place or twice	Adjust priority in an add_filter call via a custom plugin
Outdated plugin on new PHP	Deprecated notices, then fatals after a PHP upgrade	Update, or replace if abandoned (check the “last updated” date on WordPress.org)
Theme overrides a plugin template	Plugin features missing after a plugin update	Compare the theme’s override with the new plugin template and update the override

Before contacting support, collect the debug.log excerpt, the browser console error, the Site Health info export, and the exact pair of plugins that trigger the problem. A report that says “Plugin A and Plugin B together break the checkout, here is the error” gets resolved in one reply. “My site is broken” does not.

Preventing the next one

Most conflicts we see arrive through updates. A few habits cut them down sharply.

• Use a staging site. Nearly every managed host offers one-click staging. Run updates there first and click through the checkout, login and any forms before pushing to live.
• Update in batches, not all at once. If you update fifteen plugins together and something breaks, you are back to process of elimination. Update the big ones (WooCommerce, your page builder, your LMS) separately.
• Fewer plugins. Every plugin is a potential conflict partner. Remove the ones you stopped using, and prefer one well-maintained plugin over three overlapping ones.
• Watch the “last updated” date. A plugin untouched for over a year is a liability with each WordPress and PHP release.
• Keep a changelog. A plain text note of what changed and when makes “what did we do last Tuesday” a thirty-second question.

If you would rather not be the person doing this at 11pm, this is exactly what a maintenance retainer covers. Our WordPress care plans include staged updates and conflict testing, and for community or LMS sites with heavier plugin stacks, our development team can resolve the conflicts that need code changes rather than a settings tweak.

Frequently asked questions

Will deactivating plugins delete my data?

No. Deactivation only stops the plugin running. Settings and database tables stay in place. Deleting a plugin may remove its data depending on how it was built, so deactivate, never delete, while testing.

Can I test on a live WooCommerce store?

With Troubleshooting Mode, yes, because only your session is affected. With manual deactivation, no; every customer on the site would see the plugins disappear. Use staging for manual testing.

The problem only happens for logged-out visitors. How do I test that?

Troubleshooting Mode only works for your logged-in session, so use a staging copy and test in a private window. Caching plugins often serve different output to logged-out users, so clear the cache first.

What if two plugins conflict and I need both?

Report it to both developers with your findings. In the meantime, a small custom plugin that dequeues a duplicate script or adjusts a hook priority usually bridges the gap. This is typically an hour or two of developer time.

What we’d do

Turn on debug logging and check the browser console first; half the time the error names the plugin outright. If not, install Health Check & Troubleshooting and work through plugins one at a time in Troubleshooting Mode. Once you know the pair involved, decide whether to update, replace, or patch, and then set up staging so the next update does not surprise you.