Empty or stale WooCommerce cart: restore the session and refresh data

Distinguish a lost cart from a stale display

You add a product and the cart appears empty on the next page. Or you remove an item but the header’s small cart still shows it. These symptoms can arise from different layers: session data, the browser response or the component displaying it. The desired result is one consistent cart throughout the same visitor’s journey.

This guide concerns WordPress with WooCommerce and administrator access for settings and logs. Browser inspection can begin without server changes. In multisite, select the correct store; two sites do not automatically share a cart. A store using an external interface may identify its cart through more than site cookies alone. On WordPress.com or managed hosting, some cache and network settings belong to the provider: use its panel or supply a targeted report.

WooCommerce is a free plugin; cart persistence belongs to the store and its integrations. The diagnostics below use existing tools and require no additional plugin installation.

Do not start by clearing every customer session under WooCommerce, Status, Tools. That would delete active carts without identifying the cause. Also preserve your own cart if needed: opening a new private diagnostic window is preferable to immediately deleting all data from your usual browser.

Reproduce one journey with precise reference points

Choose a simple in-stock product, quantity and test browser. Add it once, open Cart, change quantity and refresh. Compare the mini-cart, full page and checkout summary without submitting a purchase. Record the first point where values diverge.

Keep the same window throughout. Two devices or separate profiles may have separate carts. Conversely, multiple private windows in the same Chrome profile share the current private session. For a new private session, first finish useful work and close every private window, then open a new one. If you log in between steps, record that: a logged-in customer’s cart may be handled differently from a visitor’s. A post-login difference alone does not prove faulty cache.

Observe the full address at each step: domain, www, HTTPS and subdirectory. A link to an old store or another address may leave the context where the cart was created. Do not randomly correct both WordPress addresses: they may intentionally differ when installation is in a subdirectory.

Also read WooCommerce messages. A changed, unavailable or unpurchasable product may be removed from the cart with an explanation. A cart emptied after a successful order is different from loss before purchase. Preserve the exact message instead of hiding it with styling.

• Full page correct, mini-cart stale: examine component refreshing.
• Page and summary genuinely empty after adding: examine session, request and address changes.
• Old content served across several visits: examine caches and exclusions.
• One product removed with a notice: first check its state and commercial rules.

Route 1: check the Cart page assigned to the store

Open WooCommerce, Settings, Advanced and record the assigned Cart page. Open it under Pages, All Pages. Verify content through List View: a Cart block, classic shortcode or builder module must actually supply cart data. A layout merely titled Cart does not fulfill that function.

If the wrong page was selected, retain its initial assignment, choose the intended Cart page and save. Cart, Checkout and My Account functions must remain separate. Then check the public cart link opens this page rather than an old page retained after migration.

If correct content was accidentally replaced, recover its saved version on an isolated copy before restoring it. The shortcode below concerns classic checkout: place it in a Shortcode block on the assigned Cart page. Do not duplicate it below an existing Cart block to try forcing updates.

The expected result is a page displaying current session content and allowing quantity checks. Rollback restores saved assignment and content. This requires neither restoring the entire database nor touching existing orders.

If the page is correct but does not show the product added in the same session, continue with cache and cookies. If only the header icon remains stale, retain the correct page as a comparison point for the mini-cart route.

1. Record the Cart page under WooCommerce, Settings, Advanced, then its public address.
2. Open that page in the editor and identify its single cart block, shortcode or module.
3. On the copy, restore only assignment or content confirmed wrong; save the page and relevant settings.
4. Add the test product and check the public link and quantities.
5. If the correction is unsuitable, restore both saved values without touching orders.

[woocommerce_cart]

Remove personal responses from shared cache

Cart, Checkout and My Account pages display visitor-specific information. They must remain dynamic at every layer: plugin, hosting, CDN or proxy. A logged-in administrator may bypass cache encountered by visitors; therefore also check without administrative login using your diagnostic cart.

LiteSpeed Cache normally excludes these three pages when correctly assigned in WooCommerce. An empty Do Not Cache URIs list therefore does not prove they are cached. Start by checking assignment and received response. If a cache in front of the server reuses the page, a WordPress-only exclusion does not fix it.

For a confirmed missing exclusion, use actual paths under LiteSpeed Cache, Cache, Excludes, Do Not Cache URIs. This field matches address portions; ^ restricts matching to the beginning of the path. The example below assumes pages exactly under /panier/, /commande/ and /mon-compte/ at the root. Replace each with your store’s path, including any subdirectory or language prefix. Do not insert these rules into a PHP file.

LiteSpeed Cache is a free tool cited only if already present; server-cache features depend on a compatible environment. Do not install it to troubleshoot another cache. The expected result is an up-to-date personal cart after adding, changing and reloading. Retain necessary exclusions even if another cause explains the failure. Remove only an erroneous test rule after confirming pages remain protected from shared cache.

1. Preserve existing rules before modification; add only missing paths, one per line, then save.
2. Open LiteSpeed Cache, Toolbox, Purge, then Purge By. Choose URL, enter affected addresses one per line and use Purge List. This page purge does not purge CSS or JavaScript files.
3. In the logged-out diagnostic browser, open Network, reload the cart and select the main document request.
4. In response headers, X-LiteSpeed-Cache-Control: no-cache confirms bypass of this LiteSpeed layer. Its absence alone does not prove shared caching: also inspect CDN or proxy headers and rules.
5. Repeat the journey and check dynamic cart responses. If an external cache remains involved, correct and purge only affected rules with its administrator; do not erase customer sessions.

^/panier/
^/commande/
^/mon-compte/

Route 2: check whether the browser retains the session

A session cookie is a small piece of information returned by the browser so the store can retrieve visitor data. In Chrome developer tools, open Application, then Storage, Cookies and the store domain. After adding a product, look particularly for a cookie whose name begins wp_woocommerce_session_. Do not copy its value into a public report.

The same area shows domain, path, expiration and security attributes. Presence alone does not prove the server retrieves corresponding data. Absence before any interaction is not necessarily abnormal. Observe its state especially after adding and what is sent on the next page.

In Network, open the add-to-cart request, then the cart request. Examine Cookies information and any rejection reasons shown by the browser. Compare domains and protocol. If a cookie is set for another host or cannot be sent to the destination, retain this precise evidence before changing infrastructure.

For a browser-specific problem, compare a genuinely new private session while retaining privacy choices required by the journey. If the cart works there, inspect browser extensions or old site data in your usual profile. If cleanup is justified, first record your cart’s products: deleting local data cannot be undone and may log you out. In Chrome settings, open Privacy and security, Third-party cookies, then See all site data and permissions. Search the exact domain, delete only its entry and confirm. Do not clean all sites.

The expected result is session retrieval across successive steps without a relevant cookie rejection. If every browser fails identically, do not arbitrarily extend cookie lifetimes. Instead investigate the identified host change, rejection or server fault. A browser-setting correction is limited to what changed and must respect visitor privacy choices.

1. Add the test product in the diagnostic session and open Application, Storage, Cookies, then the domain.
2. Filter on wp_woocommerce_session_ and record only presence, domain, path and expiration without changing the value.
3. In Network, open the next cart request, then Cookies: check whether the cookie is sent and a warning appears.
4. Compare that request with the expected address; retain the first observed host change or rejection.
5. Correct only the identified cause, then repeat the same sequence before clearing more data.

Correct the address change or block actually observed

If the cart works up to a specific link, record its destination before and after redirection. An old hardcoded button address may send visitors to another store. Correct the link in the page or component producing it with necessary editing permissions, using the assigned Cart page. Preserve the initial destination to undo this targeted change.

If a server redirect causes the change, ask the administrator to compare its rule with the intended public domain and store paths. An installation in a subdirectory or behind a proxy is not fixed by making every address identical. Useful evidence is the exact transition changing context, together with its session result.

A consent tool may also delay scripts or prevent a necessary cart function. Check the component and configuration from the rejected request or cookie. Have the appropriate functional rule corrected under tool documentation and site policy. Do not remove the banner or every consent check to make testing succeed.

The expected result is retaining the same commercial context throughout the authorized journey. Repeat adding, opening the cart and changing quantity from the intended public address. To undo an unsuitable link correction, restore its saved value; for a network rule, retain a rollback procedure with whoever changed it. None of these changes requires erasing every customer’s cart.

Route 3: refresh the mini-cart through its own mechanism

If Cart contains correct products but the small cart stays stale, do not conclude the session disappeared. The theme may display a classic widget or Mini-Cart block with different refresh mechanisms. Identify this component in the header, builder or widgets before correcting scripts.

The classic widget may use cart fragments, small pieces of content refreshed after a change. In Network, look for a get_refreshed_fragments request when that mechanism is actually used. Its absence does not establish failure in a Mini-Cart block, which may use the Store API. Do not globally force fragments to load on every page to conceal incorrect integration.

For blocks, filter Network on wc/store, select the cart exchange, then Response. Compare products and quantities with the full cart; status 200 alone does not prove correct data. Depending on permalinks, the route may appear in a rest_route parameter rather than under /wp-json/. A rejected exchange or stale response must be fixed at its source. Do not share cart tokens observed in headers: some integrations use them to identify and manipulate the cart.

On the isolated copy, compare the mini-cart without script optimization suspected of blocking refresh. Use the existing tool’s documented page or script exclusion, then purge necessary generated resources. Keep the correct Cart page as a control. Reenable the transformation to verify whether the same defect returns.

If the component belongs to the theme or a builder, examine compatibility and version before replacement. A targeted integration correction may be needed. Preserve the original component and parameters for rollback. The expected result is updating the count and contents after addition and removal without altering correct session data.

Examine server data and normal product removals

If requests are correct but the session does not retain content, correlate test time with store and hosting logs. A database error, misconfigured object cache or plugin rewriting the cart needs specific evidence. Do not delete session tables to try starting over.

Session duration depends on context and may be customized. Code defaults distinguish visitors and logged-in users; they do not promise unlimited retention. A browser-deleted cookie, logout or user change may alter the result. Extending duration does not fix an immediately lost cart.

Examine product-removal notices. WooCommerce may discard an entry whose product is unavailable or changed incompatibly with stored data. Under Products, check the actual product and selected variation: publication, purchasability and availability. Do not force an item into the cart when the store can no longer sell it.

On a copy with a separate database and live email, payments and synchronization disabled, then compare without the cart or pricing plugin identified by logs. Deactivate it under Installed Plugins and repeat the same scenario if dependencies allow. Reactivate to confirm the relationship. Avoid this comparison on customers’ active carts.

The expected result is either an explained commercial removal or a reproducible technical cause. Restore components not responsible and do not transfer the test database onto the live store. Correction must preserve recent orders, accounts and carts.

Check the complete cart after correction

Validate a short sequence: add a product, open Cart, change quantity, remove a line and proceed to checkout. Compare mini-cart and summary at every step. A value correct only after manual reload may still indicate faulty refreshing.

Repeat the journey for a visitor and, if supported, a logged-in customer with their own test account. Keep the same browser within each sequence. Comparing two different sessions must not be presented as expected automatic synchronization between devices.

Record retained cache exclusions, corrected component and values restored to their initial state. If you cleared only your local data for comparison, remember that does not fix other visitors’ configuration. Conversely, a server correction may work without modifying existing carts; do not request blanket cleanup without an observed need.

The cart is restored when data remain consistent throughout the intended journey and display follows visitor actions. If content becomes correct but payments remain absent or final submission blocks, continue that specific diagnosis. No collective deletion is needed to declare this consistency verified.

Generate the cart link from its assigned page

If a custom-theme button points to an old address, the developer can replace its fixed URL with the intended WooCommerce function. This case concerns an identified PHP template; for an editor button, simply correct its link to the assigned Cart page as described above.

On the copy, preserve the original child-theme or owning-component snippet. At the location where the link should render, use an adapted snippet:

This snippet includes PHP tags because it is intended for a template mixing PHP and HTML. Do not paste it unchanged inside an already open PHP block. The function check avoids a fatal error if WooCommerce is not loaded; in that case it displays no misleading fallback link.

The function uses the cart destination configured in WooCommerce. It does not repair a bad page assignment, erroneous URL filter or shared cache. Repeat one visitor’s journey: add, click this button, check quantity and return to the catalog. The link must retain the expected domain and path. If the result worsens, restore the original snippet, then check assignment before deploying. No additional plugin is needed for this native link.

<?php if ( function_exists( 'wc_get_cart_url' ) ) : ?>
    <a href="<?php echo esc_url( wc_get_cart_url() ); ?>">Voir le panier</a>
<?php endif; ?>