Starting April 14, WooCommerce 10.7 will introduce a significant architectural shift: HPOS sync on read will be disabled by default. If you have spent years writing custom code that treats WooCommerce orders like standard WordPress posts, this change is your wake-up call. The safety net that kept your direct database updates in sync is being pulled away.
As a developer who has wrestled with High-Performance Order Storage (HPOS) since its early beta days, I can tell you this move was inevitable. Consequently, stores relying on legacy hooks or generic post meta functions are about to face data integrity issues if they don’t refactor immediately.
What Exactly Is HPOS Sync on Read?
When WooCommerce introduced HPOS, it included a “Compatibility Mode” to sync data between the new custom tables and the old wp_posts table. HPOS sync on read (also known as “on-the-fly” synchronization) was an additional layer of protection. Specifically, it compared the timestamps of both records during a read operation. If the legacy wp_posts record was newer than the HPOS record, WooCommerce would pull that data back into the authoritative HPOS tables.
Furthermore, this mechanism was designed as a temporary bridge. It allowed developers time to adopt the WooCommerce CRUD (Create, Read, Update, Delete) API. However, keeping this bridge open indefinitely invites race conditions and performance bottlenecks that negate the very benefits HPOS was built for.
Why Disabling It Is the Right Move
Disabling this feature by default improves reliability. In high-traffic environments, “Sync on Read” can lead to unintended consequences, such as order status reversions or stale data overwriting legitimate updates. By removing the “on-the-fly” check, WooCommerce ensures that the HPOS tables remain the single source of truth without the overhead of constant comparisons.
Are You at Risk?
You are affected if your site uses custom code or older plugins that modify order data using generic WordPress functions like update_post_meta or direct SQL queries. Here is an example of the “Naive Approach” that will break:
// 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' ) );Therefore, if you continue using these functions, your changes will sit in the legacy wp_posts table, ignored by the HPOS engine that actually powers the checkout and admin dashboard.
The Senior Dev Fix: Transitioning to CRUD
The solution is simple but requires a refactor. You must stop treating orders as “posts.” Instead, use the wc_get_order function and the dedicated setters. This approach ensures your code is compatible regardless of whether the store uses HPOS or 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’re dealing with complex synchronization issues, you might want to check my previous post on WooCommerce HPOS loops to understand how data syncing can sometimes go wrong.
Emergency Workaround for WooCommerce 10.7
If you upgrade to 10.7 and discover that a critical legacy plugin has broken, you can temporarily re-enable the old behavior. Use the following filter in your theme’s functions.php or a custom plugin, but treat this as a technical debt to be cleared immediately.
/**
* Temporarily re-enable HPOS sync on read.
* Use this only as a stopgap measure!
*/
add_filter( 'woocommerce_hpos_enable_sync_on_read', '__return_true' );Look, if this HPOS sync on read stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
Takeaway: Performance Requires Standards
WooCommerce is maturing. The transition away from the wp_posts table is a massive win for performance and scalability. While disabling HPOS sync on read might feel like a headache today, it forces the ecosystem toward better coding standards. Stop hacking the database and start using the API—your site’s speed and stability depend on it.
