How to Diagnose a WordPress Plugin Conflict

Enable WP_DEBUG

By default, WordPress hides PHP errors. Turn on debug logging so you can see what's happening.

Edit wp-config.php in your WordPress root. Find this line:

define('WP_DEBUG', false);

Replace it with these four lines:

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

What each does:

• WP_DEBUG — turns on error reporting
• WP_DEBUG_LOG — writes errors to wp-content/debug.log
• WP_DEBUG_DISPLAY — hides errors from visitors (important for production)
• SCRIPT_DEBUG — loads unminified CSS/JS so conflicts are easier to trace

Reproduce the error

Visit the exact page or trigger the exact action that breaks the site. Then check the log file.

Where to find the log:

• Via SFTP: wp-content/debug.log
• Via your host's file manager: same path
• Via WP-CLI: wp log show --lines=50 (if the WP-CLI log command is available)

Open the last ~50 lines. You're looking for:

[16-Oct-2026 14:22:01 UTC] PHP Fatal error: Uncaught TypeError:
Cannot access offset of type string on string in
/home/user/public_html/wp-content/plugins/some-plugin/includes/class-handler.php:142

[16-Oct-2026 14:22:01 UTC] PHP Stack trace:
[16-Oct-2026 14:22:01 UTC] PHP   1. {main}() /index.php:0
[16-Oct-2026 14:22:01 UTC] PHP   2. do_action() /wp-includes/plugin.php:517
[16-Oct-2026 14:22:01 UTC] PHP   3. some_plugin_init() /wp-content/plugins/some-plugin/hooks.php:88
[16-Oct-2026 14:22:01 UTC] PHP   4. Some_Plugin_Handler::render() /wp-content/plugins/some-plugin/class-handler.php:142

Read the stack trace

The stack trace tells you exactly which file threw the error and which files called into it.

Reading order:

1. Top frame — the fatal line and file (the actual crash site)
2. Bottom frame — the entry point (usually index.php or wp-blog-header.php)
3. Middle frames — the call chain (this is where the plugin interaction lives)

Look for plugin paths in the middle frames:

wp-content/plugins/plugin-a/...   ← Plugin A involved
wp-content/plugins/plugin-b/...   ← Plugin B involved

If two different plugins appear in the stack trace, you've found your conflict. Plugin A called a function that Plugin B was also hooking into, and one of them modified something the other expected.

Check hook conflicts with Query Monitor

If the log doesn't reveal the culprit, Query Monitor shows exactly which plugin is doing what on each page.

Install and activate Query Monitor. It adds a "Query Monitor" menu to the admin bar with these tabs:

• Queries — every database query with the plugin that ran it
• Hooks — every WordPress hook fired, sorted by priority
• Scripts & Styles — what CSS/JS loads on this page
• HTTP API — outgoing external requests

Look for these patterns in the Hooks tab:

• Two plugins hooking the same action at the same priority
• A plugin removing another plugin's hook (search for remove_action)
• Duplicate function names (search for function_exists patterns)

Bisect the plugin list

When you still don't know which plugin is causing the issue, bisect. Faster than testing one at a time.

The bisect method:

1. List all active plugins in a spreadsheet
2. Deactivate the bottom half
3. Reproduce the error
4. If the error is gone, it's in the bottom half — restore, deactivate the other half
5. If the error is still there, it's in the top half — keep the bottom active, deactivate the top half
6. Repeat with the smaller half

Bisect math:

32 plugins → 5 rounds of testing
16 plugins → 4 rounds
8 plugins  → 3 rounds
4 plugins  → 2 rounds

# vs testing one at a time = up to 32 tests

Resolve and prevent

Once you've identified the culprit plugin, here's what to do:

If both plugins are required:

• Check if there's a newer version of either plugin. Conflicts are often fixed in point releases.
• Search the plugin support forums on wordpress.org for the exact error
• Report the conflict with a stack trace — the plugin author may not know
• Check the plugin's GitHub issues if it has one

If you can replace one:

• Find an alternative plugin that does the same thing without the conflict
• Or write a small custom function — often faster than dealing with a bloated plugin

Prevent future conflicts:

• Test plugin updates on staging first
• Check the plugin's "Tested up to" version before updating
• Keep fewer plugins active overall
• Read changelogs before updating