Two changes in the WooCommerce 10.7 and 10.8 cycle are worth a specific look before you push the update button on a live store. Both are about order data. One removes a silent safety net that has been hiding HPOS compatibility bugs since 2023. The other closes a REST API loophole that was silently corrupting subscription data. Neither is a WooCommerce mistake. Both are correct decisions that expose code that was already wrong.
WC 10.7: HPOS sync-on-read is off by default
When WooCommerce shipped HPOS in 2023, it included a compatibility feature called sync-on-read. If HPOS was enabled but a plugin wrote order data directly to wp_postmeta — bypassing WooCommerce’s CRUD layer — HPOS would detect the stale write at read time and re-sync the data into the HPOS tables automatically. Wrong data in, correct data out. The bug was hidden.
That feature is off by default in 10.7.
The consequence: code that writes order data using update_post_meta(), wp_update_post(), or a raw $wpdb query now has those writes silently disappear when HPOS is enabled. Reads go to the HPOS tables. The postmeta write lands in a place that nothing is reading.
How to check your code. Search your active plugins and theme for these patterns:
update_post_meta( $order_id, ...
wp_update_post( array( 'ID' => $order_id, ...
$wpdb->update( $wpdb->postmeta, ... // called with an order ID
get_post_meta( $order_id, ... // reads also fail without sync
Any of these called with an order ID is a candidate for breakage. The replacement:
$order = wc_get_order( $order_id );
$order->update_meta_data( '_my_key', $value );
$order->save();
If you need time to audit, the filter woocommerce_hpos_enable_sync_on_read re-enables the old behavior. It is a temporary escape hatch; WooCommerce will remove it in a future release.
WC 10.8: the REST API now validates order type
Before 10.8, sending a PUT request to /wc/v3/orders/{id} with a subscription ID or custom order type ID would silently convert that order to a shop_order, overwriting type-specific data. WooCommerce now returns HTTP 400 with woocommerce_rest_shop_order_invalid_id when the ID does not belong to a shop_order.
If you have REST API integrations that update subscriptions or custom order types through the standard orders endpoint, those calls fail in 10.8. Subscription updates need the Subscriptions plugin’s own REST endpoints. Custom order types need their own registered endpoints.
The same release excludes checkout-draft orders from the default status=any query. If your integration pulls all orders via the REST API and processes drafts downstream, add status=checkout-draft explicitly.
WP 7.0: the short version
WordPress 7.0 shipped May 20. For order-adjacent plugins the checklist is short:
- PHP minimum is now 7.4. Recommended is 8.3. Nothing breaks immediately on PHP 8.0 or 8.1, but you are off the supported path.
- The wp-admin color scheme changed. WooCommerce 10.8 shipped explicit WP 7.0 admin readiness fixes. If your plugin renders custom admin UI without using WC’s provided styles, spot-check it.
- Real-time collaboration was announced for 7.0 and cut twelve days before release. Do not build against it; it is not expected before 7.3.
Order Daemon on WC 10.8 and WP 7.0
We ran Order Daemon through a full test cycle against WC 10.8 and WP 7.0 before publishing this. Nothing needed changing in the plugin.
Order Daemon has used the WC CRUD layer since day one: wc_get_order(), $order->get_meta(), $order->update_status(). It has never touched wp_postmeta directly for order data. When 10.7 removed sync-on-read, the plugin did not notice. It was never relying on it. The 10.8 REST API type validation does not affect internal processing for the same reason. The event log captures hooks that fire on the order object, not on database writes, so the Action Scheduler analytics change in 10.5 did not create gaps in the event timeline either.
Order Daemon Free v1.3.35 and Pro v1.2.25 are tested and confirmed against WC 10.8 and WP 7.0. Install the free version before the update: every status transition and rule execution is recorded on a per-order timeline, so a break shows up there before it shows up in a customer email.