WooCommerce 11.0 enables product object caching by default for new stores. The cache is request scoped and standard WooCommerce or WordPress APIs invalidate it. Code that writes price, stock, or attributes through direct SQL can bypass that invalidation, so a later wc_get_product() call in the same request may return the value loaded before the write.
Use this for importers, ERP connectors, pricing tools, inventory sync jobs, custom plugins, bulk editors, and integrations that call wpdb directly and then read a WooCommerce product in the same request.
Quick answer
WooCommerce 11.0 Product Cache Direct SQL Invalidation Test should be handled with a narrow evidence-first workflow: find direct product writes, build a same-request trace, compare the crud control, then verify the result before making broader changes.
What to check first
- Search custom code for wpdb update or query calls that write product posts, post meta, lookup tables, stock, price, sale price, regular price, or variation attributes.
- Build one staging request that reads the product object, performs the direct write, reads it again, and records database value, object value, cache deletion calls, and hooks.
- Repeat the case using WooCommerce CRUD setters and save so the standard invalidation path becomes the control result.
- Add the appropriate cache cleanup after unavoidable direct SQL, then repeat the exact same request with object caching enabled and disabled.
- Check the storefront, cart, variation selection, admin product screen, lookup tables, external feed, and next request before approving the change.
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 |
|---|
| Find direct product writes | Search custom code for wpdb update or query calls that write product posts, post meta, lookup tables, stock, price, sale price, regular price, or variation attributes. | The database, second product-object read, storefront, cart, and admin screen show the same expected value. |
| Build a same-request trace | Build one staging request that reads the product object, performs the direct write, reads it again, and records database value, object value, cache deletion calls, and hooks. | The CRUD control and any retained direct-SQL path have documented invalidation behavior. |
| Compare the CRUD control | Repeat the case using WooCommerce CRUD setters and save so the standard invalidation path becomes the control result. | Variable products, stock status, prices, sale dates, and lookup tables stay consistent. |
| Invalidate after raw SQL | Add the appropriate cache cleanup after unavoidable direct SQL, then repeat the exact same request with object caching enabled and disabled. | The fix works with product object caching enabled and does not rely on starting a new request. |
Why this usually happens
- The first wc_get_product() call stores an object for reuse during the current request.
- Raw SQL bypasses WooCommerce setters, save methods, hooks, and automatic invalidation.
- The database can contain the new value while application code still holds the old object.
- A test that starts a new request after every write cannot reveal same-request staleness.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
# Search custom plugins before changing behavior
rg -n '\$wpdb->(update|query)|_price|_stock|_sale_price' wp-content/plugins wp-content/mu-plugins
# In a controlled test, log before write, database after write,
# wc_get_product() after write, and the result after cache cleanup.
wp cache flush
wp wc product get 1042 --fields=id,price,regular_price,stock_quantity
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.
- Find direct product writes
- Build a same-request trace
- Compare the CRUD control
- Invalidate after raw SQL
- Retest every consumer
Decision rule
Prefer WooCommerce CRUD APIs. Keep direct SQL only when its owner can prove why it is required, update every related table correctly, trigger the intended invalidation, and pass the same-request trace plus storefront and checkout verification.
What to tell the client or owner
Share the product and variation IDs, custom code path, exact SQL fields and tables, first object value, database value after write, second object value, invalidation calls, hooks, cache feature state, and storefront result.
Production verification checklist
- The database, second product-object read, storefront, cart, and admin screen show the same expected value.
- The CRUD control and any retained direct-SQL path have documented invalidation behavior.
- Variable products, stock status, prices, sale dates, and lookup tables stay consistent.
- The fix works with product object caching enabled and does not rely on starting a new request.
Mistakes to avoid
- Do not solve request-scoped staleness with a CDN purge.
- Do not call a site-wide cache flush for every product write.
- Do not test only a simple product when the integration changes variations.
- Do not keep direct SQL without naming its plugin owner and every affected field.
Questions teams ask during testing
Is this the same as Redis or persistent object caching?
No. WooCommerce describes the product object cache as in-memory and request scoped. Persistent caches can create other issues, but this test is specifically about rereading a product inside the same request.
Is clean_post_cache() always sufficient after raw SQL?
Not automatically. The correct cleanup depends on what was changed and which WooCommerce data stores and lookup tables are involved. Prefer CRUD APIs and verify all consumers with a controlled fixture.
When HandL WP should help
HandL WP should help when an importer updates the database but checkout, feeds, or product pages keep an older value. We can instrument the request, replace unsafe writes where practical, and prove cache invalidation without broad production cache flushes.
If this is active on a production site, trace WooCommerce product cache staleness.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Parent and variation invalidation coverage
Extend the direct SQL control case with the WooCommerce 11.0 parent and variation cache invalidation test. It compares CRUD, importer, ERP, Store API, product page, cart, and checkout reads without relying on a global cache flush.
Helpful references