Plugin conflicts: how to debug — lessons from production

Plugin conflicts: how to debug — lessons from production

At 2 AM, your client's WooCommerce site stops accepting payments. At 9 AM, support reports that the checkout page is throwing a fatal error. You didn't touch the code—someone installed a new plugin yesterday. Plugin conflicts are among the most difficult issues to isolate in WordPress because the platform loads hundreds of hooks and filters simultaneously, and when two plugins clash, the error messages rarely point to the root cause.

We've spent countless hours tracing conflicts across dozens of production sites. The good news: plugin conflicts follow predictable patterns, and a methodical approach beats random guessing every time. This guide walks through the exact process we use to identify which plugin breaks the site, reproduce the failure reliably, and get plugins working together again.

Reproduce — Note exact steps and errors

Before you disable anything, document what you're seeing. A vague "the site is broken" doesn't help when you're testing fixes. Reproduction is half the battle because it lets you verify the fix actually works and prevents wasted time chasing red herrings.

Start by collecting:

• Exact error message: Check wp-content/debug.log (enable WP_DEBUG and WP_DEBUG_LOG in wp-config.php if not already set).
• Steps to reproduce: "Click cart icon, see blank page" is better than "checkout doesn't work."
• When it started: After which plugin was installed or updated? Check the activity log in a security plugin if you have one.
• Browser console errors: Open DevTools (F12), look for JavaScript errors on the affected page.
• Server logs: Check /var/log/apache2/error.log or /var/log/nginx/error.log for PHP warnings or fatal errors.

A real example: A client's product filter stopped working after installing a new ratings plugin. The error log showed Call to undefined function get_term_meta(). That told us the ratings plugin was calling a function that didn't exist in their older WordPress version, or it was hooking into the wrong priority and running before the function was defined. With that direction, we narrowed the suspects immediately.

// In wp-config.php, enable debugging
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
// Logs go to wp-content/debug.log

Disable plugins — Troubleshooting mode or wp plugin deactivate --all

Once you've documented the issue, the fastest way to confirm it's a plugin conflict is to deactivate all plugins at once. If the problem vanishes, you know a plugin caused it. If it persists, the issue lives in theme code or WordPress core (or a must-use plugin).

You have two options: the UI or WP-CLI. The UI is slower but safer if you're not confident in command line. WP-CLI is faster for large plugin sets.

Via WordPress admin (safe for non-technical clients):

1. Go to Plugins → Installed Plugins.
2. Select all plugins using the checkbox in the header.
3. From the bulk actions dropdown, choose "Deactivate."
4. Test the problem area. Does it work now?

Via WP-CLI (faster, better for production with logging):

wp plugin deactivate --all

Then test the site. If the issue is gone, re-enable the plugins one category at a time so you can find the culprit faster. If the issue persists, the problem is not a plugin.

On a production site with 40+ plugins, the UI method takes 10 minutes. WP-CLI does it in seconds. We always use WP-CLI in production, but we also SSH into a staging copy first so there's no risk to live traffic.

Bisect — Re-enable half at a time

Bisecting is the key technique that separates fast debugging from endless plugin-by-plugin testing. Instead of re-enabling 40 plugins one at a time (40 tests), you enable 20, test, then halve again. This narrows the search from O(n) to O(log n).

The bisect workflow:

1. With all plugins disabled, split them into two halves.
2. Enable the first half. Test the problem area.
3. If the issue appears, the culprit is in this half. Disable them and move to step 4.
4. If no issue, keep this half enabled and test the second half.
5. Repeat with the smaller group until you isolate a single plugin.

Example with 8 plugins:

Four tests instead of eight. With 40 plugins, you go from 40 tests to 6.

Group plugins smartly to speed this up. Keep security, caching, and SEO plugins together since they often interact. Keep builder plugins (Elementor, Divi) separate from each other since they're both heavy. If you suspect a specific plugin (based on when the issue started), move it to the first test group.

// Manual bisect via WP-CLI
wp plugin deactivate --all
wp plugin activate plugin-1 plugin-2 plugin-3 plugin-4
// Test site
// If issue found, narrow:
wp plugin deactivate --all
wp plugin activate plugin-1 plugin-2
// Test site again

Once you've isolated the guilty plugin, you know the next steps: check if an update is available, contact the author with your reproduction steps, or find an alternative plugin.

Report — Share findings with plugin authors

Good debugging work is wasted if you don't report it properly. Plugin authors want to fix real issues, but they need clear, actionable information.

Include in your report:

• WordPress version, PHP version, and other plugin versions: Conflicts are often version-specific.
• Exact reproduction steps: "Go to shop page, sort by price, conflict appears" is actionable. "Site broken" is not.
• Error messages from debug.log: Copy the full stack trace, not a screenshot.
• Which other plugin conflicts with yours: List the conflicting plugin name and version.
• Whether it's a fatal error, warning, or just broken functionality: A fatal that takes down the site is more urgent than a styling glitch.

Example report to a plugin author:

Plugin X conflicts with Plugin Y on WordPress 6.2, PHP 8.1. When both are active and you visit a product page with X's shortcode, PHP fatal error: "Undefined function get_product_meta()." Disabling X resolves it. Error log attached. Happens 100% of the time. Plugin Y is a dependency and can't be removed. Can X check if it's calling get_product_meta() before it's defined?

Authors are far more likely to respond to that than "your plugin breaks my site."

Post reports on the plugin's WordPress.org support forum or GitHub issues page. Monitor for responses and be ready to test a fix or provide additional debug information. Most maintainers take conflicts seriously and fix them quickly once they understand the issue.

Common mistakes

• Testing without clearing cache: Browser cache, object cache (Redis), and page cache can mask whether a fix actually works. Always hard-refresh or clear cache between tests.
• Not isolating enough: If you enable 10 plugins at once and the issue appears, you still don't know which one caused it. Force yourself to narrow to 2-3 at a time.
• Assuming it's the newest plugin: The plugin installed yesterday often gets blamed, but the real culprit might be an old plugin that recently auto-updated. Check update logs.
• Forgetting to test in production environment: A plugin might work fine on PHP 7.4 but fail on PHP 8.1. Test on the exact version running live.
• Not documenting steps for next time: When you solve a conflict, write it down. Your team will hit the same issue again, and having notes saves hours.

Key takeaways

• Always reproduce the issue and check debug.log before touching anything. Error messages save time.
• Deactivate all plugins at once to confirm it's a plugin conflict, not a theme or core issue.
• Use binary search (bisecting) to isolate the culprit in O(log n) tests instead of testing plugins one-by-one.
• Report conflicts to plugin authors with full context: versions, exact reproduction steps, and error messages.
• Use WP-CLI for speed in production; test on a staging copy first.
• Clear caches between tests and always test in the exact environment where the issue occurs.