WooCommerce 11.0 enables product object caching by default for new stores and allows existing stores to test it. Scheduled sales change product and variation prices on a clock, but archive, product, feed, cart, checkout, object, page, and CDN caches can invalidate at different times.
Use this for WooCommerce stores with scheduled sales, variable products, bundles, feeds, multiple currencies, object cache, page cache, or CDN caching.
Quick answer
Create simple, variable, grouped, bundle, out-of-stock, and multi-currency sale fixtures. Record store timezone, UTC schedule, cron and Action Scheduler times, product and variation cache keys, invalidation hooks, edge state, and expected prices. Check admin, archive, search, product schema, API, feed, cart, checkout, email, and order records before, at, and after each boundary. Roll back cache enablement if any chargeable surface shows the wrong price.
What to check first
- Record WooCommerce, cache backend, cache experiment, timezone, cron, Action Scheduler, page cache, CDN, feed, currency, and extension versions.
- Create simple, variable, bundle, grouped, tax, currency, and stock fixtures with controlled sale start and end times.
- Capture product and variation cache keys, scheduled jobs, invalidation hooks, edge results, schema, feed, cart, and checkout prices.
- Test five minutes before, at the boundary, five minutes after, after manual edit, after stock change, and after rollback.
- Compare displayed, structured, API, cart, checkout, charged, email, and order-stored values for the same fixture ID.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Freeze product, variation, schedule, timezone, cache, and expected-price evidence. | Record WooCommerce, cache backend, cache experiment, timezone, cron, Action Scheduler, page cache, CDN, feed, currency, and extension versions. | Scheduled jobs run within the approved clock tolerance. |
| Trace the scheduled job and every invalidation hook from product object to edge. | Create simple, variable, bundle, grouped, tax, currency, and stock fixtures with controlled sale start and end times. | Product, variation, archive, search, API, schema, feed, cart, checkout, email, and order values agree. |
| Repair the narrow missing key, parent-child invalidation, cron delay, or CDN path. | Capture product and variation cache keys, scheduled jobs, invalidation hooks, edge results, schema, feed, cart, and checkout prices. | Warm and cold cache fixtures invalidate at sale start and end. |
| Retest all surfaces at start, end, edit, stock, and rollback boundaries. | Test five minutes before, at the boundary, five minutes after, after manual edit, after stock change, and after rollback. | The rollback switch restores correct prices without leaving stale edge content. |
Why this usually happens
- Product, variation, page, fragment, feed, API, and CDN caches have separate keys and invalidation paths.
- Scheduled jobs may run late or in a different timezone from the merchandising plan.
- A parent product can stay cached after a variation changes.
- A cart created before the boundary may preserve or recalculate price based on store policy.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
fixture,start_utc,surface,cache_before,price_expected,price_actual,invalidation,decision
SALE-1,15:00Z,product,hit,79.00,79.00,scheduled,pass
SALE-1,15:00Z,archive,hit,79.00,99.00,missed,fail
SALE-V2,15:00Z,checkout,miss,49.00,49.00,parent+variation,pass
SALE-1,17:00Z,feed,hit,99.00,79.00,late,hold
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Simple product | Sale starts at 10:00 | Every surface changes once |
| Variable product | One variation on sale | Parent and child prices agree |
| Sale ends | Cart created before boundary | Documented cart policy applies |
| CDN cold and warm | Same product route | No stale public price |
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Freeze product, variation, schedule, timezone, cache, and expected-price evidence.
- Trace the scheduled job and every invalidation hook from product object to edge.
- Repair the narrow missing key, parent-child invalidation, cron delay, or CDN path.
- Retest all surfaces at start, end, edit, stock, and rollback boundaries.
- Enable caching only through a sale canary with pricing and checkout alerts.
Decision rule
Enable or retain product object caching only when every chargeable and customer-visible surface changes at the documented boundary and the cart policy produces the expected order value.
Production verification checklist
- Scheduled jobs run within the approved clock tolerance.
- Product, variation, archive, search, API, schema, feed, cart, checkout, email, and order values agree.
- Warm and cold cache fixtures invalidate at sale start and end.
- The rollback switch restores correct prices without leaving stale edge content.
Field notes
- Use products that cannot be purchased by real customers during testing.
- Record both store-local and UTC boundary times.
- Treat an incorrect charged price as a hard rollback condition.
Questions teams ask during testing
Can this be tested on production?
Use production for read-only confirmation and one narrow synthetic fixture that cannot charge a card, email a real customer, expose personal data, or change inventory. Perform destructive repairs, upgrades, cache-policy changes, and schema work on staging first. Promote only the smallest measured change with a current rollback point.
What evidence should the report keep?
Keep exact component versions, UTC timestamps, stable synthetic IDs, expected and actual results, queue or provider identifiers, the decision owner, rollback point, and final verification. Redact customer data, credentials, tokens, message content, addresses, and private infrastructure details before sharing evidence.
When is the task complete?
Complete the task when the primary user path passes, downstream records reconcile, failure branches are understood, monitoring is active, and an established owner page links to the new guide in context. Record any observation window that remains instead of calling a quiet test a permanent fix.
Mistakes to avoid
- Changing production before recording exact versions, UTC timestamps, stable fixture IDs, current settings, and a reproducible baseline.
- Treating one successful browser screen as proof that queues, caches, providers, reports, roles, and downstream records agree.
- Deleting logs or identifiers before the failure boundary, business impact, rollback point, and accountable owner are known.
- Testing only an administrator session instead of the devices, roles, consent states, networks, and failure paths real users have.
What to tell the client or owner
Give the site owner the affected versions, exact synthetic fixture, UTC timeline, before and after evidence, root cause or current cause class, decision, rollback point, unresolved risks, and next review date. State which measurements prove success and which observation window is still open.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, fix WooCommerce sale price caching.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references