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.
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.
Four things to notice:
- 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
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.
Cross-connector note: plugin compatibility is a WooCommerce / WordPress-specific concern. There is no equivalent on the hosted SaaS platforms (Shopify, BigCommerce) where the vendor controls the platform version, so no cross-platform reconciliation applies.
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.