WooCommerce HPOS Is Mandatory — Does Your Tracking Plugin Still Work?

Does my WooCommerce tracking plugin work with HPOS?

Check the plugin’s listing on WordPress.org for HPOS compatibility declarations — plugins using get_post_meta() for order data instead of WooCommerce’s $order->get_meta() API are HPOS-incompatible and will silently fail (WooCommerce documentation, 2026). HPOS compatibility is now required for new plugin listings, so any plugin submitted after the mandate should work — but older plugins may not.

The “silently” part is what makes this dangerous. An HPOS-incompatible tracking plugin doesn’t crash your store or throw an error. It simply returns empty values when it tries to read order data from the old wp_postmeta table. Your store keeps processing orders. Your tracking plugin keeps running. But the conversion events it sends to GA4 and Meta contain null values where order totals, product IDs, and transaction IDs should be.

The result is invisible data loss. Your GA4 shows purchase events with $0 revenue. Your Meta CAPI sends conversion events with no product data. Your attribution and ROAS calculations are silently wrong — and nothing in your dashboard tells you.

HPOS-incompatible tracking plugins don’t crash — they silently return empty order data, sending $0 revenue events to GA4 and Meta without any visible error (WooCommerce documentation, 2026).

What breaks when a tracking plugin uses get_post_meta() under HPOS?

The plugin returns null or empty values for order fields because HPOS stores order data in dedicated database tables, not in the wp_postmeta table that get_post_meta() queries (WordPress.org / Shipment Tracking DDT, 2026). Plugins using get_post_meta() instead of $order->get_meta() are HPOS-incompatible — the function call succeeds but returns nothing useful.

Under legacy storage, WooCommerce stored every order field — total, billing email, line items — as rows in wp_postmeta. A tracking plugin could call get_post_meta($order_id, ’_order_total’, true) and get the order total. Under HPOS, that same call returns an empty string because the order total now lives in wp_wc_orders.

The Shipment Tracking DDT plugin documented this exact fix in its changelog: it migrated from get_post_meta() to the WooCommerce CRUD API to restore HPOS compatibility. Any tracking plugin that hasn’t made this same migration is broken under HPOS — it just doesn’t tell you.

Related: 5 GA4 Volume Thresholds WooCommerce Stores Fail

How do I audit my tracking plugins for HPOS compatibility?

Check each plugin’s WordPress.org listing for HPOS compatibility badges, search the plugin’s changelog for HPOS migration mentions, and test on a staging site with HPOS enabled by completing a purchase and verifying the data reaches GA4 (WooCommerce documentation, 2026). The three-step audit takes under an hour and catches silent failures before they affect production data.

Step one is the quick filter: does the plugin’s WordPress.org page declare HPOS compatibility? Multiple tracking plugins now explicitly declare HPOS compatibility in 2026 — if yours doesn’t, that’s a red flag, not a guarantee of failure, but a signal to test.

Step two is the changelog scan: search for “HPOS”, “Custom Order Tables”, or “OrderUtil” in the plugin’s recent changelog. A migration entry means the developer addressed it. No mention means they either didn’t need to (already using the CRUD API) or haven’t done it yet.

Step three is the definitive test: enable HPOS on a staging site, complete a test purchase, and check GA4 Realtime for the purchase event with correct revenue and transaction ID. If the revenue shows $0 or the event is missing, the plugin is broken under HPOS.

Which WooCommerce tracking plugins have confirmed HPOS support in 2026?

Track Combo, FirstTrack, and Halfborg all declare HPOS and Checkout Blocks compatibility on their WordPress.org listings (WordPress.org, 2026). These plugins use WooCommerce’s data store abstraction rather than direct post meta queries, so they work correctly regardless of whether the store runs legacy storage or HPOS.

The dual declaration — HPOS and Checkout Blocks — matters because both are part of WooCommerce’s modernisation path. A plugin that supports HPOS but not Checkout Blocks still breaks on the modern checkout. A plugin that supports both is aligned with where WooCommerce is heading.

For stores evaluating tracking plugins in 2026, HPOS compatibility should be a requirement, not a nice-to-have. Any tracking plugin that doesn’t declare HPOS support in 2026 is either unmaintained or hasn’t been tested against the current WooCommerce architecture — neither is a good sign for a plugin handling your conversion data.

Track Combo, FirstTrack, and Halfborg declare both HPOS and Checkout Blocks compatibility — ensuring they work with WooCommerce’s current and future architecture (WordPress.org, 2026).

When did WooCommerce HPOS become mandatory for new plugins?

WooCommerce 10.0.4 shipped with full HPOS support in July 2025 (Wikipedia / WooCommerce, 2025), and HPOS compatibility is now required for new plugin listings on WordPress.org. Existing plugins haven’t been removed, but new submissions must demonstrate HPOS support to be listed.

The timeline matters because it determines how many plugins in the wild are potentially affected. Plugins last updated before mid-2025 have had over a year to migrate. Plugins actively maintained in 2026 should have addressed HPOS by now. The risk zone is plugins that were last updated in 2024 or earlier — they predate the mandate and are likely still using legacy data access patterns.

WooCommerce is used by 9.2% of all websites (W3Techs, 2024). The HPOS migration affects every one of those sites that upgrades — and every tracking plugin installed on them. The scale of the compatibility question is enormous.

Related: 6 WooCommerce Server-Side Tracking Plugins Without GTM

What is the difference between get_post_meta() and $order->get_meta() for tracking?

get_post_meta() reads from the legacy wp_postmeta table which HPOS no longer uses for orders. $order->get_meta() uses WooCommerce’s data store abstraction that works with both legacy and HPOS storage (WooCommerce documentation, 2026). For tracking plugins, the difference is between working everywhere and working only on legacy stores.

The technical migration is straightforward for developers: replace get_post_meta($order_id, ’_order_total’, true) with $order->get_total() or $order->get_meta(’_custom_field’). The WooCommerce CRUD API handles the storage abstraction internally — it reads from wp_postmeta on legacy stores and from wp_wc_orders_meta on HPOS stores.

For store owners, the distinction is a compatibility test: if your tracking plugin’s code contains get_post_meta calls for order data (check the source or ask the developer), it’s HPOS-incompatible until migrated.

Can I run HPOS and still use tracking plugins that are not compatible?

WooCommerce offers a compatibility mode that maintains both storage systems simultaneously, but this doubles write operations and is a transitional tool, not a permanent solution. Incompatible plugins need to be replaced (WooCommerce documentation, 2026).

Compatibility mode writes every order to both the legacy wp_postmeta table and the new HPOS tables. This means get_post_meta() still returns data, so incompatible plugins keep working. But you’re paying for it with doubled database writes on every order — which affects checkout performance, especially under load.

The longer you run compatibility mode, the harder the eventual migration becomes. Turn it off, and every incompatible plugin breaks simultaneously. Keep it on, and you’re maintaining two parallel storage systems indefinitely. The exit is replacing the incompatible plugins, not extending the compatibility window.

How does HPOS affect server-side tracking for WooCommerce?

Server-side tracking that hooks into WooCommerce actions and uses $order->get_meta() or the CRUD API works correctly under HPOS. Tracking that reads order data directly from wp_postmeta via SQL or get_post_meta() breaks silently (WooCommerce documentation, 2026).

The distinction is architectural. Server-side tracking that follows WooCommerce’s recommended patterns — hooking into woocommerce_payment_complete and reading order data through the order object — is HPOS-compatible by design. The order object abstracts the storage layer. The tracking code never needs to know whether the data lives in wp_postmeta or wp_wc_orders.

HPOS actually reinforces the case for server-side tracking. Client-side tracking that reads order data from the thank-you page DOM was already fragile. HPOS doesn’t change the DOM, but it adds another failure mode for plugins that bypass WooCommerce’s API. Server-side tracking that uses the CRUD API is immune to both problems — it reads data the right way, from the right place, regardless of storage engine.

Key Takeaways

• HPOS is mandatory for new plugins: WooCommerce now requires HPOS compatibility for new plugin listings on WordPress.org.
• get_post_meta() breaks under HPOS: Tracking plugins using this legacy function return empty values for order data — silently.
• Three plugins confirmed HPOS-compatible: Track Combo, FirstTrack, and Halfborg declare both HPOS and Checkout Blocks support.
• Audit in under an hour: Check WordPress.org badges, scan changelogs for HPOS mentions, and test on staging with a real purchase.
• Compatibility mode is not a fix: It doubles database writes and delays the migration — replace incompatible plugins instead.
• 9.2% of all websites affected: Every WooCommerce site upgrading to HPOS needs to verify its tracking stack.
• Server-side tracking via CRUD API is safe: Tracking that hooks into WooCommerce actions and reads through $order works under both storage engines.

References

1. WooCommerce — Official Documentation: HPOS Migration (2026)
2. WordPress.org — FirstTrack Plugin: HPOS Compatible (2026)
3. WordPress.org — Shipment Tracking DDT: HPOS Fix Changelog (2026)