WordPress plugin conflict checker and troubleshooter

How do you use this plugin conflict checker?

Back up files and database first, or work on a staging copy. The helper finds the plugin causing the problem with a binary search. First you turn every suspect plugin off once to check that a plugin is the cause at all. After that you turn off half of the remaining suspects each round instead of testing them one by one. That is one all-off check plus about log2 of your plugin count, rounded up. With 32 plugins it takes at most 6 checks in total (1 plus 5) instead of up to 32.

1. Paste your active plugin names, one per line. Copy them from Plugins, Installed Plugins, or paste the output of wp plugin list --status=active --field=name.
2. Optional: list plugins to keep on, such as WooCommerce for a checkout bug. They stay active and are never tested.
3. Round 1: deactivate every plugin the helper lists, clear your caches and test. Answer “No, it is fixed” or “Yes, still broken”. If it is still broken, no listed plugin is the cause and the helper shows what to check next.
4. Next rounds: deactivate only the half the helper lists, keep the rest active, test and answer again. Each answer cuts the suspect list in half.
5. Gave a wrong answer? Click “Undo last answer” to go back one round.
6. When one plugin is left, the result screen names it and lists next steps, such as updating it or checking for a conflict with one other plugin.

What should you do for each symptom?

Use this table as a reference before or alongside the helper. The helper itself works the same for every symptom.

What is recovery mode and how does it work?

Since WordPress 5.2, when a plugin or theme causes a fatal error, visitors see a generic error message and WordPress emails a special login link to the site admin email address (WordPress core announcement). Clicking it puts your browser into recovery mode with a cookie. The faulty plugin or theme is paused for you only, so you can log in and deactivate or update it. Other visitors still see the error until you fix it.

• The email goes to the RECOVERY_MODE_EMAIL constant if you define one in wp-config.php, otherwise to the admin email (source).
• By default WordPress sends this email at most once a day, and the link stays valid for one day (WP_Recovery_Mode).
• No email? Check spam, then use FTP or your host file manager to rename the plugin folder in wp-content/plugins/. WordPress deactivates a plugin whose folder it cannot find.

How does the Health Check and Troubleshooting plugin help?

The free Health Check and Troubleshooting plugin, published by the WordPress.org community, has a Troubleshooting Mode. It gives you a clean session where all plugins are disabled and a default theme is used, but only for your logged-in user until you turn it off or log out.

Turn it on from Tools, Site Health, Troubleshooting. While in the mode you can enable plugins one at a time from the Plugins screen with “Enable while troubleshooting”, and switch themes (WooCommerce guide), which works well with the binary search helper above. If you get stuck, clearing your browser cookies ends the session. Note that the plugin page says it has not been tested with the latest three major WordPress releases, so test on staging first if you can.

How do you turn on WordPress debugging safely?

Add these lines to wp-config.php above the line that says “stop editing”, as shown in the WordPress debugging documentation:

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

• WP_DEBUG turns debug mode on. It is off by default.
• WP_DEBUG_LOG writes errors to wp-content/debug.log. You can give it a path instead, for example '/tmp/wp-errors.log', to keep the log out of the public folder.
• WP_DEBUG_DISPLAY defaults to true. Set it to false on a live site so visitors do not see errors.

The WordPress documentation advises against using debug tools on live sites. Turn debugging off when you finish and delete the log, because a debug.log in wp-content can be downloaded by anyone who guesses the URL unless your server blocks it.

Worked example of the binary search

You have 20 plugins and the checkout page breaks. Round 1: turn all 20 off: fixed, so a plugin is the cause. Round 2: reactivate them, then turn off plugins 1 to 10: still broken, so the cause is in 11 to 20. Round 3: turn 1 to 10 back on and turn off 11 to 15: fixed, so it is in 11 to 15. Round 4: turn 11 to 15 back on and turn off 11 to 13: still broken, so it is 14 or 15. Round 5: turn off 14 only: fixed. Plugin 14 is the cause, found in 5 checks: one all-off check and 4 halving rounds. If the found plugin does not cause the problem on its own, the conflict may be between two plugins or with the theme, so also test with a default theme.

Common mistakes

• Testing without clearing page, browser and CDN caches, so the old broken page keeps showing.
• Deleting plugins instead of deactivating them, which can remove their settings.
• Forgetting must-use plugins in wp-content/mu-plugins/, which cannot be disabled from wp-admin. Remove the file to turn one off.

Tips to prevent future conflicts

• Keep a staging site and test updates there first.
• Keep automatic daily backups stored off the server.
• Remove plugins you no longer use and avoid two plugins that do the same job, such as two caching plugins.
• Our WP Toolkit Studio plugin gathers common admin tools in one place, and our website development team can fix conflicts for you.

Last updated: October 19, 2026