Cross-references active WP plugins against WooCommerce + WP core version compatibility matrix. Surfaces conflict-likely plugins before they break checkout.
At a glance
A live count of active plugins whose declared compatibility ceiling sits below the WooCommerce or WordPress core version your store is actually running. WooCommerce is a plugin-of-plugins world: a single gateway, subscriptions, or page-builder plugin that has not been tested against your WC version is the most common cause of a silent checkout break. This card reads your active plugin list, compares each plugin’s declared “Tested up to” and “WC tested up to” headers against your live WC and WP core versions, and surfaces the ones at risk.
| What it counts | The number of active plugins whose declared maximum tested version (WP “Tested up to” header, or the WooCommerce WC tested up to plugin header) is older than the WooCommerce or WordPress core version currently installed. Inactive plugins are not counted. |
| REST API endpoint | WordPress does not expose a fully versioned plugin list through the WooCommerce wc/v3 REST namespace. The active plugin set and each plugin’s version headers are read from the site’s plugin list (the same data the WP core update_plugins transient and the WooCommerce Status System Report expose), then cross-referenced against the live woocommerce and wp_version values. |
| Compatibility matrix | Each plugin ships a Requires at least, Tested up to, and (for Woo extensions) a WC requires at least / WC tested up to header. The card compares these declared ranges against your running WC and WP core version. A plugin tested only up to WC 8.2 on a store running WC 9.1 is flagged as conflict-likely. |
| What “conflict-likely” means | A flag is a risk signal, not a confirmed break. A plugin author simply may not have updated their “tested up to” header yet. The value is in catching the plugin that genuinely has not been tested against your stack before it surfaces as a checkout failure. |
| Self-hosted vs managed-Woo | Self-hosted stores carry the highest risk: merchants install plugins freely and core auto-updates can outrun plugin testing. Managed-Woo hosts (Woo.com Cloud, WP Engine, Pressable, Kinsta) often stage core updates and run their own compatibility checks, but the plugin set is still merchant-controlled. WordPress.com Business and Commerce plans restrict the plugin catalogue, which lowers but does not remove the risk. |
| Time window | RT (real-time, reflects the live plugin list at last sync) |
| Alert trigger | >0 incompatible plugins detected, driven by sentiment_key: wc_plugin_compatibility_audit |
| Roles | owner, engineering |
Calculation
Calculated automatically from your WooCommerce data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A self-hosted WooCommerce store running WC core 9.1 and WordPress core 6.5, snapshot taken 14 Jun 26. The store has 41 active plugins. The audit cross-references each plugin’s declared compatibility ceiling against the live WC 9.1 / WP 6.5 stack.| Plugin | Declared WC tested up to | Declared WP tested up to | Flagged conflict-likely? |
|---|---|---|---|
| WooCommerce Stripe Gateway | 9.1 | 6.5 | No |
| WooCommerce Subscriptions | 8.4 | 6.4 | Yes |
| Custom B2B Pricing (in-house plugin) | (no header) | 6.2 | Yes |
| Page-builder (Elementor) | n/a | 6.5 | No |
| Points and Rewards | 8.9 | 6.5 | Yes |
| Remaining 36 active plugins | 9.0 to 9.1 | 6.4 to 6.5 | No |
| Plugin Compatibility Audit (this card) | 3 flagged |
- Subscriptions is the highest-risk flag. WooCommerce Subscriptions overrides the checkout and renewal-order flow. Tested only up to WC 8.4 on a WC 9.1 store, it is the kind of plugin that can break recurring billing silently while one-off checkout keeps working. This is exactly the case the card exists to catch before it surfaces in Failed Orders (Last 24h).
- The in-house B2B plugin has no
WC tested up toheader at all. Custom plugins rarely declare compatibility headers, so the audit cannot confirm they are safe and flags them conservatively. This is a true positive in spirit: an untested in-house plugin against a fresh core version is genuine risk. - A flag is not a confirmed break. Points and Rewards tested to WC 8.9 may run perfectly on 9.1; the author simply has not bumped the header. Treat the flag as “verify before the next core update”, not “broken now”. The right next step is a staging-site checkout test.
- The count is real-time, not windowed. Unlike revenue cards, this reads the live plugin list at last sync. The moment a merchant activates an untested plugin or core auto-updates past a plugin’s ceiling, the count moves. Pair it with Plugin Updates (Last 24h) to know whether a recent change caused the flag.
Sibling cards merchants should reference together
| Card | Why pair it with Plugin Compatibility Audit |
|---|---|
| WC Plugin Updates (Last 24h) | Tells you whether a recent update is the reason a plugin became compatible or incompatible. A new flag right after an update is the clearest regression signal. |
| WC Plugins Out of Date | Out-of-date plugins are the most likely to fall behind the core compatibility ceiling. Update them and the audit count usually drops. |
| WC Plugin Security Patch Breach | A plugin that is both incompatible and missing a security patch is a top-priority remediation. |
| WC Active Plugin Count | The denominator. A high active-plugin count raises the odds that at least one lags the core compatibility matrix. |
| WC WooCommerce Core Version | The WC version this audit compares against. A core bump can flip several plugins to conflict-likely at once. |
| WC WordPress Core Version | The WP version side of the matrix. A WP core auto-update can outrun plugin “tested up to” headers. |
| WC Failed Orders (Last 24h) | The downstream symptom. When an incompatible gateway or checkout plugin breaks, failed orders are where it shows up first. |
Reconciling against WooCommerce
Where to look in WordPress / WooCommerce Admin: WP Admin → WooCommerce → Status → System Status lists the active plugins, their versions, and any “WooCommerce out of date” warnings WC raises itself. This is the closest first-party view to this card. Other WP Admin views that show pieces of the same picture:- WP Admin → Plugins: the active plugin list with each plugin’s version and, on the Woo extensions screen, the “WC tested up to” badge. This is the raw input the audit reads.
- WP Admin → WooCommerce → Status → Tools: utilities for clearing caches and regenerating data, useful when a flag persists after you have updated a plugin.
- WP Admin → Dashboard → Updates: shows available plugin and core updates. A plugin with a pending update is often the one lagging the compatibility matrix.
| Reason | Direction of divergence |
|---|---|
| Self-hosted sync lag. The card reflects the plugin list at the last successful sync. If a merchant has just updated or deactivated a plugin and the host was slow to respond, the card may be up to a sync cycle behind the live WP Admin view. | Ours temporarily higher or lower; self-resolves at next sync |
| Plugin header accuracy. The audit relies on the plugin author’s declared “tested up to” headers. WC’s own Status report uses the same headers, so the two should agree, but a plugin that declares no header is treated conservatively here and may not raise a warning in WP Admin. | Ours may flag plugins WC Status does not |
| Active vs installed. This card counts active plugins only. WP Admin → Plugins lists installed-but-inactive plugins too; those are not a runtime risk and are excluded here. | Ours lower than the full installed list |
| HPOS vs legacy storage. High-Performance Order Storage changes which plugins touch the orders table. A plugin not declared HPOS-compatible is a real conflict risk on an HPOS store even if its version headers look current; the audit surfaces version mismatch, so cross-check HPOS compatibility in WooCommerce → Status. | Either; investigate per-merchant |
Known limitations / merchant FAQs
A plugin is flagged but my checkout works fine, is this a false alarm? Possibly. A flag means the plugin’s declared “tested up to” header is older than your live WC or WP version, not that it is confirmed broken. Many authors lag their headers behind reality. Treat a flag as “test this before the next core update” rather than “broken now”. Run a staging-site checkout test for the flagged plugin; if it passes, you can wait for the author to bump the header. Why is my in-house custom plugin always flagged? Custom and in-house plugins rarely declare theTested up to or WC tested up to headers. With no header to read, the audit cannot confirm compatibility and flags conservatively. Add the headers to your plugin’s main file (Tested up to: and WC tested up to:) to clear the flag once you have verified it against your current stack.
Does this card check HPOS (High-Performance Order Storage) compatibility?
The version-header audit catches plugins that lag your WC core version, which is the most common risk. HPOS compatibility is a separate declaration. If you have enabled HPOS, also check WooCommerce → Status → the HPOS compatibility panel, because a plugin can have current version headers yet still not be HPOS-aware.
Why did the count jump after a WordPress or WooCommerce core update?
A core update moves your live WC or WP version forward, which can push several plugins past their declared compatibility ceiling at once. This is expected. It is also exactly why the card pairs with Plugin Updates (Last 24h): a spike in the audit right after a core bump tells you which plugins to verify first.
Does it count inactive plugins?
No. Only active plugins are a runtime risk, so deactivated plugins are excluded even if their versions lag. If you want to reduce attack surface and noise, delete inactive plugins rather than leaving them installed.
How current is the data?
This is a real-time card: it reflects the active plugin list at the last successful sync (typically hourly for self-hosted stores). If you have just remediated a flag, force a manual refresh from the dashboard or wait for the next sync to see the count update.