Cart dropping all items / cart session clears

Question

A site I manage suddenly (potentially 2 weeks ago - from GA stats, and only reported now) started dropping the cart items when you view the cart, or go to checkout.

The top 'mini-cart' shows the items in the dropdown, until you browse to cart/checkout, and you then end up on the cart, with 'There are no items in your cart' message.

Seems like a session issue. It does not happen when logged in.

Removed all session validation options in 'system->web->session validation settings', and enabled the one that says 'Use SID on Frontend'. This did solve the issue, but since these settings did not change in the last 3 months, I know there is some underlying issue.

This then points to issue with sore-id issue? Somehow the site is loosing what store-id it is on, and dropping the session/cart data? Maybe some observer/event/rewrite by some module.

I cannot replicate the issue on local dev, or on UAT server. DB on UAT is 2 weeks dated from live, so this could point to a db issue/setting?

Things I am trying: I am busy pulling current live db over to UAT to get that up-to-date , to see if I can replicate the issue there. will update when that is done.

Once I can replicate the issue in a non-live area, I will systematically disable modules, see if something is mucking about with store id's (starting with MageMonkey and sweettooth, since they got updated 2 weeks ago)

Question is - what else can I try? Any pointers to where I can whack some breakpoints and step the code to see if I can trace this issue?

there are no extra cache systems like varnish or memcache installed. Server is a standard cpanel install. testing on uat I disabled all cache.

further update : it would seem that when I drop to the default theme I cannot reproduce. I am systematically moving theme override folders back.

I also used git to backtrack code and the issue remains with every hash.

Update: Been a while since I had time to spend on this. High work load.

I moved the sessions to file based and the issue has gone away. Since the client is not intending to use multiple servers in the near future, and due to my work load, this was left at that. Will most likely come back to bite me later.

magento support suggested the issue is related to sweet tooth module extending the session classes, but I have disabled that module, and the issue remained.

will update when I get more results.

Answer 1

On our cPanel boxes, missing assets were serving the entire Magento page.

cPanel's defaults to ErrorDocument 404 /404.shtml but /404.shtml doesn't exist in Magento's document root, so the .htaccess gets executed again and redirects /404.shtml to index.php (using mod_rewrite).

Magento's default .htaccess should specify 404, 500, and other error handlers explicitly.

To fix this beahviour, we added the following to our .htaccess:

ErrorDocument 404 /errors/404.php

We probably should also add 500s as well:

ErrorDocument 500 /errors/500.php

Answer 2

Are you using Varnish on the server?

We've seen a number of implementations where people strip the cookie BEFORE fetching on static content (images/css/js) - so if the image/js/css doesn't exist; it loads the Magento bootstrap and 404's - this stripping the cookie and site session entirely.

Answer 3

One problem might be that Magento is not saving the session data when switching from HTTP to HTTPS. Make sure that the necessary settings for SSL etc. are set up properly.

Another problem it might be that the customer's ISP is changing their ip address, as documented here.

To fix this issue:

Change the Session Validation settings in the Magento Admin, found under System > Configurations > Web, to ‘no’ on everything except “Validate HTTP_USER_AGENT.” After doing this, go to System > Cache Management and refresh the configuration cache to apply the changes.

Answer 4

We have observed this issue when there is a missing image on a page, especially if the image is missing from all pages e.g. in a header or footer. It seems that the 404 page that either Magento or the webserver returns breaks the frontend session cookie, leading to loss of session. It is on our list of things to fix, but the workaround is to ensure there are no missing images...

Answer 5

We had a similar issue. In our case, it was the Varnish configuration (Like Ben Lessani - was suggesting). We have configured our Varnish to cache 404s for 120s so that our servers won't get hammered badly when there is a 404 error on a page.

So the issue is for 404s Magento was responding with a Set-Cookie in the header for frontend and frontend_cid cookies, that resets the customer session.

Our solution for this one is to strip any Set-Cookies for 404 responses,

unset beresp.http.set-cookie;

Answer 6

This could be a cookie/server date issue. First thing to check are the cookie headers. Inspect the headers (using something like Firebug, Charles or Fiddler).

You should see something like the following:

Set-Cookie  frontend=9dhtlgf1qmo6loqksvvmqjd625; expires=Thu, 31-Jan-2013 05:01:13 GMT; path=/; domain=.foo.com; HttpOnly

If the value for the expires field is in the past, then chances are the time on your server is wrong. This can happen when services like ntpd fail to start. If that's the case, check the time on the server. If the time is off check the status of ntpd (or whichever daemon service to keep the server's time updated).

Answer 7

PHP garbage collection is clearing out the sessions prematurely. I have seen this myself on high-traffic sites.

Some troubleshooting tips:

• How old is your oldest session? To find out: ls -laht [mageroot]/var/session/ | tail - if you don't have sessions longer than a couple of weeks or so, garbage collection is likely to blame
• Move sessions to another data store temporarily - MySQL or Memcached, for instance. Is the problem resolved?
• Is this happening on a development server? If no, and all things are equal, it could be that traffic levels are triggering premature session expiration or garbage collection

I have fixed this in one of two ways:

1. In your .htaccess, add php_value session.gc_maxlifetime 2592000
2. In your php.ini, set session.gc_maxlifetime

More reading: http://www.php.net/manual/en/session.configuration.php#ini.session.gc-maxlifetime

Answer 8

Dumb things that have broken PHP sessions for me in the past and might be worth checking:

• a full disk
• inaccurate server time

Answer 9

Check your Varnish VCL configuration, if it's enabled static files caching.

Commented the return (pass) line, and uncommented unset lines as on example below:

# Static files caching
if (req.url ~ "^/(pub/)?(media|static)/") {
    # Static files should not be cached by default
    #return (pass);

    # But if you use a few locales and don't use CDN you can enable caching static files by commenting previous line (#return (pass);) and uncommenting next 3 lines
    unset req.http.Https;
    unset req.http.X-Forwarded-Proto;
    unset req.http.Cookie;

In this case, static files 404s destroy the session.