From April 14, WooCommerce 10.7 ships with HPOS sync on read disabled by default. If you have years of custom code that treats orders like ordinary WordPress posts, that code is about to lose the thing that has been quietly covering for it. Direct database updates will no longer find their way back into the order tables.
I have been fighting with High-Performance Order Storage (HPOS) since its early betas, and this was always going to happen. Stores still leaning on legacy hooks or generic post meta functions will start seeing data integrity problems unless they refactor.
What HPOS sync on read actually does
HPOS shipped with a “Compatibility Mode” that syncs data between the new custom tables and the old wp_posts table. HPOS sync on read, sometimes called on-the-fly synchronization, sat on top of that as extra insurance. On every read it compared the timestamps of both records, and if the legacy wp_posts row was newer, WooCommerce copied that data back into the authoritative HPOS tables.
The mechanism was only ever a bridge, meant to give developers time to adopt the WooCommerce CRUD (Create, Read, Update, Delete) API. Leaving it open forever invites race conditions and the sort of read overhead that cancels out the reason HPOS exists.
Why turning it off is the right call
Reliability is the reason. On a busy store, sync on read can revert an order status or let stale data overwrite a legitimate update. Drop the on-the-fly check and the HPOS tables stay authoritative, without paying for a timestamp comparison on every read.
Are you affected?
You are affected if your site uses custom code or older plugins that touch order data through generic WordPress functions like update_post_meta or through raw SQL. Here is the naive version that stops working:
// THE WRONG WAY: This will no longer sync to HPOS on the next read.
update_post_meta( $order_id, '_billing_phone', '555-0123' );
wp_update_post( array( 'ID' => $order_id, 'post_status' => 'wc-completed' ) );Keep using those functions and your changes will sit in the legacy wp_posts table, invisible to the HPOS engine that runs checkout and the admin order screens.
The fix: move to the CRUD API
The fix is straightforward, though it does mean a refactor. Stop treating orders as posts. Load the order with wc_get_order and use its setters. Code written that way works whether the store is on HPOS or on legacy storage.
// THE RIGHT WAY: Using WooCommerce CRUD API
$order = wc_get_order( $order_id );
if ( $order ) {
$order->set_billing_phone( '555-0123' );
$order->set_status( 'completed' );
$order->save(); // This updates both HPOS and legacy tables (if sync is enabled)
}If you are untangling a messier sync problem, my earlier post on WooCommerce HPOS loops covers how data syncing goes wrong in practice.
Emergency workaround for WooCommerce 10.7
If you upgrade to 10.7 and a critical legacy plugin falls over, you can put the old behaviour back. Drop the filter below into your theme’s functions.php or a small custom plugin, and treat it as debt you clear this month rather than a setting you forget about.
/**
* Temporarily re-enable HPOS sync on read.
* Use this only as a stopgap measure!
*/
add_filter( 'woocommerce_hpos_enable_sync_on_read', '__return_true' );If HPOS sync on read is eating your dev hours, hand the work to me. I have been wrestling with WordPress since the 4.x days.
What to do before April 14
Moving orders off the wp_posts table is what makes WooCommerce faster on large stores, and switching off HPOS sync on read is the last step in that move. It is a headache in the short term. It also pushes the ecosystem toward writing order code the supported way, so audit your custom code now, replace the database writes with the API, and you can upgrade without a scramble.
