WordPress plugin conflict logs: where errors hide and how to read them

When a WordPress plugin breaks your site, you usually get a white screen, a cryptic error message, or—worse—nothing at all. The checkout button stops working. The contact form silently drops submissions. A scheduled post never publishes.

Most solo operators disable plugins one by one until something works again. That approach finds the culprit, but it doesn’t tell you why the conflict happened or whether it’ll break again after the next update.

WordPress writes conflict and error data to several places. If you know where to look and what patterns matter, you can diagnose plugin conflicts in minutes instead of hours, and you’ll catch silent failures before readers do.

Where WordPress writes plugin error logs

WordPress doesn’t enable debug logging by default. When a plugin conflict occurs, the error might surface in your browser, but more often it gets written to a server log that most operators never open.

There are three places to check:

• debug.log in /wp-content/ — only appears if WP_DEBUG_LOG is enabled in wp-config.php. This is the primary conflict log. It captures PHP errors, warnings, notices, and deprecated function calls. Most plugin conflicts show up here first.
• Server error logs — your hosting provider writes PHP fatal errors and web server errors here. Location varies: cPanel puts them in /logs/, managed WordPress hosts expose them in dashboards. BigScoots surfaces them in the control panel under “Error Log.” Fatal errors that kill the site bypass debug.log and land here.
• Browser console — JavaScript conflicts don’t write to PHP logs. Open your browser’s developer tools (F12) and check the Console tab. A missing .js file, a jQuery version mismatch, or a React component error will show here, not in WordPress logs.

If WP_DEBUG_LOG isn’t enabled, add this to wp-config.php 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 debug.log without displaying them to site visitors. Leave it on for a week. If a conflict exists, it’ll log.

What plugin conflict entries actually look like

A typical conflict log entry looks like this:

[23-Jul-2026 14:32:18 UTC] PHP Fatal error: Uncaught Error: Call to undefined function wp_mail() in /home/user/public_html/wp-content/plugins/custom-contact-form/contact.php:47

Here’s what matters:

• Timestamp — when the error fired. Cross-reference this with when you updated a plugin or when a visitor reported a problem.
• Error type — Fatal errors break execution. Warnings and notices don’t stop the site, but they signal a conflict that might escalate after the next plugin update.
• File path — tells you which plugin triggered the error. In this case, custom-contact-form is the culprit.
• Function name — wp_mail() is undefined, which usually means the plugin loaded too early, before WordPress core functions were available.

Not all conflicts are this clear. Sometimes you’ll see dozens of deprecation notices from a single plugin. That’s noise. Look for fatal errors and repeated warnings tied to the same plugin and function. Those are the patterns that predict breakage.

Tracing breaking changes after plugin updates

If your site breaks immediately after a plugin update, the log will show the new error. But if the conflict is silent—forms stop submitting, emails stop sending, scheduled posts don’t publish—you need to correlate log timestamps with plugin update times.

WordPress logs plugin updates in the database, but doesn’t surface them in a readable timeline. If you suspect a recent update caused a conflict, check debug.log for the first error timestamp, then compare it to your plugin update history in the WordPress admin under Dashboard → Updates. That page shows recent updates, but only for the last few days.

For longer history, query the database directly or use a plugin like WP Activity Log, which tracks every plugin activation, update, and deactivation with timestamps. Cross-reference the log with your debug.log entries. If the first error appeared within an hour of a plugin update, that’s your conflict source.

What to do once you’ve identified the conflict

Once you know which plugin is logging errors, you have three options:

• Roll back the plugin — most managed WordPress hosts offer one-click plugin rollback. If yours doesn’t, download the previous version from the WordPress plugin repository’s “Advanced View” tab and upload it manually. This buys time while you wait for a patch.
• Disable the conflicting feature — some plugins let you toggle features. If the conflict stems from a feature you don’t use, turn it off instead of disabling the entire plugin.
• Contact the developer — if the plugin is actively maintained, report the conflict with your log excerpt, WordPress version, PHP version, and conflicting plugin name. Most developers fix conflicts within a few days if you give them clean reproduction steps.

Don’t leave WP_DEBUG enabled indefinitely on a live site. Once you’ve identified and resolved the conflict, set WP_DEBUG and WP_DEBUG_LOG back to false. Debug logs grow large and can expose server paths to anyone who guesses the debug.log URL.

One non-obvious tip: check for JavaScript conflicts separately

PHP logs won’t capture JavaScript conflicts. If a plugin breaks your site’s front-end interactivity—buttons stop responding, modals don’t open, checkout forms freeze—open your browser console and look for red error messages. Common culprits: two plugins loading different versions of jQuery, or a plugin enqueueing a script that depends on another script that didn’t load.

To confirm a JavaScript conflict, disable plugins one by one while keeping the browser console open. When the red errors disappear, you’ve found the plugin responsible.

Want more WordPress infrastructure breakdowns like this? Reply with the hosting or plugin behaviour you want explained next—we read every response and route the best questions into future issues.