How to Troubleshoot a WordPress Plugin Conflict Step by Step

Two plugins tried to do the same thing on your site and one of them lost. Or maybe they loaded scripts in the wrong order. Either way, something broke: a form stopped submitting, a page went blank, or your admin panel crashed.

That is a WordPress plugin conflict. It is one of the most common site problems, and it is almost always fixable without deleting anything permanently.

This guide walks through each diagnostic step in the right order. I have structured it to start with the safest, fastest checks first and escalate only if needed.

One thing to clarify before you start: if your site is simply loading slower after a plugin update, that is a performance issue rather than a conflict. Check How to Find Which WordPress Plugin Is Slowing Down Your Site instead. This guide focuses on functional failures: broken features, error pages, and access problems.

Before You Start

Backup first. Use your host's snapshot tool, UpdraftPlus, or another backup plugin before changing anything. If something goes wrong, you need a restore point.

Use staging when possible. A staging copy lets you run all these tests without any risk to your live visitors. Once you identify the conflict on staging, you can apply the fix to production with confidence. The WordPress Staging Site Checklist covers what to verify once your staging environment is ready.

If wp-admin is completely inaccessible, skip to Step 3 (FTP method).

Quick Fix Summary

1. Confirm the problem is a functional conflict, not a slowdown.
2. Check the browser console (F12) for JavaScript errors.
3. Install and enable Health Check Troubleshooting Mode to disable all plugins for your session only.
4. Re-enable plugins one at a time. Test after each one.
5. The plugin that brings the problem back is the conflict source.
6. Update, replace, or remove the conflicting plugin.
7. Disable Troubleshooting Mode to restore your site. Verify all plugins re-activated.

Step 1: Confirm It Is a Plugin Conflict

Before disabling anything, confirm you are dealing with a conflict, not a server issue or misconfiguration.

Do these quick checks first:

• Clear your site cache and browser cache.
• Try the problem page in an incognito/private window.
• Check your hosting status page for outages.

Signs it is likely a plugin conflict:

• The problem appeared right after installing or updating a plugin.
• It only happens when two specific features are used together.
• You see a white screen, HTTP 500 error, or "there has been a critical error" message.
• An admin page crashes, redirects unexpectedly, or shows a broken layout.
• A form, checkout, or booking feature that worked before now fails.

Signs it is probably something else:

• The site is just slower (see the slow-plugin guide linked in the intro).
• One specific post or page is missing content (likely a post editor or block issue).
• The problem started after a server migration or PHP version change.
• All sites on your host are affected (server outage).

Step 2: Check the Browser Console for JavaScript Errors

This is the fastest diagnostic step. It takes about 30 seconds and does not change anything on your site.

1. Open the problem page in your browser.
2. Press F12 (Windows/Linux) or Cmd + Option + J (Mac) to open developer tools.
3. Click the Console tab.
4. Reload the page.

Look for red error messages. The most common conflict indicators are:

If you find an error with a clear plugin name or file path in it, note it down. That is your leading suspect before any further testing.

Step 3: Use Health Check Troubleshooting Mode

The Health Check and Troubleshooting plugin (free from WordPress.org) is the safest tool for this job. Its Troubleshooting Mode disables all plugins and switches to a default theme for your browser session only. Your live visitors see the normal site throughout the entire process.

Install and activate

1. Go to Plugins > Add New in your WordPress admin.
2. Search for "Health Check and Troubleshooting."
3. Install and activate it.

Enable Troubleshooting Mode

1. Go to Tools > Site Health.
2. Click the Troubleshooting tab.
3. Click Enable Troubleshooting Mode.

Your session now runs with all plugins disabled and the default WordPress theme active. A bar appears at the top of the admin screen confirming you are in Troubleshooting Mode.

Test with everything disabled

Navigate to the page or feature that was broken. If the problem disappears with all plugins disabled, a plugin is the cause. If the problem persists with all plugins disabled, suspect the theme or a server-level issue and skip to Step 4.

Re-enable plugins one at a time

1. From the Troubleshooting tab, re-enable one plugin.
2. Reload the affected page and check whether the problem returns.
3. Repeat for each plugin.
4. When the problem comes back, the last plugin you re-enabled is the conflict source or part of the pair causing the conflict.

For sites with 10 or more plugins, use the binary method:

This approach is faster. Instead of enabling one plugin at a time:

1. Re-enable half your plugins at once.
2. Test the problem page.
3. If the problem does not appear, disable that group and enable the other half.
4. Once you identify which half contains the conflict, split that group in half again.
5. Keep dividing until you isolate the single plugin.

In my testing, this method finds the conflict source in around 5 rounds instead of 30 or more sequential tests.

Exit Troubleshooting Mode

Click Disable Troubleshooting Mode in the admin bar at the top of the screen. Your plugins should return to their previous active/inactive states.

Important: A small number of users have reported that exiting the mode left some plugins in a deactivated state. After disabling the mode, go to Plugins > Installed Plugins and confirm that all previously active plugins are active again. Reactivate any that did not restore automatically.

Step 4: Disable Plugins via FTP When Admin Is Locked

If the conflict has made your admin panel inaccessible, use FTP or your hosting control panel's File Manager.

Disable all plugins at once:

1. Connect via FTP or open File Manager in your hosting panel.
2. Navigate to wp-content/.
3. Rename the plugins folder to plugins-disabled.
4. WordPress cannot find the folder, so all plugins deactivate automatically.
5. Try loading your site and wp-admin again.

Disable a single plugin:

1. Navigate to wp-content/plugins/.
2. Rename just that plugin's folder. For example, rename contact-form-7 to contact-form-7-disabled.
3. WordPress deactivates it automatically.

To restore either method, rename the folder back to its original name.

Note: Work on a staging copy if possible. Renaming the plugins folder on a live site will break any frontend features that depend on those plugins until you rename it back.

Step 5: Switch to a Default Theme to Rule Out Theme Involvement

Some issues that look like plugin conflicts are actually caused by a theme function interfering with a plugin. A quick theme switch rules this out.

Via wp-admin:

1. Go to Appearance > Themes.
2. Activate a default WordPress theme such as Twenty Twenty-Four or Twenty Twenty-Three.
3. Test the problem page.

If the problem disappears with the default theme active, the conflict is in your active theme, not a plugin. Contact your theme developer or check your child theme's functions.php for conflicting code.

Via FTP (if admin is locked):

1. Navigate to wp-content/themes/.
2. Rename your active theme folder. For example, rename divi to divi-disabled.
3. WordPress falls back to the default theme automatically.

Step 6: Enable PHP Debug Logging

If you have identified a conflict but need more detail about what is failing and where, PHP debug logging captures server-side errors to a file without displaying them to visitors.

Add these lines to wp-config.php before the comment that reads /* That's all, stop editing! Happy blogging. */:

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

What each line does:

After saving, reproduce the problem. Then open wp-content/debug.log via FTP or File Manager. Look for entries that include a specific plugin file path. That path points to where the error is originating.

Remove these lines from wp-config.php after you are done diagnosing. Leaving WP_DEBUG active on a live production site can expose internal file paths to anyone who views source. Do this step on a staging copy when possible.

Step 7: Contact the Plugin Vendor with a Reproducible Test Case

Once you have identified which plugin (or which pair of plugins) causes the conflict, report it. A clear report gets a faster fix.

Information to include:

• WordPress version (visible in the admin footer)
• PHP version (visible in Tools > Site Health > Info > Server)
• Plugin name and version number for both plugins involved
• What you expected to happen
• What actually happened
• Exact steps to reproduce the conflict on a clean setup
• Any JavaScript console errors or PHP debug.log entries you captured

Where to report:

• WordPress.org support forum for the plugin: go to the plugin's page at wordpress.org, click "Support"
• Plugin's own support system: most premium plugins have a ticket or chat system

While waiting for a fix:

• Keep the conflicting plugin disabled if the site can function without it.
• Look for an alternative plugin that handles the same function.
• If both plugins are essential, a developer can often resolve the conflict by adjusting hook priorities - but this is not a beginner task and should not be attempted on a production site.

If This Does Not Work

Problem persists after disabling all plugins in Troubleshooting Mode: The issue is likely in your theme, a child theme function, or a server configuration. Switch to a default theme (Step 5). Also check your hosting panel's error log, which often shows server-level PHP errors that wp-content/debug.log does not capture.

Problem is only in wp-admin, not on the frontend: Must-use plugins, stored in wp-content/mu-plugins/, cannot be deactivated from the admin panel. They always load. If you suspect one is involved, access that folder via FTP and rename the file to disable it. This is an advanced step; proceed with care on a live site.

Troubleshooting Mode exited but plugins are still deactivated: This is a known edge case with the Health Check plugin. Go to Plugins > Installed Plugins and manually reactivate each plugin. Then test your combinations again to confirm the conflict is resolved.

Two required plugins conflict and both need to stay: This requires a developer. Common resolutions include adjusting add_action or add_filter priorities in a child theme's functions.php, or requesting a compatibility patch from one of the plugin authors. Do not modify plugin files directly - your changes will be overwritten by the next update.

Common Mistakes to Avoid

• Testing on the live site without a backup. If you break something while disabling and re-enabling plugins, you need a restore point. Always back up first.

• Deactivating all plugins at once via the admin bulk action, then re-enabling all at once. This does not isolate the conflict. Re-enable them one at a time.

• Skipping the browser console. In my experience, checking F12 first takes 30 seconds and catches JavaScript conflicts immediately, before touching a single plugin setting.

• Forgetting to clear cache between tests. Your caching plugin or hosting-level cache can show you a cached version of the broken page even after the fix. Clear it after each test.

• Leaving WP_DEBUG enabled on a live site after diagnosis. Set WP_DEBUG to false or remove the lines from wp-config.php when you are done.

• Updating all plugins at once after resolving the conflict. If a new conflict appears, you will not know which update caused it. Update plugins one at a time and test after each one. The guide on how to safely update WordPress plugins covers this in detail.

• Not reporting the conflict to the vendor. A quick forum post helps other users with the same setup and gets the fix logged.

When to Ask for Help

Contact your hosting provider if:

• wp-admin is locked and FTP credentials are not working.
• The server error log shows database connection errors (these are hosting-level, not plugin-level).
• Your site is on managed WordPress hosting where FTP access is restricted or controlled by the host.

Contact a WordPress developer if:

• Two required plugins conflict and both need to stay active on the site.
• The conflict involves custom code in a child theme's functions.php.
• You see errors that involve mu-plugins or core WordPress files.
• You have completed all steps above and still cannot identify the source.

Contact the plugin developer if:

• You have isolated the conflict to a specific plugin or plugin pair and have the details from Step 7.
• The plugin has an active support forum or ticket system and the issue looks like a compatibility bug.

Final Checklist

• Backup created before any testing
• Browser console (F12) checked for JavaScript errors
• Cache cleared before and after each test
• Health Check Troubleshooting Mode used to disable all plugins safely
• Plugins re-enabled one at a time to isolate the conflict
• Default theme tested to rule out theme involvement
• PHP debug logging enabled on staging (if needed) and removed after diagnosis
• Conflicting plugin updated, replaced, or reported to vendor with full details
• Troubleshooting Mode exited and plugin list verified in wp-admin
• Site checked on frontend after restoring normal plugin state
• Future plugin updates planned one at a time: see How to Safely Update WordPress Plugins

Before installing new plugins: The Before You Click Install: A 5-Minute WordPress Plugin Check covers compatibility signals to look for in the WordPress.org listing, which can help you catch potential conflicts before they happen.