WooCommerce cart empties when customer logs in: what I check

A shopper builds a basket as a guest, hits Log in (or creates an account at checkout), and the cart is suddenly empty. Sometimes every line vanishes. Sometimes only half the items survive. Either way, you just watched a near-sale fall over at the worst possible moment.

I see this a lot on busy Woo stores with full-page cache, Redis, membership plugins, or a custom login redirect. Below is the order I work through before I start rewriting session handlers on production.

Confirm guest cart vs logged-in cart

Reproduce it cleanly. Open an Incognito window, stay logged out, add two or three products, then log in with a real customer account (not an admin). Note whether the cart empties on the login page, on the first page after login, or only when they reach checkout.

Also try the reverse: log in first, add items, log out, then log back in. If the guest path loses the cart but the already-logged-in path keeps it, you are dealing with session merge or cookie scope, not a broken Add to cart button.

I check mobile Safari as well. ITP and aggressive cookie blocking can drop the guest session cookie the moment the login redirect fires, which looks exactly like "cart wiped on login".

Session cookies, cache, and empty cart HTML

WooCommerce stores the guest cart against a session cookie. If a full-page cache (or Cloudflare) serves a cached empty cart fragment to a shopper who already had items, the UI looks empty even when the session still has data. The opposite also happens: cache serves a logged-out shell after login, so the customer thinks everything vanished.

I look for:

• Full-page cache on cart, checkout, my-account, and any AJAX cart endpoints
• Redis or Memcached object cache holding a stale wc_session payload
• Cloudflare Cache Everything, or a page rule that ignores woocommerce_items_in_cart / session cookies
• Minify or combine plugins that break cart-fragments.js after login

On staging I exclude cart, checkout, and account URLs from full-page cache, purge Redis for that site, and retest the guest-then-login path. When the cart returns, I re-enable rules one at a time instead of guessing which layer ate the session.

Cart fragments, AJAX, and the theme mini-cart

After login, many themes refresh the mini-cart via Woo’s cart fragments AJAX. If that request 500s, returns cached empty HTML, or never fires because jQuery deferred too hard, the header says empty while /cart/ still has items (or the other way round).

I open the browser network tab during login, watch the ?wc-ajax=get_refreshed_fragments call, and compare the fragment HTML to the cart page. Theme overrides of the mini-cart template, Elementor Woo widgets, and old child-theme copies of cart fragments scripts are regular culprits after a Woo or theme update.

Switching briefly to Storefront (or a default block theme) with only Woo active tells you whether the wipe is core session behaviour or the theme’s cart UI lying to you.

Persistent cart and Accounts & Privacy

Under WooCommerce → Settings → Accounts & Privacy, check the retain cart options. Woo can keep a cart in the database for logged-in customers and restore it on the next login. If that is off, or a plugin overrides it, a customer who shops as a guest then logs in may not get a merge into their stored cart.

Also watch multi-device behaviour. A cart saved on phone, then login on desktop, depends on that persistent cart path working. If staff test only one browser, they miss the "emptied when I switched device" reports from real customers.

Plugin conflicts that wipe or replace the session

Membership, B2B, wholesale, currency switchers, and custom login or force-login plugins regularly rewrite the customer session on authentication. Typical failure modes:

• Login redirect that loads a cached homepage before Woo finishes merging the guest cart
• Currency or geo plugins that rebuild the cart in another currency and drop lines that "do not exist" in that catalogue
• B2B or role plugins that swap the customer into a different pricing group and clear the cart by design
• SSO or social login that creates a new user session cookie without carrying the guest session key across

On staging I disable membership, currency, and custom-redirect plugins, retest guest cart → login, then re-enable until it breaks. When I find the plugin, I fix its login hook rather than turning off sessions site-wide.

Server sessions and load balancers

If PHP sessions (or Woo’s custom session handler) are file-based and the site sits behind two app servers without sticky sessions, a login request can land on a different box than the one that held the guest cart. From the shopper’s point of view the basket just disappeared.

I check hosting docs for sticky sessions, confirm Woo is using the database session handler (default on modern Woo), and make sure Redis session storage is shared across every node. A recent host migrate or Cloudflare orange-cloud change is a common trigger for this class of ticket.

When to stop guessing

If guest cart works, logged-in cart works on its own, default theme keeps the merge, cache exclusions are correct, and the wipe only happens with one membership or currency plugin plus Cloudflare on, stop toggling live settings during peak traffic. At that point you want a staging clone, a HAR of the login redirect, and someone who has traced Woo’s session merge before.

Do not delete customer sessions or flush Redis on production hoping it "resets" the bug. You will empty carts for everyone mid-checkout.

Most of these tickets come down to cache serving the wrong cart shell, a plugin clearing the session on login, or persistent cart and multi-device restore not doing what store owners expect. Confirm the guest-then-login path in Incognito first, then fix the session and cache layer so the next shopper keeps what they already chose. Cheers.