WordPress Plugin Conflict: How to Find the Culprit in Minutes

Something on your WordPress site stopped working. The slider is gone, the contact form spins forever, the checkout button does nothing or the admin shows a blank editor. Nothing obvious changed, and you have 30 plugins installed.

That is a plugin conflict: two plugins, or a plugin and your theme, or a plugin and a new WordPress or PHP version, that do not work together. The good news is that finding the culprit is a mechanical process. This guide shows the fastest way to do it, without taking your live site offline, and how to stop the next one before visitors find it.

Signs of a plugin conflict#

• Part of a page disappears or the layout breaks after an update.
• Buttons, sliders, menus or popups stop responding (often a JavaScript error).
• Forms stop sending, or send without the confirmation message.
• The block editor or a page builder will not load, or shows "Updating failed".
• WooCommerce cart or checkout stops working. See WooCommerce checkout not working.
• The whole site shows a white screen or "There has been a critical error on this website". See WordPress critical error and white screen of death.
• Site Health reports loopback, REST API or PHP session errors.

Why plugins conflict#

Plugins all run inside the same WordPress request and the same browser page, so they can step on each other in a few predictable ways:

• Two plugins doing the same job. Two SEO plugins writing titles, two caching plugins, two security firewalls or two form plugins loading competing scripts.
• JavaScript clashes. Optimization plugins that combine, defer or minify scripts can break the order other plugins depend on. One script error can stop every script after it.
• Hooks and priorities. Two plugins filter the same content (titles, the cart, the login form) and one undoes the other.
• Version jumps. A plugin update, a WordPress core update or a PHP upgrade changes a function another plugin relied on.
• Security rules. Firewalls and security plugins block REST API or AJAX requests that page builders, forms and checkout need.
• The theme. Themes, especially page builder themes, bundle their own scripts and template overrides. A "plugin conflict" is often a theme conflict.

Before you start: two minutes of safety#

1. Take a backup of files and database, even if the site is already misbehaving.
2. Write down the symptom precisely: which page, which button, which browser, logged in or out. You need a reliable way to reproduce it to know when it is fixed.
3. Use staging if the symptom shows there too. Most managed hosts offer one-click staging. Our WordPress staging site guide covers the options. If the problem only exists on production, use troubleshooting mode below instead, which does not affect visitors.

Step 1: Check what changed most recently#

Most conflicts start right after something changed. Before you disable anything, answer one question: what was updated, installed or switched on just before the problem started?

• Look at Dashboard > Updates and each plugin's version against its changelog.
• Check your host's activity log or your backup history for the date things changed.
• Remember automatic updates: WordPress may have updated a plugin overnight without anyone clicking. See WordPress automatic updates.

If one plugin updated just before the problem appeared, test that one first. Roll it back to the previous version (see how to roll back a WordPress plugin) and check whether the symptom disappears. This single step solves a large share of conflicts in minutes.

This is also the step a monitoring plugin can do for you: the free MyKavo plugin keeps a history of every plugin, theme and core update on the site, and on paid plans checks your pages after each one and labels any change with the update it appeared after.

Step 2: Use troubleshooting mode (without breaking the live site)#

The classic advice is "deactivate all plugins". On a live site that switches off your forms, your checkout and your SEO plugin for every visitor. There is a better way.

The free Health Check & Troubleshooting plugin, maintained by the WordPress community, has a troubleshooting mode:

1. Install and activate Health Check & Troubleshooting.
2. Go to Tools > Site Health > Troubleshooting and click Enable Troubleshooting Mode.
3. For your browser session only, all plugins are disabled and a default theme is active. Visitors and other admins still see the normal site.
4. Check whether the problem is gone. If it is still there with every plugin off and a default theme, the cause is not a plugin: look at WordPress core, PHP or the server.
5. If it is gone, use the troubleshooting menu in the admin bar to enable your theme, then plugins, and find the one that brings the problem back (see Step 3).
6. Click Disable Troubleshooting Mode when you are done.

Step 3: Split the list in half (the fast way)#

Enabling 30 plugins one at a time means up to 30 rounds of testing. Splitting the list in half is much faster:

1. Enable half of your plugins (say 15).
2. Test. If the problem is back, the culprit is in that half. If not, it is in the other half.
3. Take the suspect half, enable half of it, and test again.
4. Repeat until one plugin is left.

With 30 plugins you find a single culprit in about five rounds instead of 30. Always keep plugins that others depend on enabled together: WooCommerce with its extensions, a page builder with its add-ons.

Some conflicts need two plugins active together. If disabling either one fixes the problem, you have found a pair. Note both, because the fix may involve settings in either.

Do not forget the theme: test with your real theme and a default theme. If the problem only appears with your theme active, contact the theme developer.

Step 4: Read the error instead of guessing#

When the symptom is a crash or a broken button, the error message often names the plugin directly:

• PHP errors: enable debugging in wp-config.php with WP_DEBUG and WP_DEBUG_LOG set to true and WP_DEBUG_DISPLAY set to false. Reproduce the problem, then open wp-content/debug.log. A path such as wp-content/plugins/some-plugin/ in a fatal error is your answer. Turn logging off afterwards.
• JavaScript errors: open the page, press F12, and look at the Console tab. The first red error and the file it points to usually name the plugin. Errors appearing after an optimization plugin combined scripts suggest excluding that script from minification.
• Query Monitor: this free plugin shows PHP errors, failed HTTP requests, slow queries and which plugin added each hook, right in the admin bar.
• Recovery mode: when WordPress catches a fatal error it emails the admin a recovery mode link. Logging in through it pauses the plugin that crashed.

Step 5: If you are locked out of wp-admin#

When the conflict takes down the admin, disable plugins without the dashboard:

• SFTP or file manager: rename wp-content/plugins to plugins-off. Every plugin deactivates. Log in, rename it back, then reactivate plugins in halves.
• One plugin only: rename just that plugin's folder.
• WP-CLI: run wp plugin deactivate --all, or wp plugin deactivate plugin-slug for one. If a plugin crashes WP-CLI too, add --skip-plugins to the command.

How to fix a plugin conflict once you find it#

1. Update both plugins. The conflict may already be fixed in a newer version.
2. Roll back the plugin that changed, if the conflict started with an update. Then pause auto-updates for it until a fixed version is out.
3. Check settings. Exclude the affected script from minify or defer, exclude the checkout and cart from page caching, or allow the blocked REST route in your firewall.
4. Remove the duplicate. If two plugins do the same job, keep one.
5. Report it. Open a topic in the plugin's WordPress.org support forum with the two plugin names and versions, your WordPress and PHP versions, the exact steps to reproduce, and your Site Health Info. Developers fix conflicts fast when they can reproduce them.
6. Replace the plugin if it is abandoned. Plugins with no update in a long time are the most likely to break on new WordPress or PHP versions.

Common conflict combinations to check first#

How to prevent plugin conflicts#

• One plugin per job. Audit plugins twice a year and remove what you do not use.
• Update one plugin at a time, then check the site. Bulk updates hide which plugin broke something. Our guide to safely updating WordPress plugins has the full routine.
• Test risky updates on staging: page builders, WooCommerce, caching and security plugins.
• Watch the site after every update, including automatic ones at night, so you find a conflict in minutes instead of when a customer emails.

Let MyKavo find the conflict for you#

Most of this guide is about one question: which change broke the site? The free MyKavo WordPress plugin answers it as it happens:

• Safe Update All (free). One button: optionally run an UpdraftPlus backup first, then update plugins one at a time, check the site after each, and automatically roll back any update that breaks it. You get a single verdict such as "7 updated, 6 verified, 1 rolled back". That is the half-split method above, done for you on every update.
• "Did it crash?" (free). About ten seconds after each update, the site loads its own home page and up to three monitored pages and looks for server errors, the critical error page, PHP fatal errors and empty pages, with a Roll back now button.
• Snapshots and one-click rollback (free). Before WordPress updates a plugin or theme, MyKavo saves a copy, so any plugin, premium ones included, can be rolled back for seven days.
• The culprit, named (paid plans, from Starter). After every update and every plugin switched on or off, MyKavo checks your key pages and labels each change: "Appeared after: Updated Elementor 3.24.0 to 3.25.0". Before you update again, the Plugins screen warns when a plugin's last update changed things on your site.

Summary#

Back up, then ask what changed last and test that first. If that is not it, use troubleshooting mode so visitors are not affected, and split your plugins in half until the culprit is left. Read the PHP log and the browser console to confirm it. Fix it by updating, rolling back, changing a setting or replacing the plugin, and report it to the developer. Then update one plugin at a time and watch the site after each update so the next conflict takes minutes to find, not hours.