27

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.

  • The 'Use SID on Frontend' did in fact not fix the issue. Seems the issue is random. Works fine for some sesssions, drops for others. – ProxiBlue Jan 31 '13 at 3:04
  • I can reliably replicate this on UAT now. Seems like 8/10 attempts to add to cart has this issue. Then the session 'sticks' and everything works as per normal. Eliminated SweetTooth and MageMonkey as reasons (after they were upgraded) Confirmed it is a session issue. WHen I add to cart, I have session with one ID, when I go to view cart, I get new session id. – ProxiBlue Jan 31 '13 at 3:58
  • Some colleagues encountered an almost identical issue. I don't know exactly what caused the issue (I know it was related to memcache and/or varnish), but the solution was setting up a load balancer for the server(s). So you should talk to your server administrator about this. – Vlad Preda Jan 31 '13 at 13:36
  • 1
    What is the magento version? Also what are you using as session storage? Does switching to files or database respectively make a difference? – Kristof at Fooman Feb 1 '13 at 8:33
  • @Fooman Hi, EE 1.11.2.0, using DB session, have not tried swapping to files, will report back what result that gives. – ProxiBlue Feb 1 '13 at 8:56
8

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

  • @ProxiBlue did this solve your problem since it's the accepted answer? I have almost identical issue. Still not sure what's causing it. – dchayka Aug 4 '17 at 18:32
9

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.

  • No varnish, wish it was that simple :'( – ProxiBlue Jan 31 '13 at 13:44
  • Hi have same issue may i know what is the solution? – Kandarp B Patel Feb 5 '15 at 11:04
  • @Ben Please can you elaborate on this. – burntblark Oct 22 '15 at 9:59
6

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.

  • The cart is still in http, thus not http->https issue. – ProxiBlue Jan 31 '13 at 21:16
  • 1
    It is happening to us, in our UAT environment as well, and we have a fixed ip. Appreciate the suggestions. – ProxiBlue Jan 31 '13 at 21:17
5

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...

  • I'm glad that's not happening for some of our clients. More 404s than I care to admit. – philwinkle May 2 '13 at 5:13
  • 2
    @jonathanday Magento won't do this, but badly configured Varnish will. – Ben Lessani - Sonassi May 2 '13 at 7:13
  • @sonassi, can you expand on the badly configured Varnish pls? We've been having the same issue. Fixing the 404 page has fixed the issue but would love to know if we can configure Varnish better! – jmlnik Jun 19 '13 at 7:54
  • This was in fact what was happening. I somehow missed this answer! The fact is that magento should not be pushing the controller version of the 404 page, but a static 404 page. – ProxiBlue Jun 19 '13 at 8:00
  • 1
    I posted an answer which explains it. – Ben Lessani - Sonassi Jun 19 '13 at 8:20
1

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).

  • Checked, server date/time if fine, cookie date / time is fine :( – ProxiBlue Jan 31 '13 at 4:47
1

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

  • 1
    Good suggestions. Will try in a few days – ProxiBlue May 1 '13 at 23:11
1

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;
0

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

  • a full disk
  • inaccurate server time
  • :) checked disk first thing, all ok. – ProxiBlue Jan 31 '13 at 3:55
  • date fine :( not that simple, ugh [~/public_html/var/log]# date Thu Jan 31 11:55:49 WST 2013 – ProxiBlue Jan 31 '13 at 3:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.