When a variable product shows the previous shopper's pricing tier, clearing caches is only a temporary diagnostic. Identify whether the wrong amount comes from full-page HTML, WooCommerce's variation-price cache or the pricing extension itself. A correct cache key must distinguish every context that actually changes the price.
Use a private copy and synthetic customer groups. Never expose a real customer's negotiated price while gathering screenshots or sharing logs.
Keep the two cache boundaries separate
First compare a fresh application response with the displayed page. If WooCommerce calculates the expected member price but the browser receives a cached retail page, investigate page caching and logged-in exclusions. If the server already returns the wrong amount, a frontend purge will not repair the underlying price context.
The official variation-cache advisory explains why stable callback signatures should not be relied upon to encode changing object state. Extensions using dynamic variation-price filters must account for their pricing factors in woocommerce_get_variation_prices_hash. The advisory's original rollout dates were plans; inspect the behavior of your installed release instead of inferring its default from an old date.
Define a deliberately small pricing example
Choose one variable product with two variations. Create a retail test user and a member test user. For illustration, one variation might cost 100 in the retail group and 85 in the member group. These are fixture values, not claims about discounts your extension should implement.
Record the extension's expected price before enabling caching. Confirm whether the rule depends only on group membership or also on currency, quantity, tax-display context, a customer-specific agreement or a scheduled time window. Do not assume a role name captures all those distinctions.
Reverse the cache warm-up order
- Start from a controlled empty cache for the affected product on staging.
- Request the retail price, then request the member price in a separate authenticated session.
- Repeat both requests without clearing the cache.
- Reset only the test's relevant cache and warm the member context first.
- Request retail again and compare all four observations with the expected fixture.
If the first visitor's price persists for the second group, that is useful evidence of context contamination. It is not yet proof of which plugin created it. Preserve the request context and effective pricing callbacks so the maintainer can identify the owner.
Synthetic price-isolation worksheet: distinguish full-page caching from variation-price context and invalidation. Synthetic explanatory visual.
Review what belongs in the hash
The hash should represent the smallest stable set of price-affecting inputs. If all members share the same rule, a stable group identifier may be sufficient. If each account has negotiated prices, group membership alone is insufficient. Never add a random value on every request: it can hide stale results by preventing useful cache reuse.
Do not put passwords, raw personal information or unrestricted request payloads into a diagnostic cache-key log. Have the developer record a redacted context label and whether two requests produce equal or different keys. That is enough to compare isolation without exposing customer details.
Next change the underlying pricing rule while holding the customer fixed. Check whether the old entry is invalidated or the rule revision is represented appropriately. Context separation and invalidation are separate requirements; passing one does not establish the other.
Verify the amount beyond the catalog card
Compare the selected variation, product page range, cart line and checkout calculation using the same identity and quantity. Document intentional differences, such as a catalog price excluding tax and a checkout total including it. Do not call those a cache leak without normalizing the comparison.
For product-data changes made by an importer, use the parent and variation invalidation checks. This guide addresses customer-dependent price reuse, not every stale product object.
Release the repair only after both warm-up orders pass and a repeated same-context request still benefits from caching. Keep performance measurements separate from correctness evidence. HandL WP can trace the pricing and cache boundary when an extension fix needs validation across member, retail and anonymous sessions.
Reference and review date
Primary technical reference. Sources checked October 29, 2026. The proposed procedures and original diagrams are explanatory test aids, not claims of customer testing or measured improvements.