A plugin conflict is rarely announced as one. What you see is a slider that stopped sliding, a checkout button that does nothing, a settings page that loads half-empty, or a full-page error. Nothing on screen tells you that two pieces of code are fighting. This page explains how that fight happens, how to narrow it down without making things worse, and what we do when the usual tricks have not found the answer. If you are not yet sure a conflict is what you are dealing with, our guide to common WordPress errors and their fixes helps you place the symptom first.
What a plugin conflict actually is
Every plugin on your site runs inside the same WordPress install, on the same page load, sharing the same memory, the same database and the same browser window. Most of the time they politely ignore each other. A conflict is the moment two of them reach for the same thing and only one can have it.
That “thing” can be a PHP function name, a JavaScript library, a slot in the page where something gets printed, a database option, or a WordPress hook that both plugins change in incompatible ways. The theme counts too. A theme is just a larger bundle of code that runs on every page, so a plugin can clash with the theme exactly as it can clash with another plugin.
The important consequence: neither plugin is necessarily broken. Each one may work perfectly on its own. The bug only exists in the combination, which is why the plugin’s developer often cannot reproduce it and why the fix sometimes lives in neither plugin.
How conflicts usually show up
There are two broad families, and telling them apart early saves a lot of time.
Server-side conflicts (PHP)
These happen before the page reaches the visitor. When they are serious, the page does not load at all: you get the “There has been a critical error on this website” message, a 500 error, or a blank page. A typical PHP message in the log reads something like “Cannot redeclare function”, which means two plugins (or a plugin and the theme) defined code with the same name. Our critical error repair service covers that full-page failure in more depth.
Browser-side conflicts (JavaScript and CSS)
Here the page loads, but parts of it misbehave. Menus will not open on phones, pop-ups never appear, a form submits without sending, a page builder’s editor spins forever, or product image galleries freeze. The server is happy; the trouble is in the browser, where scripts from different plugins load in the wrong order, load two different copies of the same library, or one script throws an error that stops the ones after it from running. These are the conflicts people most often mistake for “the plugin is just buggy”.
Why they happen
- Two plugins doing the same job. Two SEO plugins both writing meta tags, two caching plugins both rewriting the page, two security plugins both rewriting login rules. Overlap is the most common cause and the easiest to remove.
- Bundled copies of shared code. Many plugins ship their own copy of a common library. If two ship different versions, whichever loads first wins, and the other plugin gets code it was not written for.
- Optimisation plugins combining scripts. Minifying, combining or deferring JavaScript changes the order things load in. A script that worked when loaded normally can fail once it is merged with fifty others into one file.
- An update on one side only. Plugin A changes how it does something; plugin B, which relied on the old behaviour, has not caught up. The combination worked yesterday and fails today. If that is your story, the after-update recovery page may be the better fit.
- Theme functions that duplicate plugin features. Premium themes often build in sliders, forms or schema output. Add a plugin for the same feature and you have two systems competing on every page.
- Old code nobody maintains. A plugin that stopped receiving updates gradually falls out of step with everything around it. Our article on what to do about an abandoned plugin explains how to judge whether one is worth keeping.
What you can safely check yourself first
Before anything else, make sure a fresh, complete backup exists (files and database) and that you know where it is stored. Conflict testing means switching things off, and on a live store that can briefly affect real customers, so pick a quiet hour.
Look for the recovery mode email
When a PHP fatal error takes the site down, WordPress usually emails the site’s admin address with a special login link and, often, the name of the plugin or theme where the error happened. Check that inbox (and its spam folder) before doing anything else. That email is the closest thing to a free diagnosis WordPress gives you.
Use troubleshooting mode instead of switching plugins off for everyone
The free Health Check & Troubleshooting plugin on wordpress.org offers a troubleshooting mode: for your own logged-in session only, every plugin is turned off and a default theme takes over. Visitors keep seeing the normal site while you turn plugins back on one by one. It is a far gentler way to test on a live site than bulk-deactivating everything.
Open the browser console for front-end problems
If the page loads but something on it does not work, press F12 (or right-click and choose Inspect) and open the Console tab, then reload. Red error lines often include a file path, and that path usually contains the folder name of the plugin that threw the error. It is not always the guilty party, since the plugin that fails is sometimes the victim of one that loaded before it, but it tells you where to look.
If you are locked out of wp-admin
Using your host’s file manager or FTP, rename the folder wp-content/plugins to something like plugins-off. WordPress will treat every plugin as deactivated. If the dashboard comes back, rename the folder back and then rename individual plugin folders to find the one responsible. Renaming is easy to undo; deleting is not, so never delete plugin folders while testing.
Write down what you change
It sounds trivial. It is the step that most often goes missing, and a site where nobody remembers which ten plugins were switched off is harder to put back together than the original fault was to find.
Why “one at a time” sometimes finds nothing
The classic method of disabling everything and re-enabling plugins one by one works well for simple clashes. It gives misleading answers in a few situations we run into regularly:
- Caching hides the result. You switch a plugin off, but the page you are looking at is a cached copy from a minute ago. Without clearing the plugin cache, server cache and any CDN between tests, every test can look the same.
- The fault needs three ingredients. Some conflicts only appear when a specific pair of plugins is active together with a particular theme setting. Turning plugins on one at a time against a default theme never recreates the combination.
- It only affects some visitors. Logged-out users, mobile browsers, a certain payment method or a certain product type. If you test while logged in on a desktop, the problem simply does not happen for you.
- It happens on a schedule. Faults triggered by scheduled tasks, imports or third-party callbacks do not appear when you reload a page.
Our guide to the recurring causes of WordPress breakage covers more of these traps from the owner’s side.
How we find and fix the culprit
Our approach is built around not experimenting on your live business.
Reproduce it on a copy
We copy the site to a staging environment and confirm the fault happens there too. If it does not, that itself is useful: it points at caching, the server, or something only the live environment has, such as a CDN rule.
Read the evidence before guessing
With debugging turned on (the WP_DEBUG and WP_DEBUG_LOG settings in wp-config.php, which write errors to wp-content/debug.log), PHP conflicts usually name the files involved. The browser’s console and network tab do the same for scripts. Our posts on turning on WordPress debug mode safely and reading the error log explain what those lines mean if you want to look yourself.
Halve the list instead of walking it
On a site with forty plugins, switching them on one at a time is slow. We split them into halves, find which half carries the fault, split again, and so on. That reaches the pair responsible much faster, and the same logic finds three-way combinations that the single-step method misses.
Choose the smallest lasting fix
Finding the clash is half the job. The fix depends on what we find, and we explain the options before choosing:
- updating one side, when the developer has already solved it;
- changing a setting, such as excluding one script from minification or turning off a duplicated feature in the theme;
- replacing one plugin with a maintained alternative that does the same job;
- a small, documented code adjustment in a child theme or a must-use plugin, so it survives future updates;
- reporting the bug to the plugin’s developer with the details they need, when the fix belongs to them.
Once the change is tested on staging, we apply it to the live site, clear every cache layer, and check the pages and actions that were affected, plus the ones most likely to be hurt by the change.
Keeping it from coming back
Most sites that suffer repeated conflicts have a plugin list nobody has questioned in years. A short review usually turns up overlap: two form plugins, a builder add-on pack used for one widget, an optimisation plugin fighting the host’s own cache. Removing what is not needed lowers the number of combinations that can go wrong.
The other habit is updating in small groups rather than all at once, with the riskier plugins (page builders, caching, security, checkout) done separately. When something does break, you then know which change caused it.
Conflicts are one part of the wider work our WordPress bug fixing service handles. If you have a clash right now, send us the error text or a screenshot along with what changed recently, and we will tell you plainly what we see. Builder-specific clashes have their own page too: see Elementor repair if the editor is where things broke.