Identifying and Fixing Plugin Conflicts: A Developer’s Proven Method

WordPress plugin conflicts are one of the most common reasons a site breaks — and one of the most fixable, once you know where to look. A conflict happens when two or more plugins (or a plugin and your theme) try to do the same thing, load incompatible JavaScript libraries, or run on a PHP version they weren’t built for. The result ranges from a layout glitch on the front end to a full white screen with no admin access.

Before you do anything else: back up. Both files and database. If your host takes daily automated backups, confirm you know how to restore from one before you start. I’ve seen conflicts get worse during troubleshooting — usually because something gets renamed without a fallback in place.

What kind of conflict are you dealing with?

There are three main types:

• Plugin vs. plugin — two plugins loading conflicting JavaScript libraries, or both trying to modify the same WooCommerce checkout hook.
• Plugin vs. theme — a plugin’s output conflicts with your theme’s CSS or custom template overrides.
• Plugin vs. PHP version — a plugin built for PHP 7.4 throws fatal errors on PHP 8.2, or a newer plugin requires a PHP version your server doesn’t run yet.

Knowing which type you’re dealing with shapes how you troubleshoot. If the problem appeared immediately after a PHP upgrade, start there. If it appeared after activating a specific plugin, that plugin (or its interaction with an existing one) is almost certainly the culprit.

Scenario A: You can still access wp-admin

The site looks broken on the front end, but your dashboard works. You have two options.

Method 1: Safe Mode via the Health Check plugin

This is the method I use on live sites. The Health Check & Troubleshooting plugin (free, by the WordPress core team) has a troubleshooting mode that disables all plugins and switches to a default theme — but only for your browser session. Regular visitors still see the live site while you test on a clean slate.

1. Go to Plugins > Add New and install Health Check & Troubleshooting.
2. Go to Tools > Site Health > Troubleshooting tab.
3. Click Enable Troubleshooting Mode.
4. If the problem disappears, you know it’s a plugin or theme conflict.
5. Re-enable your plugins one by one from the troubleshooting toolbar. Check the site after each one.
6. When the problem reappears, the last plugin you activated is the conflict.

This is the right approach for WooCommerce stores or membership sites where showing visitors a broken checkout while you debug isn’t an option.

Method 2: Bulk deactivation

If you’d rather not install another plugin, the manual route works — but it affects what visitors see while you test.

1. Go to the Plugins screen.
2. Check Select All.
3. Choose Deactivate from the Bulk Actions dropdown and apply.
4. Check the site — the error should be gone with everything off.
5. Reactivate plugins one by one, checking the site in a private/incognito window after each activation.
6. When it breaks again, you’ve found the conflict.

Slower than Safe Mode, and it briefly disrupts live traffic. If you’re doing this during a low-traffic window, it’s a reasonable fallback.

Scenario B: White Screen of Death (locked out)

No dashboard, just a white screen or a “Critical Error” message. Your data is almost certainly intact — you just can’t reach it through the normal route yet. If you’re seeing a “Briefly unavailable for scheduled maintenance” message instead, that’s a different problem: see how to fix a WordPress site stuck in maintenance mode.

For the white screen specifically, the full WSOD guide covers all causes. The two methods below focus on isolating a plugin conflict as the source.

Method 3: Rename the plugins folder via FTP

1. Connect to your server via FTP (FileZilla works) or your host’s file manager.
2. Navigate to /wp-content/.
3. Rename the plugins folder to plugins.deactivated.
4. Try loading wp-admin. If you can get in, a plugin was blocking access.
5. Rename the folder back to plugins, then open it.
6. Rename individual plugin folders one by one — add _OFF to the end of the folder name.
7. Reload wp-admin after each rename. When the dashboard loads, the folder you just renamed contains the conflicting plugin.

This is a blunt approach, but it works when you have no other access. One way to avoid getting here is to apply plugin updates manually one at a time rather than via auto-update — see how to update WordPress plugins manually. That way you can test each update in isolation and know exactly which one broke something.

Method 4: Enable WP_DEBUG to find the exact error

If you want to know why the site is crashing — file name, line number, error type — rather than just which plugin is at fault, enable debug logging.

1. Connect via FTP and open wp-config.php from your site’s root directory.
2. Find the line: define( 'WP_DEBUG', false );
3. Replace it with:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

This writes PHP errors to /wp-content/debug.log without displaying them to visitors. Open that file via FTP and look for lines marked “Fatal error” — they’ll identify the plugin file (and usually the exact line) causing the crash.

Set WP_DEBUG back to false when you’re done. Debug logging left on in production writes to that file indefinitely.

You’ve found the conflicting plugin. Now what?

Your site works with it deactivated. Here’s how to fix it permanently:

• Update everything first. Check that WordPress core, your theme, and the conflicting plugin are all on their latest versions. Many conflicts are version-mismatch issues that a point release has already resolved.
• Roll back the plugin. If the conflict started immediately after an update, the WP Rollback plugin lets you revert to the previous version while the developer ships a fix.
• Check the support forums. Go to the plugin’s page on WordPress.org → Support tab. If your conflict is a known bug, there’s usually already a thread with a workaround or patch link.
• Replace it. If the plugin hasn’t been updated in over a year, or conflicts consistently across WordPress and PHP releases, find an alternative. An unmaintained plugin is a security risk independent of the current conflict.

The cleanest way to avoid this situation is to test plugin updates on a staging environment before applying them to production. Most hosts include a staging clone for free. See how to set up a WordPress staging site if you don’t have one yet.

Plugin conflicts are one category in a broader set of recurring WordPress problems. For the full list with fixes, see the roundup of the 10 most common WordPress errors.

If you’ve worked through the methods above and the conflict keeps coming back — or the fix for the conflicting plugin breaks something else — get in touch. Most plugin conflicts can be diagnosed and resolved remotely in a few hours without touching your live data.