Product object caching is enabled by default for new WooCommerce 11.0 stores. Variable products are especially sensitive because price, stock, visibility, attributes, and purchasability can depend on both a parent product and individual variations.
Use this for stores with Redis or Memcached, product imports, ERP sync, direct database writes, dynamic pricing, bundles, custom variation data, or high-volume catalog updates.
Quick answer
Update one field at a time through supported WooCommerce CRUD methods, then compare the parent, variation, Store API, archive, product page, cart, and checkout in the same request and a new request. Any direct SQL path must trigger equivalent invalidation or be replaced.
What to check first
- Record the cache feature state, persistent object cache, product and variation IDs, current prices, stock, attributes, visibility, and API responses.
- Change a variation price and stock through WooCommerce CRUD, save it, and read both the child and parent in the same PHP request and a new request.
- Repeat the change through the real importer, webhook consumer, ERP job, or custom code path used in production.
- Change a parent attribute, default variation, catalog visibility, and sale schedule, then inspect archive, product page, Store API, cart, and checkout.
- Run a direct SQL control case on staging to demonstrate stale data, then replace it with supported setters or explicit invalidation and retest.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Capture parent and child state | Record the cache feature state, persistent object cache, product and variation IDs, current prices, stock, attributes, visibility, and API responses. | Parent and variation objects show the new values in the same request and a fresh request. |
| Update through CRUD | Change a variation price and stock through WooCommerce CRUD, save it, and read both the child and parent in the same PHP request and a new request. | Store API, archive, product page, cart, and checkout agree on price, stock, and purchasability. |
| Test the real sync path | Repeat the change through the real importer, webhook consumer, ERP job, or custom code path used in production. | Importer, ERP, webhook, and admin edits produce the same invalidation result. |
| Inspect every dependent view | Change a parent attribute, default variation, catalog visibility, and sale schedule, then inspect archive, product page, Store API, cart, and checkout. | No routine workflow requires a full Redis, page-cache, or CDN purge to reveal a product change. |
Why this usually happens
- Parent and child product objects can have related but separate cache keys.
- Direct SQL bypasses WooCommerce setters, hooks, lookup-table updates, and cache deletion.
- A persistent cache can make stale data survive PHP requests and web workers.
- Import and webhook code often updates only the object it received, not all dependent views.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
$variation = wc_get_product( 1845 );
$variation->set_regular_price( '39.00' );
$variation->set_stock_quantity( 12 );
$variation->save();
clean_post_cache( 1845 );
wc_delete_product_transients( $variation->get_parent_id() );
wp cache flush-group products
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Capture parent and child state
- Update through CRUD
- Test the real sync path
- Inspect every dependent view
- Remove direct SQL writes
Decision rule
Keep product object caching enabled only after every production update path invalidates the changed product and its dependent parent or child views. Do not use global cache flushes as the permanent fix.
What to tell the client or owner
Share the cache feature state, object-cache backend, product IDs, update method, same-request and new-request reads, API output, importer or ERP logs, hook trace, and the smallest invalidation that fixes the result.
Production verification checklist
- Parent and variation objects show the new values in the same request and a fresh request.
- Store API, archive, product page, cart, and checkout agree on price, stock, and purchasability.
- Importer, ERP, webhook, and admin edits produce the same invalidation result.
- No routine workflow requires a full Redis, page-cache, or CDN purge to reveal a product change.
Mistakes to avoid
- Do not benchmark performance before proving correctness.
- Do not hide a missing invalidation hook with a global cache flush.
- Do not test only simple products when the store sells variations.
- Do not run direct SQL control cases on production.
Questions teams ask during testing
Does deleting product transients clear every object cache?
Not necessarily. Product transients, the WordPress object cache, REST or Store API cache, page cache, and CDN are separate layers. Identify which value is stale first.
Should existing stores enable product object caching immediately?
Test the exact catalog update paths and extensions on staging first. WooCommerce 11.0 enables it by default for new stores, while existing stores should make a measured compatibility decision.
When HandL WP should help
HandL WP can trace stale product data from WooCommerce CRUD through persistent object cache, Store API, page cache, and checkout without relying on destructive global purges.
If this is active on a production site, test WooCommerce product cache invalidation.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Canary product object caching on an existing store
Expand the variation test with the WooCommerce product object cache canary, covering every writer, product type, invalidation path, storefront, cart, checkout, feed, API, and rollback.
Helpful references