Most WordPress plugin conflicts don’t throw a visible error. The site looks fine. The dashboard loads. But form submissions stop working, scheduled posts don’t publish, or your automation plugin silently skips every third webhook.
The conflict is logged—WordPress writes it somewhere—but most operators don’t know where to look or what the log entries actually mean.
Here’s how to find conflict logs, read them, and figure out which plugin is causing the problem without disabling everything one by one.
Where WordPress writes plugin conflict data
WordPress doesn’t have a single “conflict log.” It writes errors to three places depending on your hosting setup:
- debug.log — lives in
/wp-content/ifWP_DEBUG_LOGis enabled in wp-config.php - PHP error log — location varies by host; often
/var/log/or accessible via cPanel - Server error log — Apache or Nginx writes fatal errors here; usually needs SSH or hosting dashboard access
If you’re on managed WordPress hosting like BigScoots, Kinsta, or Flywheel, the dashboard usually surfaces recent errors without file access. Look for “Error Logs” or “Site Health” in the admin panel.
To enable debug logging manually, add this to your wp-config.php file just above the line that says “That’s all, stop editing”:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
This writes errors to /wp-content/debug.log without showing them to visitors. Leave it on for 24 hours, then check the file.
What plugin conflict entries look like
A real conflict log entry looks like this:
[21-Sep-2026 14:32:18 UTC] PHP Fatal error: Cannot redeclare class WP_REST_Controller in /wp-content/plugins/plugin-a/includes/rest-api.php on line 12
The key patterns to search for:
- “Cannot redeclare” — two plugins define the same function or class
- “Call to undefined function” — one plugin expects another to load first and it didn’t
- “Maximum execution time exceeded” — infinite loop between two plugins
- “Headers already sent” — one plugin outputs content before another tries to set cookies or redirects
The file path tells you which plugin triggered the error. If you see /wp-content/plugins/plugin-a/ and /wp-content/plugins/plugin-b/ in consecutive lines with the same timestamp, that’s your conflict pair.
Reading logs without file access
If your host doesn’t offer file access and you don’t have SSH, install the free “WP Log Viewer” or “Error Log Monitor” plugin. Both surface debug.log contents in the WordPress admin.
Once installed, go to Tools → Error Log (the menu label varies). You’ll see the most recent entries at the top. Use your browser’s find function (Ctrl+F or Cmd+F) to search for the patterns above.
Most conflicts happen during these events:
- Plugin activation or deactivation
- WordPress or PHP version updates
- Cron jobs running in the background
- Form submissions or checkout processes
Filter the log by timestamp to isolate when the problem started. If a user reported “checkout stopped working on Tuesday,” look at entries from Tuesday morning onward.
One non-obvious detail: load order matters
WordPress loads plugins alphabetically by folder name. If Plugin A expects Plugin B to register a custom post type first, but “plugin-a” loads before “plugin-b,” the conflict won’t show up until a specific feature is triggered.
The log will say Call to undefined function register_cpt_from_plugin_b() even though both plugins are active and working independently.
The fix: some plugins offer a “load priority” setting in their options. If not, you can rename the plugin folder (via FTP or file manager) to change load order—prefix the one that needs to load first with 0- or aaa-. This is hacky but works when the plugin developer won’t fix it.
Before you do that, check if one of the plugins has a dependency declaration in its header. Open the main plugin file and look for Requires Plugins: in the comment block. If it’s there, WordPress 6.5+ enforces load order automatically. If it’s missing, the developer didn’t specify dependencies—which is why the conflict exists.
When to stop reading logs and just test
If the log shows 200+ lines of the same error repeating, don’t parse every entry. The conflict is clear. Disable the plugin named in the file path, clear the log, and see if the error stops.
If two plugins both appear in the log but you can’t tell which one is at fault, disable the one updated most recently. Plugin updates often introduce conflicts with older code that hasn’t been patched in years.
Keep a staging site or local copy running if you manage multiple WordPress installs. Test plugin updates there first, enable debug logging, and scan for conflicts before pushing to production. It’s faster than debugging live.
Hit reply if you’ve found a plugin conflict pattern that logs don’t surface. Some conflicts only show up in browser console errors or network request failures—we’ll cover those in a future piece if there’s enough interest.