Plugin Conflict Detection

The idea

When checkout starts failing, the cause is often a plugin that was just updated. PRO records every plugin activation, deactivation and update that WordPress reports (it ignores Commerce Health itself), then checks what happened to your checkout around that change.

How it decides

Once a change is at least 2 hours old, PRO compares the 2 hours before it with the 2 hours after. It raises an issue if either of these is true:

• A JavaScript error that had never been seen before started appearing on the checkout page.
• Payment failures increased by at least 2 compared with the 2 hours before.

The issue names the plugin and what changed. Most plugin updates raise nothing at all. Whether it emails you depends on the Issue Emails setting. These values are fixed in this version.

Closing the issue

Each change is judged once, so a flagged issue isn’t closed automatically. After you investigate (roll the plugin back, or decide it’s unrelated), open Commerce Health → Issues and use Mark as resolved. This is the only kind of issue that can be marked resolved by hand.

What it cannot see

• Changes made outside WordPress. A plugin replaced over FTP or deployed with Git doesn’t trigger WordPress’s activation or update events, so it is not recorded.
• Theme and WordPress core updates, which are not recorded, only plugins.
• Problems that start more than 2 hours later, or that show up on a page other than checkout.
• Quiet stores. With very few checkouts there may be no failures to compare, so a real conflict can go unflagged.

Example. You update a shipping plugin at 10:00. At 11:30 a new error starts appearing on checkout, and nothing like it happened in the two hours before. PRO raises a Medium issue naming the plugin. If you updated the same plugin by uploading its files over FTP, PRO would have recorded nothing.