A Sylius cart empty after adding product issue is frustrating because the storefront can look as though it worked. A customer clicks “Add to cart,” sees a redirect or success message, then finds an empty cart on the next page. In other cases, the mini-cart count never changes, or items disappear only when the customer moves from a product page to checkout.
This symptom is usually not a catalog problem. It more often means that Sylius created or updated an order in one part of the request flow, but could not identify the same cart on the following request. Sessions, cookies, channels, caching, custom controllers, and storefront JavaScript can all be involved.
The safest approach is to establish exactly where continuity breaks before changing configuration or clearing application data. If the issue is affecting live orders, a focused Sylius Bug Fixing review can trace the failed request flow without relying on guesswork.
First, confirm what “empty” means
Several different failures can look like an empty cart, but they need different fixes. Reproduce the issue in a private browser window or a clean test session and record the result after each action.
- The item never appears: the add-to-cart form may be invalid, a variant may be unavailable, or custom code may be preventing the add action.
- The item appears briefly, then vanishes after a redirect: session or cookie continuity is a likely cause.
- The mini-cart stays empty but the cart page contains the item: the problem may be a stale JavaScript component, API response, or template data issue.
- The item disappears only after changing channel, currency, locale, or domain: request context and channel configuration should be checked.
- The problem affects only guests or only logged-in customers: compare the two cart-association paths rather than assuming one shared cause.
Also note whether it happens for every product, only configurable products, only products with a particular shipping setup, or only after a recent deployment. A precise reproduction path is more valuable than a broad list of possible causes.
Check the browser request and response flow
Start with the add-to-cart request in browser developer tools. Confirm the request method, URL, response status, redirect destination, and cookies sent with the request. A successful-looking 302 response does not prove that the cart was retained; it only proves that the application instructed the browser to load another URL.
Look for these clues:
- Does the add-to-cart request return a validation error hidden by custom JavaScript?
- Does the response set a session cookie, replace an existing one, or delete one?
- Is the cookie present on the request to the cart page?
- Does the host change between www and non-www, HTTP and HTTPS, or one subdomain and another?
- Does an AJAX request add the item while a later full-page request renders a cart for a different session?
A changed session identifier between two consecutive requests is a strong signal. Do not immediately edit Sylius cart services, though. First determine why the browser stopped returning the expected cookie or why the server could not read the saved session.
Review session storage and session configuration
Guest carts generally depend on consistent session handling. If the session is not persisted, is cleared, or is read from a different storage location on the next request, Sylius can create a fresh cart instead of loading the existing one.
Review the configured session handler and the infrastructure behind it. File-based sessions can fail when permissions are wrong or when application requests are served by containers or servers that do not share the same session directory. Redis or database-backed sessions can fail through connection errors, expired keys, namespace changes, serialization issues, or environment-specific configuration differences.
In a load-balanced environment, check whether each node can access the same session data. Session affinity may conceal a shared-storage problem during light testing, then expose it when requests land on different nodes. Compare application logs and server identifiers for the add-to-cart request and the following cart-page request.
Do not clear all sessions on a live store simply to test this theory. That can log customers out and abandon active carts. Use a controlled test session and review logs, storage health, and configuration first.
Cookie settings are a common cause after a domain, proxy, HTTPS, or deployment change. A session cookie can exist in the browser but still not be sent to the URL that renders the cart.
Check whether the application is consistently using one canonical host. For example, a cookie set for one host may not accompany a request to another host. The same is true when a storefront moves between a main domain and a subdomain. Ensure the cookie path permits access to the storefront routes that need it.
HTTPS termination deserves special attention. When a reverse proxy handles TLS but the application believes requests are plain HTTP, cookie security decisions and generated redirects may be inconsistent. Trusted proxy configuration should accurately reflect the deployment. Avoid weakening secure cookie settings as a quick workaround; correct the request scheme and proxy awareness instead.
SameSite settings can matter when the store is embedded, opened from a third-party flow, or uses cross-site payment return paths. However, do not attribute every cart loss to SameSite. Test the exact navigation path and inspect whether the cookie is actually absent before changing it.
Check channel and storefront context
Sylius is channel-aware. The current channel can influence what the shopper sees and which storefront configuration is used. If custom routing, multiple domains, locale prefixes, or channel resolution changed recently, confirm that the product page, add-to-cart endpoint, cart page, and checkout all resolve the same expected channel.
Useful questions include:
- Does the issue occur only on one storefront domain?
- Does it begin after selecting another currency or locale?
- Are the product page and cart page served through different route hosts?
- Did a custom channel resolver, request listener, or redirect rule change?
A channel mismatch may not literally remove an order item from the database. Instead, it can make the next request retrieve or display a different cart context. That distinction matters when reading database records and logs.
Audit custom add-to-cart code and event listeners
When the standard storefront flow works but a custom product page, headless frontend, or bespoke controller does not, focus on the integration boundary. Custom code may add an item to an order object without persisting it, use the wrong cart context, omit a required request value, or redirect before the cart update completes.
Review recent changes around:
- custom add-to-cart controllers and forms;
- API endpoints or frontend fetch requests;
- event listeners and subscribers that alter order items, quantities, or availability;
- promotional logic that removes items when a condition is not met;
- theme overrides for product forms and cart fragments.
Compare the failing request with a standard Sylius product form on the same environment. This is often faster and safer than trying to infer intended behavior from custom code alone. Pay attention to which services obtain the current cart and when persistence occurs.
Rule out cache and frontend display problems
Not every empty-cart report is a missing cart. A reverse proxy, CDN, browser cache, or incorrectly cached cart fragment can display a generic or old cart response to a customer. This is especially likely if the cart page or mini-cart has been included in aggressive full-page caching rules.
Test with caching bypassed where appropriate and compare the rendered page with the underlying request data. Personal cart content should not be served as a shared cached response. Also inspect JavaScript console errors and network calls if the cart count is updated asynchronously. A failed fragment request can leave the visible count at zero even while the server-side cart is correct.
Use logs and database checks to narrow the failure
Once the behavior is reproducible, correlate timestamps across browser requests, Symfony logs, PHP or web-server logs, and session storage. Look for exceptions, session write failures, redirects to an unexpected host, and messages from custom listeners.
Database inspection can help confirm whether an order and order item were created, but it should answer a specific question: did the add request persist an item, and was the following request associated with that same cart? Avoid directly editing order tables to “repair” a test cart. Manual changes can create misleading data and bypass normal business logic.
A safe order for fixing the issue
- Capture a clean, repeatable guest-cart test.
- Compare request URLs, response redirects, and session cookies.
- Confirm session storage works across the servers handling requests.
- Verify canonical host, HTTPS, proxy, and cookie settings.
- Check channel resolution across the product and cart routes.
- Compare custom add-to-cart behavior with the standard Sylius flow.
- Exclude shared caching and frontend rendering faults.
- Test the final fix for guests, authenticated users, multiple browsers, and the full checkout path.
Make one controlled change at a time and retain evidence of the before-and-after behavior. This reduces the risk of fixing the symptom for one browser while breaking cart handling elsewhere.
When the cart issue needs urgent help
Treat the issue as urgent when customers cannot add products, active carts disappear during a campaign, or the failure began immediately after a deployment. Preserve logs and deployment details, avoid broad cache or session purges, and consider temporarily rolling back only a clearly identified recent change when a tested rollback path exists.
If the cart is empty after adding a product and the cause crosses Symfony configuration, sessions, proxies, custom Sylius code, and storefront behavior, targeted investigation is usually more effective than a trial-and-error configuration change.
Frequently asked questions
Why does a Sylius cart work briefly and then become empty?
This commonly indicates that the following request is using a different or unreadable session. Check cookie continuity, redirects between hosts or schemes, session storage, and load balancer behavior.
Can a cache cause a Sylius cart to appear empty?
Yes. Shared caching can serve stale cart fragments or a generic cart page. Confirm whether the server-side cart exists before assuming the item was removed.
Does this affect logged-in customers and guests in the same way?
Not always. Guest carts rely heavily on the browser session, while authenticated carts can also involve customer association and merge behavior. Test both paths separately.
Should I clear all sessions to fix an empty cart?
Usually no. Clearing sessions can disrupt active customers and does not identify the underlying cause. Diagnose a controlled test session first.