Common WordPress Plugin Conflicts and How to Fix Them: A Step-by-Step Diagnostic Method

Your site worked yesterday. Today the checkout button does nothing, the page builder refuses to load, or the whole front end is a blank white page. In most cases you are not looking at a hack or a server failure. You are looking at a WordPress plugin conflict: two pieces of code fighting over the same hook, the same JavaScript library or the same database table.

The good news is that diagnosing a plugin conflict is a process, not a talent. Below is the exact workflow we use at WebVitamin before we ever write a line of custom code. Follow it in order and you will usually identify the guilty plugin in 20 to 40 minutes, without putting your live site offline and without paying for developer hours you may not need.

What a WordPress plugin conflict actually is

A plugin conflict happens when two or more plugins (or a plugin and your theme, or a plugin and your PHP version) try to do incompatible things at the same point of the WordPress execution cycle. The three most common technical causes are:

Hook collisions: two plugins hook into the same action or filter and one overwrites or short-circuits the other’s output.
JavaScript and jQuery collisions: two plugins load different versions of the same library, or a minification plugin concatenates scripts in the wrong order and breaks dependencies.
Duplicate functionality: two caching plugins, two SEO plugins, two security plugins or two redirect managers all trying to own the same output.

A conflict is not always a bug in one plugin. Very often both plugins are individually fine and simply cannot coexist with a particular combination of settings.

The classic symptoms and what they usually mean

Start by matching what you see to the table below. The symptom tells you which part of the stack to inspect first, and that alone saves a lot of blind clicking.

Symptom	Most likely cause	Where to look first
White Screen of Death (blank page, front end or admin)	PHP fatal error, duplicate function or class name, memory exhaustion	WP_DEBUG log, server error log
“There has been a critical error on this website”	Fatal error caught by WordPress recovery mode	Recovery mode email sent to the admin address
Admin loads but buttons, tabs or modals do nothing	JavaScript error stopping script execution	Browser console (Console tab)
“jQuery is not defined” or “$ is not a function”	jQuery loaded late, deregistered, or replaced by a CDN/optimization plugin	Console plus the page source order of scripts
Page builder spins forever or won’t save	Caching, minification, firewall or REST API blocking	Console Network tab, 403/404 on admin-ajax.php or /wp-json/
Updates fail or site stuck in maintenance mode	Interrupted update, file permissions, conflicting update manager	Delete the `.maintenance` file by FTP, then check logs
Layout suddenly broken, fonts or icons missing	CSS combined or deferred in the wrong order	Disable CSS/JS optimization in the caching plugin
Forms submit but no email arrives	Two plugins filtering `wp_mail` or an SMTP plugin override	Mail log plugin, SMTP plugin settings
Random logouts or login loop	Security, login-URL and caching plugins fighting over cookies and sessions	Caching exclusions, security plugin session rules
WooCommerce cart empties or prices wrong	Cart pages being cached, or two plugins altering price filters	Cache exclusion rules, pricing/discount plugins

Before you touch anything: the five-minute safety checklist

Do not start deactivating plugins on a live site at peak hours. Prepare first.

Take a full backup (files plus database) and verify that it downloaded completely. A backup you cannot restore is not a backup.
Make sure you have a second way in: SFTP/FTP credentials, hosting file manager, or SSH. If a conflict locks you out of /wp-admin, this is how you get back.
Note your admin email. WordPress recovery mode sends a special login link there when a fatal error occurs.
Create a staging copy. Most quality hosts offer one-click staging. This is the single biggest difference between a professional diagnosis and a risky one.
Write down the exact steps to reproduce the problem: URL, user role, browser, logged in or logged out, desktop or mobile.

Why staging matters more than any plugin

On a staging site you can deactivate everything, break things on purpose and test freely while your live site keeps selling. If your host does not provide staging, a local copy (LocalWP, DevKinsta, Docker) works just as well. Only after the fix is confirmed on staging do you repeat it on production, during a quiet window.

Step 1: Rule out the false positives

A surprising share of “plugin conflicts” are not conflicts at all. Eliminate these first, in this order:

Purge every cache layer: plugin cache, object cache, server cache (LiteSpeed, Varnish, NGINX FastCGI), CDN cache, then your own browser.
Test in a private window and in a second browser to exclude extensions and stale local storage.
Disable browser extensions, especially ad blockers and privacy tools, which routinely block admin AJAX requests and analytics scripts.
Check PHP version and memory. In 2026 you should be on PHP 8.2 or newer, with at least 256M memory for a typical WooCommerce site. A “conflict” that appears only on big pages is often exhausted memory.
Check your host status page and disk quota. A full disk produces errors that look exactly like plugin bugs.

Step 2: Read the browser console properly

If the admin loads but nothing clicks, the answer is almost always in the console. This is the skill that separates guessing from diagnosing.

How to open it

Chrome, Edge, Brave: F12, or Ctrl+Shift+J (Cmd+Option+J on Mac)
Firefox: Ctrl+Shift+K (Cmd+Option+K)
Safari: enable Develop menu in Settings > Advanced, then Cmd+Option+C

What to look for

Reload the broken page with the console already open, so you capture errors from the start.
Ignore yellow warnings for now. Focus on red errors.
Look at the file path on the right of each error. If it reads /wp-content/plugins/some-plugin/js/frontend.js, you just found your prime suspect.
Open the Network tab, reload, and sort by status. Any 403, 404 or 500 on admin-ajax.php, wp-json or a plugin asset is a direct lead.

Translating the most common console errors

Console message	What it means in practice
`Uncaught ReferenceError: jQuery is not defined`	A script runs before jQuery loads. Usually caused by JS deferral, combination or a “move scripts to footer” option in an optimization plugin.
`$ is not a function`	A plugin assumes the `$` shortcut exists in WordPress no-conflict mode. A badly coded plugin or theme script.
`Cannot read properties of undefined (reading '...')`	A dependency failed to load earlier. Scroll up: the first red error is the real cause.
`Failed to load resource: 403 (Forbidden)`	A firewall, security plugin or server rule is blocking the request. Classic security plus page builder conflict.
`SyntaxError: Unexpected token '<'`	A PHP error or HTML was returned where JSON or JS was expected. Go straight to WP_DEBUG.
`Refused to execute script ... MIME type`	Minification or a CDN is serving the wrong file. Disable JS combination and retest.

Copy the full error text, including the file path and line number. You will need it later for the plugin support ticket.

Step 3: Enable WP_DEBUG safely (logging, not displaying)

For white screens and fatal errors, PHP logging is mandatory. The key point: never display errors to visitors. Log them to a file instead.

Edit wp-config.php by SFTP or your host file manager and place the following above the line /* That's all, stop editing! */:

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

What each line does:

WP_DEBUG: turns on error reporting.
WP_DEBUG_LOG: writes everything to /wp-content/debug.log.
WP_DEBUG_DISPLAY false and display_errors 0: keeps errors off the screen, so visitors and Google never see them.
SCRIPT_DEBUG: loads unminified core JS and CSS, which makes JavaScript conflicts far easier to trace.

Safer logging to a custom path

Because /wp-content/debug.log is publicly reachable by default on some setups, you can redirect the log outside the web root or to an unguessable filename:

define( 'WP_DEBUG_LOG', '/home/youruser/private-logs/wp-errors-8f3a21.log' );

Reading the log

Reproduce the problem once, then open the log and read from the bottom up. You are looking for lines starting with PHP Fatal error. A typical entry looks like:

PHP Fatal error: Uncaught Error: Call to undefined function acme_helper() 
in /home/site/public_html/wp-content/plugins/acme-addons/includes/class-render.php:118

The file path names the plugin. That is your culprit, or at least the plugin that crashed because of another one.

Turn it off when you are done

Set WP_DEBUG back to false, set SCRIPT_DEBUG to false, and delete the log file. Debug logs grow fast and can contain sensitive paths and queries.

Step 4: The systematic deactivation method

This is the heart of plugin conflict troubleshooting. Do it on staging. Deactivating one plugin at a time is the slow way; use the binary split instead.

The classic sequence

Deactivate all plugins. Select all in Plugins > Installed Plugins, then Bulk actions > Deactivate.
Test the broken behaviour.
- If the problem is gone, a plugin is responsible. Continue.
- If the problem persists, switch to a default theme (Twenty Twenty-Five or similar). If it then disappears, your theme is the issue, not a plugin. If it still persists, you are looking at a server, PHP, database or core issue.
Reactivate half of the plugins. Test again.
Keep halving. If the problem returns, the culprit is in the group you just activated: deactivate half of that group and retest. If it does not return, the culprit is in the other half.
Repeat until one plugin is left. With 32 plugins this takes about 5 tests instead of 32.
Confirm the pair. Many conflicts need two plugins. With only the suspect active the site may work fine, so reactivate the rest one by one until it breaks again. Now you have the exact pair.
Document it: plugin A version X plus plugin B version Y, on WordPress version Z and PHP version N.

Faster with WP-CLI

If you have SSH access, this is considerably quicker and fully reversible:

# list active plugins and save the list first
wp plugin list --status=active --field=name > active-plugins.txt

# deactivate everything
wp plugin deactivate --all

# reactivate a specific group
wp plugin activate woocommerce elementor wordpress-seo

# restore the original state later
wp plugin activate $(cat active-plugins.txt)

Health Check troubleshooting mode: testing without affecting visitors

If you truly cannot use staging, the Health Check & Troubleshooting plugin is the safest option on a live site. It disables plugins and switches the theme for your session only. Visitors keep seeing the normal site while you test. Tools > Site Health > Troubleshooting, then toggle plugins from the admin bar.

Plugin Detective is another useful option: it walks you through conflict isolation interactively and can also clear a stuck maintenance mode.

Step 5: When you are locked out of wp-admin

No admin access means no Plugins screen, so you work at file or database level.

Option A: Rename the plugins folder (FTP or file manager)

Connect by SFTP and go to /wp-content/.
Rename plugins to plugins-off. WordPress cannot find them and deactivates all of them.
Log in to /wp-admin. It should work now.
Rename the folder back to plugins. All plugins stay deactivated and you can reactivate them one group at a time.

Option B: Rename a single plugin folder

If the debug log already named the plugin, rename just that folder, for example acme-addons to acme-addons-off. That disables only the suspect.

Option C: Database route

In phpMyAdmin or Adminer, open the wp_options table (your prefix may differ), find the active_plugins row, copy the value to a text file first, then replace it with:

a:0:{}

That is an empty serialized array and it deactivates every plugin. Restore your saved value when finished.

Option D: Recovery mode email

When WordPress catches a fatal error it emails the site admin a one-time recovery link. That link gives you an admin session with the broken plugin paused, so you can deactivate it in two clicks. Check your admin inbox and spam folder before anything else.

Step 6: Fix it properly, not just make it go away

You identified the pair. Now choose a real fix, in order of preference:

Update both plugins, the theme and WordPress core. On staging. A large share of conflicts are already fixed upstream.
Change settings instead of code. Most JavaScript conflicts are solved by excluding one file from minification, deferral or delayed loading in the caching plugin. Most firewall conflicts are solved by whitelisting admin-ajax.php or a REST route.
Exclude dynamic pages from caching: cart, checkout, my account, login, any page with personalised content.
Remove duplicate functionality. Keep one caching plugin, one SEO plugin, one security plugin, one redirect manager. Overlapping plugins are the most frequent root cause we see.
Open a support ticket with both plugin vendors. Include: WordPress version, PHP version, both plugin versions, the exact error text, the reproduction steps and a note that you isolated the conflict on a clean staging install with a default theme. Tickets written that way get real answers.
Replace one plugin with a better maintained alternative. Check the last update date, the active install count and the support forum before you commit.
Ask a developer for a targeted snippet (changing hook priority, dequeuing a duplicate script, conditional loading) only once options 1 to 6 are exhausted. Keep such snippets in a child theme or a dedicated mu-plugin, never in a parent theme’s functions.php.

Conflict combinations we see most often

Combination	Typical symptom	Usual fix
Page builder + caching/optimization plugin	Editor won’t load, broken layout, missing icons	Disable JS/CSS combination, exclude builder scripts, exclude the editor URL from cache
Two caching plugins	Stale content, random 500 errors	Keep one, delete the other and its leftover drop-ins (`advanced-cache.php`, `object-cache.php`)
Two SEO plugins	Duplicate meta tags, two sitemaps, canonical conflicts	Migrate data, keep one, deactivate and delete the other
Security/firewall + REST-based plugin	403 on `/wp-json/`, features silently failing	Whitelist the route, relax the rule, allowlist your IP
Custom login URL + caching or security plugin	Login loop, lockout, 404 on login page	Exclude the login URL from cache, align both plugins’ settings
WooCommerce + full-page cache	Cart empties, wrong totals, shared sessions	Exclude cart/checkout/account, exclude Woo cookies
Two SMTP or mail plugins	Emails not delivered at all	Keep a single `wp_mail` handler
Multilingual plugin + any plugin storing its own URLs	Wrong language URLs, duplicated content	Use the official compatibility add-on or vendor integration
Lazy load plugin + slider or gallery	Blank slides, images never appearing	Exclude the slider container class from lazy loading

How to prevent the next WordPress plugin conflict

Keep a staging site permanently. Every update goes there first, then to production.
Update in small batches, not 24 plugins at once, so causality stays obvious.
Audit your plugin list quarterly. Delete, do not just deactivate, anything you do not use. Deactivated plugins are still a security and maintenance liability.
Vet before installing: last updated date, tested up to version, number of unresolved support threads, changelog quality.
Avoid overlap by design. One plugin per job.
Enable automatic backups with a tested restore procedure, and keep off-site copies.
Use a child theme or mu-plugin for custom snippets so updates never wipe your fixes.
Monitor uptime and PHP errors so you learn about a conflict from a notification, not from a customer.

When it is time to call a developer

Hand it over if any of these apply:

The problem persists with all plugins off and a default theme active (likely server, database or core level).
The debug log shows database errors, corrupted tables or repeated memory exhaustion.
You suspect malware: unknown admin users, injected scripts, modified core files.
The conflict is inside a business-critical checkout or booking flow and every hour of downtime costs real money.
Both vendors refuse responsibility and a custom compatibility layer is the only remaining option.

Even then, the notes you produced by following this workflow (reproduction steps, console errors, fatal error lines, the isolated plugin pair) will cut the billable diagnosis time dramatically. If you want that work handled for you, the WebVitamin team troubleshoots WordPress conflicts, performance issues and failed updates on staging environments, so your live site stays online while we fix it.

FAQ

How do I know whether it is a plugin conflict or a theme problem?

Deactivate all plugins. If the issue remains, switch to a default WordPress theme. If it disappears with the default theme, your theme is involved. If it persists with no plugins and a default theme, the cause is outside WordPress: server configuration, PHP version, database or core files. A comparable breakdown sits on wordpress.org.

Can I test for plugin conflicts without taking my site offline?

Yes. Use a staging copy, a local install, or the Health Check & Troubleshooting plugin, which disables plugins only for your own logged-in session. Visitors continue to see the normal site.

Is it safe to leave WP_DEBUG enabled on a live site?

Only with WP_DEBUG_DISPLAY set to false and logging to a protected path, and only for as long as you need it. Displaying PHP errors publicly exposes file paths and other details that help attackers, and it looks unprofessional to visitors.

Why does my site break only after a plugin update?

Updates change hooks, script handles, dependencies and minimum PHP requirements. A combination that worked for a year can break because one plugin renamed a function another one relied on. This is precisely why updates belong on staging first. getwaas.io has a solid rundown on this.

How many plugins are too many?

There is no magic number. Twelve well-coded plugins can be lighter and more stable than four bloated ones. What matters is code quality, overlap and maintenance. Two plugins doing the same job are a bigger risk than twenty doing distinct jobs well.

What should I include in a support ticket about a conflict?

WordPress version, PHP version, both plugin names and versions, active theme, the exact error text from the console or debug log, numbered reproduction steps, and confirmation that you isolated the conflict on a clean staging install with a default theme and only those plugins active.

Does deactivating a plugin delete its data?

Deactivation almost never deletes data. Deletion sometimes does, depending on the plugin’s uninstall routine. Always back up before deleting, and check the plugin’s documentation if it stores content such as forms, orders or custom post types.