WooCommerce 10.7 HPOS Sync on Read Fix

The Problem

WooCommerce 10.7 made one HPOS transition detail impossible to ignore: sync on read is now disabled by default.

If your store still has custom code, legacy plugins, or reporting tools that write order data to the posts tables and expect HPOS to pull that data back in on the next read, that safety net is gone unless you explicitly turn it back on.

This is not a theoretical change. The official WooCommerce advisory spells out exactly who gets hit: stores with HPOS active, compatibility mode enabled, and code that still writes through wp_update_post(), update_post_meta(), or direct SQL instead of the WooCommerce CRUD layer.

That is why I would not treat this as just another maintenance release note. It is a migration deadline.

If you still have older query code in the stack, read my WooCommerce HPOS custom queries fix next. Sync on read problems and posts-table query problems tend to show up on the same stores.

Why It Happens

Sync on read always existed as a temporary bridge.

With HPOS, the order tables are the source of truth. Compatibility mode keeps a secondary copy in the posts tables to help older code keep limping along. Sync on read added one more behavior on top: if something updated the posts copy directly and that timestamp looked newer, WooCommerce could pull the change back into HPOS during a read.

That sounds convenient, but it is also risky. The WooCommerce team called out the main reason for the change: pulling stale or unexpected data back into HPOS can revert statuses or overwrite newer order data.

In other words, sync on read was helping outdated integrations survive, but it was also making the actual source of truth less reliable.

The Fix

The right fix is not to keep reviving sync on read forever. It is to stop writing orders through generic WordPress APIs.

Bad pattern

// Legacy pattern that assumes posts/postmeta are writable order storage
wp_update_post(
    [
        'ID'          => $order_id,
        'post_status' => 'wc-completed',
    ]
);

update_post_meta( $order_id, '_tracking_number', $tracking_number );

HPOS-safe pattern

$order = wc_get_order( $order_id );

if ( ! $order ) {
    return;
}

$order->set_status( 'completed' );
$order->update_meta_data( '_tracking_number', $tracking_number );
$order->save();

That is the change I want everywhere: status updates, metadata, exports, background jobs, ERP syncs, webhook retries, all of it.

What To Do Right Now

I use this order:

1. Audit every write path

Search the codebase for:

• wp_update_post(
• update_post_meta(
• direct SQL touching wp_posts or wp_postmeta
• Action Scheduler callbacks that mutate orders

Those are the paths most likely to break quietly after the upgrade.

2. Re-enable sync on read only as a temporary bridge

WooCommerce gave developers a filter for that:

add_filter( 'woocommerce_hpos_enable_sync_on_read', '__return_true' );

That can buy you time after the upgrade, but I would treat it as a short-term compatibility patch, not the end state.

3. Remove posts-table assumptions from custom integrations

If a shipping sync, warehouse connector, or internal report still treats orders like regular posts, fix that now. The posts copy was never supposed to be the long-term write target.

4. Consider disabling compatibility mode when the store is ready

If everything is HPOS-safe already, disabling compatibility mode removes unnecessary synchronization work and usually leaves the store in a cleaner, faster state.

One Client Pattern I Keep Seeing

The nastiest version of this bug is not a fatal error. It is silent drift.

The ERP integration updates a status through old code. The admin sees something different inside WooCommerce. The customer email workflow reads the HPOS state. The report exporter reads the posts copy.

Now nobody trusts the data, and the store owner thinks HPOS is unstable when the real problem is that two storage models are still fighting each other.

That is why I like this WooCommerce change. It is stricter, but it forces the right repair instead of hiding the wrong architecture.

The official advisory is here: HPOS sync on read to be disabled by default in WooCommerce 10.7. Read that first, then audit your own order writes.

If you want a safe HPOS migration without data drift, reporting breakage, or plugin guesswork, check my services. I also cover the broader store-speed side in this WordPress performance guide.