This is the one part of the WooCommerce integration with a real infrastructure consequence. It is worth understanding before you decide whether to keep it.
The problem
A logged-out shopper’s cart lives in a WooCommerce session, identified by a cookie. WooCommerce normally writes that cookie while rendering a page.
The chat endpoint streams its response. By the time a tool runs, the response headers are already sent, and no cookie can be written any more.
Left alone, the result is the worst kind of bug: the chat reports the item added, the shopper believes it, and the cart is empty on the next page load.
The fix, and its cost
On any chat turn where the cart-changing tool is available, Sohay issues the session cookie before the stream opens. The cart then persists exactly as it would if the shopper had clicked Add to Cart.
The cost is page caching. Most full-page caches treat the WooCommerce session cookie as a “do not serve from cache” marker — so a guest who sends a chat message becomes uncacheable for the life of that session.
Two things make that less alarming than it sounds:
- It is the same cookie WooCommerce sets the moment any guest adds anything to a cart. Sohay issues it earlier, for shoppers who talk before they click.
- Read-only turns do not mint it. A store with the cart-changing tool switched off never issues the cookie at all.
Logged-in shoppers are unaffected either way — their cart persists against their user account.
Opting out
Return false from the priming filter:
add_filter( 'sohaychat_wc_prime_cart_session', '__return_false' );
Guests then keep the page cache and lose chat-driven cart changes on refresh. That is a real trade, not a free win: the chat will still report success, and the cart will still be empty afterwards.
If you take this route, switching the cart-changing tool off entirely is more honest than leaving it on and broken. See Turning individual shopping tools off.
The mini-cart lags by one navigation
A known and deliberate limitation. Your theme’s cart badge and WooCommerce’s cart fragments read cookies subject to the same headers-already-sent limit, so the badge on the page the shopper is looking at can be stale until they navigate.
The cart itself is correct — it is only the count in the header that is behind. It catches up on the next page load.
Deciding
- Heavy full-page caching, mostly logged-out traffic, cart matters — measure before and after. This is a genuine trade-off, not a formality.
- Mostly logged-in shoppers — none of this affects you.
- Support-focused site that happens to run WooCommerce — switching the cart tools off avoids the whole question.
Where to go next
Turning individual shopping tools off.
