HPOS verified in CI, not just declared in the header

HPOS — High-Performance Order Storage — moves WooCommerce orders into dedicated tables instead of the WordPress posts table. A plugin can declare HPOS compatibility in its header while its code still reads orders as posts, so the declaration and the behaviour can disagree. Asteris Cart enforces compatibility in continuous integration: a build rule fails if legacy order-meta calls appear against order IDs. The compatibility is checked in code on every build, rather than asserted once in a header and trusted thereafter.

What HPOS is, briefly

WooCommerce historically stored orders in the same wp_posts table as blog posts and pages. High-Performance Order Storage moves orders into dedicated tables built for the job, which scales far better for busy stores. WooCommerce has been steering the ecosystem toward HPOS for some time.

The catch is the long tail of plugins. Any plugin that reads or writes orders using the old post-based functions — get_post_meta() on an order ID, for instance — can misbehave once a store turns HPOS on. The order data is no longer where those functions expect it.

The gap between declaring and doing

WooCommerce lets a plugin declare HPOS compatibility in its header. That declaration is a promise, not a proof. A plugin can carry the compatibility flag while parts of its code still call the legacy functions, because nothing forces the two to agree. The flag says “compatible”; the code says otherwise; the store owner finds out when orders behave strangely after enabling HPOS.

This is not hypothetical for the category. Funnel and checkout plugins with large, mature codebases carry years of order-handling code, and migrating all of it to HPOS-safe calls is ongoing work. Some competitors have open HPOS migration items on their public roadmaps [VERIFY: link their roadmaps/issues at publish] — which is honest of them, and exactly the gap this essay is about: a header flag does not mean the migration is finished.

How Asteris Cart enforces it

Asteris Cart treats HPOS compatibility as something to test, not declare:

Code receipt: continuous-integration configuration (plugin-wide rule) [CODE SNIPPET — CC to insert the CI rule / grep config from the repo at build; must match shipping v1.0.]

Why this matters to a store owner

You do not read other people’s source code before installing a plugin, and you should not have to. But HPOS is the one area where a quiet incompatibility shows up as real damage — orders that do not save metadata correctly, reports that go wrong, integrations that misfire. A plugin that fails its own build on a legacy order call is making a verifiable promise: the incompatibility cannot ship, because the build will not let it.

How this fits

HPOS-in-CI is a plugin-wide property rather than a single module, and it underpins the honest-claims positioning across the comparison pages. Asteris Cart vs CartFlows → · Asteris Cart vs FunnelKit → · See pricing →

FAQ

What is HPOS in WooCommerce? High-Performance Order Storage moves orders into dedicated tables instead of the posts table. Plugins that still read orders as posts can misbehave once it is on.

Does declaring HPOS compatibility make a plugin safe? No. A header can declare compatibility while the code still calls legacy order-meta functions.

How does Asteris Cart verify it? A continuous-integration rule fails the build if legacy order-meta calls appear against order IDs.

Sources