WooCommerce + ForgeCache — Cart, Mini-Cart, and Checkout Issues

Issue 1 — Cart Page Shows Empty After Adding Products

Customer adds a product to cart, navigates to the cart page, and sees “Your cart is currently empty” — but the product is actually there (other carts, server-side cart API, etc. confirm).

What this almost certainly is

A cache layer above ForgeCache (managed-host edge cache, CDN page cache, reverse proxy) is serving a stale cart page that was captured during a previous anonymous visit. ForgeCache itself never caches the cart page — the exclusion is hardcoded.

How to verify

The fix

Configure the upstream cache layer to exclude WooCommerce pages and cookies. The exact steps depend on the layer:

• Cloudflare — add a Cache Rule that bypasses cache for paths matching /cart/*, /checkout/*, /my-account/*, and any request that includes a woocommerce_* cookie. Cloudflare’s Caching → Cache Rules panel; create a rule with eligibility set to Bypass cache.
• Cloudflare APO — APO has WooCommerce auto-detection that’s supposed to bypass cache for WC cookies. If you’re still seeing stale carts with APO enabled, the auto-detection may have missed your WC install — check the APO settings panel in your Cloudflare dashboard (its location has moved across Cloudflare redesigns), or escalate to Cloudflare support.
• Managed-host edge cache (Kinsta, WP Engine, Pressable, SiteGround SuperCacher, etc.) — every reputable WC host auto-excludes cart/checkout/account. If they’re not, that’s a host support ticket.
• nginx / Varnish / LiteSpeed — if you control the reverse proxy, add a bypass for any request with the woocommerce_items_in_cart or wp_woocommerce_session_* cookie set.

Issue 2 — Mini-Cart in the Header Doesn’t Update After Add-to-Cart (Shop / Category Pages)

Customer is on the shop page or a category archive, clicks Add to cart on a product card, and the mini-cart count in the header stays at zero (or whatever it was before). The cart page itself does have the item, but the header doesn’t update without a full page reload.

Three ways to handle it

Option A — Accept the trade-off (recommended for most stores)

The mini-cart still updates correctly on single product pages, the cart page, the checkout page, and every other non-archive page. The only place it doesn’t live-update is on shop / category / tag listings, and the customer gets the correct cart count as soon as they navigate anywhere else. For most stores this is the right call.

Option B — Disable WooCommerce optimizations entirely

If live mini-cart updates on shop archives are critical to your store (e.g. high-velocity add-to-cart UX with a side-cart pattern), the simplest fix is to turn off the WooCommerce toggle. WP Admin → ForgeCache → Settings → Advanced → WooCommerce → uncheck Enable WooCommerce optimizations → Save Changes. ForgeCache will still respect WC cart cookies and exclude cart/checkout/account from page cache, but it’ll stop dequeuing the mini-cart fragments script. Your shop pages will be marginally slower but the mini-cart will update live everywhere.

Option C — Selectively re-enable fragments on archives via a tiny mu-plugin

If you want most of the WC optimizations but not the fragments dequeue, drop this into wp-content/mu-plugins/forgecache-keep-fragments.php (create the mu-plugins directory if it doesn’t exist):

<?php
// Keep wc-cart-fragments enabled on shop archives despite ForgeCache's
// WooCommerce optimization. Trade speed for live mini-cart updates.
add_action( 'init', function() {
    if ( class_exists( 'ForgeCache_WooCommerce' ) ) {
        $inst = ForgeCache_WooCommerce::instance();
        remove_action( 'woocommerce_before_shop_loop', array( $inst, 'disable_cart_fragments_on_shop' ) );
    }
}, 20 );

This unhooks just the fragments dequeue while leaving every other WC optimization (generator tag removal, checkout password-strength-meter dequeue) intact.

Issue 3 — Checkout Page Shows Stale Data (Shipping Methods, Totals, Form State)

Customer reaches checkout but sees stale shipping rates, an old cart total, or form fields pre-filled with a previous customer’s info.

What this almost certainly is

Same root cause as issue 1 — an upstream cache layer is serving a captured-once-and-reused checkout page. ForgeCache hardcodes is_checkout() to never page-cache. POST requests (the checkout submission) bypass cache by definition.

How to verify

Open an incognito window, add a product, go to checkout. Are the totals correct? If yes, the issue is in your customer’s browser/cookies. If no — or if you see another visitor’s form prefill data — check the response headers on /checkout/ the same way as issue 1.

The fix

Same as issue 1: exclude /checkout/* and the WC cookie set at every cache layer above WordPress. If it’s Cloudflare, a Cache Rule with Bypass cache for the checkout path is the cleanest fix. If you’re running Cloudflare APO with WooCommerce auto-detected, APO should be excluding checkout automatically — if it isn’t, Cloudflare support can verify whether APO detected your WC install correctly.

Issue 4 — Customer A Sees Customer B’s Cart / Account Data (Critical)

The rare and serious one. Customer A reports seeing items they didn’t add, or a wrong email/shipping address pre-filled on checkout, or another customer’s order data in My Account.

What this almost certainly is

A cache layer above ForgeCache is serving an HTML response that includes server-side session data (cart contents, checkout pre-fill, account info) to multiple visitors. The classic cause is a CDN or reverse proxy caching responses without honoring the cookies that identify the customer.

How to verify

The fix

Disable or correctly configure whichever cache layer is the source. Concretely:

• If Cloudflare is HIT’ing logged-in pages, your Cache Rules / Page Rules are too aggressive. Add a rule that bypasses cache for any request with the wordpress_logged_in_*, wp-postpass_*, or any woocommerce_* cookie set. Cloudflare APO with WC detection does this automatically — if APO is enabled but you’re still seeing this, escalate to CF support.
• If a host edge cache is the culprit, open a host support ticket immediately — this is a misconfiguration on their side and they should have a per-customer fix.
• If another caching plugin is running alongside ForgeCache (LiteSpeed Cache, W3 Total Cache, WP Super Cache), deactivate it. Running two page-cache plugins simultaneously is unsupported and a common source of data-leak bugs.

After applying the fix, force-purge every cache layer (ForgeCache → Clear All Cache, Cloudflare → Purge Everything, host edge cache → full purge) before testing again. Stale entries from before the fix will continue serving the leak until they roll over naturally.

Other Common WooCommerce + Caching Symptoms

Add-to-Cart button does nothing / page reloads to homepage

Usually an AJAX failure rather than a caching issue. ForgeCache excludes every request where wp_doing_ajax() is true — which covers admin-ajax.php (the route most wc-ajax calls take) — so this is rarely a ForgeCache layer problem. Common actual causes: a security plugin blocking the AJAX request, an upstream CDN caching the wc-ajax endpoint, or a JS error preventing the AJAX call. Open DevTools → Network and look at the ?wc-ajax=add_to_cart request when you click the button. Anything other than 200 with a JSON response is a clue.

Currency switcher / multi-currency plugins showing wrong prices

Multi-currency plugins typically store the visitor’s chosen currency in a cookie. If that cookie name isn’t in ForgeCache’s dynamic-cookie watchlist, anonymous visitors might see a cached page in the wrong currency. The watchlist is hardcoded to standard WC + EDD cookies; if your currency plugin uses a custom cookie name, the simplest fix is to disable page caching on currency-switched visits via the forgecache_should_cache_page filter:

<?php
add_filter( 'forgecache_should_cache_page', function( $should_cache ) {
    // Replace with your currency plugin's actual cookie name
    if ( isset( $_COOKIE['my_currency_cookie'] ) ) {
        return false;
    }
    return $should_cache;
} );

Product price update doesn’t appear on shop archive

ForgeCache invalidates the cache for a specific post URL plus the homepage on save_post. It doesn’t automatically purge the shop archive page on a product price change — the archive page’s cache will roll over naturally on its TTL (default 1 hour) or you can force it manually via ForgeCache → Clear All Cache. If you change prices frequently and want shop archives to update faster, lower the cache TTL in Settings → Cache → Cache Expiration.

Checkout content area blank with WooCommerce Blocks + Blocksy / Stackable / block-based builders

If you’re running the WooCommerce Cart Block or Checkout Block (or any block-based builder that server-renders React components — Blocksy, Stackable, similar), and the entire checkout content area went blank after enabling Core Web Vitals, the cause is the CWV image-dimensions transformer mutating <img> attributes after server-side rendering. React hydrates on the client, finds attributes it didn’t generate, treats the SSR output as a mismatch, and unmounts the affected component.

Fixed in ForgeCache 2.1.19+ — the CWV transformer now auto-skips on cart, checkout, and account pages. If you’re still on 2.1.18 or earlier, update from WP Admin → Plugins, or as a temporary workaround disable the Core Web Vitals toggle in Settings → Advanced.

Still Stuck? Email Priority Support

If you’ve worked through the relevant issue above and the symptom persists:

Email support@royalplugins.com with the diagnostic info below. Priority email support is included with your ForgeCache Pro license — typical response time is within 24 hours, and we treat suspected cross-customer data leaks (issue 4) as highest priority.