Add to Basket --> Cart Empty - SOLUTION

[Guest ColeFlournoy]

Hello,

There is a huge number of threads in this forum relating to an unresolved issue that is causing a lot of issues for many cart users and because this issue has been around for so long and is not recognized as an issue by the developer – this problem is hurting the cube cart community overall.

The issue is – some (but not all) customers add an item to their cart and then go to checkout and the items have disappeared. The can continue to add items and try to check out, but they are unable to do so unless they do a “workaround†as listed in other posts.

But forget all the debate of whether this is an issue or a bug or if it’s not. We have recognized that this clearly is an issue affecting at least some portion of cube cart installs. My personal opinion is that this is a problem effecting all cube cart stores, but because most cube cart stores don’t have a large number of sales, they would rarely see it come up – and if it did just attribute it to the customer doing something wrong.

So – let’s find a solution. I will personally debug this code to try and find a solution – but the first step is recreating the problem. I have so far, been unable to figure out what exact steps are taken to cause the problem. I only know that from about 100 orders, there are consistently about 5 or so people (at least) that have run across this problem. Most likely those 5 people are just adding items to their cart in some specific way that causes the error. Whether you have any programming background or not – you can help solve this problem just by trying to figure out what is causing it. So please, if you have had (or think you might have had) this issue come up – test your store and see if you can recreate the problem and make sure to document all steps exactly here.

Thanks,

Cole

[Guest bholland]

Hi Cole,

Thanks for posting this - although the title is a little misleading

Anyways, I can usually reproduce the error fairly easily and will run some tests and post my findings and thoughts on the matter. It's good to see someone else that views this as a real problem.

-B

[Guest bholland]

Okay, just replicated it (see, I told you it was easy...first try! - not actually excited by this...)

Browser: FF 1.5.0.8

Mods: SEF URLs, Estelle redirect to basket

login status: Not logged in

I didn't do anything to the cookies in my browser, but have visited the site before...The very first time I land on the homepage, then click to a product page, then "add to cart" (and am subsequently redirected to the cart), viewing empty cart.

The issue went away when I clicked "Homepage" in the left nav and repeated the process.

Anyone else?

[Guest ColeFlournoy]

That doesn't cause it for me (in IE 7). Although, I had another customer today who was having the empty cart problem -- so the problem is still there.

I am not completly sure about this, but I think I tested estelles mod and it caused the empty cart problem a lot more frequently so I then uninstalled it.

Wow -- as I am writing this post another customer just called and is telling me they can't checkout because of the empty cart problem. Any more suggestions as to how I can replicate this problem?

Thanks,

Cole

[Guest bholland]

I haven't replicated the problem since I have been on IE7, so I can't comment on that one.

I don't have much experience with cookies, but it seems like it is the initial setting of the cookie that is having problems...Does anyone who has experience with this care to weigh in??

[Guest ColeFlournoy]

I did see this problem occure on IE7 - and this seems like a problem independant of what browser you use. I am going to be out for the weekend -- but off the top of my head I am thinking a quick fix for for this problem would be to edit the cart.php (might be a differnt name) and to have an if statment like:'

if cart is empty then emptybasket();

emptybasket() being what ever function is called by pressing the empty basket button, as doing that usually fixes the problem (but not allways from what I have read).

My theory is that this would cause the customer to have the problem the first time, but then they would be able to then go back and it would work (instead of now, how the customer can keep going back and trying again, but the same thing happens).

Somebody want to test this out and see if it helps?

[Guest vinyltrendz]

i get 2-3 emails a day with this problem. Its annoying for cart members that get good amounts of orders a day.

[Guest ColeFlournoy]

i get 2-3 emails a day with this problem. Its annoying for cart members that get good amounts of orders a day.

Have you had any luck figuring out exactly what steps cause the problem?

Cole

[Guest vinyltrendz]

Yes.

USING CUBECART VER. 3.0.12

USING INTERNET EXPLORER 7

on shopping cart. www.jdmdecals.com

Site works flawless when the cookie setting is on:

ACCEPT ALL COOKIES and LOW

When the Privacy bar is moved up to Medium this is when it drops products from the shopping cart. if you click add to basket nothing will stay in the cart.

[Guest CheapScotsman]

Low:

• Blocks third party cookies that do not have a compact privacy policy
  
• Restricts third party cookies that save information that can be used to contact you without your implicit consent.
  

Medium:

• Blocks third party cookies that do not have a compact privacy policy
  
• Blocks third party cookies that save information that can be used to contact you without your implicit consent.
  
• Restricts first party cookies that save information that can be used to contact you without your implicity consent.
  

From the help file:

First-party cookies come from the website that you're viewing and can be either persistent or temporary. Websites might use these cookies to store information that they'll reuse the next time you go to that site.

Since we are dealing with the cubecart basket, it should be a first party cookie.

==================================================================

Hmmm … my default in IE7 is medium and a quick test on my system indicates that changing this does not affect the ability to maintain the cart (even after closing IE and coming back in again).

[KirkM]

One client's store is getting 3-5 PHONE CALLS per day about this. I'm getting as many emails from customers of that same store using the "website issues" link. I can't imagine how many people are simply giving up and leaving the site. The store is 3.0.14.

I have another customer's store who has the same problem with about the same frequency. That one is 3.0.12. Version 3.0.14 supposedly had a fix to the sessions.inc.php script that stopped some session bug, but it didn't seem to stop this issue.

It's a moving target. I used to be able to duplicate it but since I have done the Empty Basket and registration workarounds, I can't get it to misfire on FF 2, IE6 & IE7. Unfortunately, the client who owns the store gets it to happen every time they go to check. They were on IE6 and then upgraded to IE7 and it didn't help. They even dumped the cookies and cache and it still did it to them.

I had one customer email me who said if he lowered his settings to low as described in the previous post, it worked. Sorry that's all the info I have from my end. I have been dealing with this problem since mid 2005 and am hoping one of the sharp minds out there can crack this case.

Thanks everyone for your generous efforts.

[Guest Geraint]

There are 2 potential problems I have identified with session cookies and possibly with https - I'm having problems with my Zend Debugger at the moment so can't confirm the SSL problem.

1. I summarised the problem with the session cookie in another post (http://www.cubecart.com/site/forums/index.php?showtopic=24195) - the fact that the sesion cookie path is always ending up as "/" could cause problems for sites where the cart is installed in a subdirectory.

A order simple switch is not actually the solution - the key code that's in the wrong place is :

// get paths and dirs

if(detectSSL()==TRUE){

$GLOBALS['rootDir'] = $glob['rootDir'];

$GLOBALS['storeURL'] = $config['storeURL_SSL'];

$GLOBALS['rootRel'] = $config['rootRel_SSL'];

} else {

$GLOBALS['rootDir'] = $glob['rootDir'];

$GLOBALS['storeURL'] = $glob['storeURL'];

$GLOBALS['rootRel'] = $glob['rootRel'];

}

2. There's also some dodgy code w.r.t. SSL at line 120 of functions.inc.php. The code should read:

if((!ereg("ccUser",$_SERVER['PHP_SELF']) && !ereg("/admin/",$_SERVER['PHP_SELF'])) && !empty($_SESSION['ccUser']) && $storeURL!==$storeURL_SSL && $config['ssl']==1){

$params['ccUser'] = $_SESSION['ccUser'];

}

I don't know my way around the code enough to confirm the exact behaviour this error would cause but it suggests to me that when the cart switches to SSL on some servers the sessions won't match and the cart will appear empty. It would all relate to whether you logged in under SSL or not.

I hope this helps.

[Guest Geraint]

USING INTERNET EXPLORER 7

on shopping cart. www.jdmdecals.com

When the Privacy bar is moved up to Medium this is when it drops products from the shopping cart. if you click add to basket nothing will stay in the cart.

This is caused by the 3rd party cookie constraints in MSIE medium setting

If you cccess the site via

http://blort.org/~itrendz/vinyltrendz/v3/index.php

and it works fine with Medium cookie contraints

Why is this site in a FRAME?

[Guest vinyltrendz]

my friend offers me free free hosting. unlimited space/bandwidth... hard to say no to that. I have no idea how to setup the hosting so its not in a frame.

[Al Brookbanks]

I'm surprised by this thread as since v3 has been released I would say I've has probably 2 or maybe 3 tickets about issues such as this.

I can ONLY take findings seriously on unmodified stores.

@bholland - The mods you have installed are quite hefty and could easily cause the problem.

If anyone can show me/us is this can be replicated on our demo store or a clean install on different domain/hosting account I will take it seriously.

If it turns out to be due to a browser security setting that is higher than default or a 3rd party security software running on the server there may be little that can be done.

I know ZoneAlarm has caused problems for people in the past. Please don't think I'm trying to pass the blame it's just that everything needs to be considered and to think out of the box.

[Al Brookbanks]

To try and replicate this the following needs to be done.

1. It has to be a fresh install of CubeCart 3.0.14 with no mods in every case.

2. We need to test an install on the root of a domain and folders off a domain.

e.g. http://www.example.com/index.php as well as http://www.example.com/store/index.php

3. Try to see if there is a correlation between whether this happens with SSL on or off.

4. If there is a correlation with SSL on or off we have to look to see if the SSL domain is the same as the standard domain (for shared certs).

e.g http://www.example.com and https://www.exampe.com

or

http://www.example.com and https://sharedssl.hostingcompany.com/~user

5. Test different browser security settings in 1-4. Low/Med/High and possibly custom.

6. Look at any oher security software on the client machine. e.g ZoneAlarm / Norton Security Suite etc

Can't think of anything else. :-/

[Guest gwyneth]

4. If there is a correlation with SSL on or off we have to look to see if the SSL domain is the same as the standard domain (for shared certs)

5. Test different browser security settings in 1-4. Low/Med/High and possibly custom.

6. Look at any oher security software on the client machine. e.g ZoneAlarm / Norton Security Suite etc

Can't think of anything else. :-/

Re all of those: shared certificates can totally confuse some browser settings by changing the URL on the session cookie.

Even non-shared certificates can do this if you haven't changed every internal link to the secure location, an excellent reason for running the test with a non-modified version.

Some 'privacy' settings, extensions, and programs also react in a way that seems 'unpredictable', but really isn't. The client machine might have some kiddy-guard program in place--some of these get hyper vigilant about browser actions, and apparently some also trigger blocks based on words the (adult) user has configured in, such as 'credit card', 'addresss', etc.

Several privacy programs are very aggressive about managing the cookie data, to handle all the junk and multi-domain garbage that, um, porn sites leave behind (not that the client has installed one for that reason, but many privacy customers do, so the programs are designed with them in mind). Some will wipe out cookie data the instant the browser visits another URL, which would include switching to the SSL https.

Since the 'custom' zones/levels in IE are simply user-chosen mixtures of the various levels, they could also be at fault; if it's determined that something in one level is causing it but not another, that option could cause it in 'custom'. (I tried rephrasing that paragraph three or four times so I hope my meaning is understandable.)

If the problem happens with browsers' default, just installed settings, it's more likely to be something in the Cube or shop end...if it doesn't, look there or any other internet-related programs on the client machine, not just the obvious security and virus programs.

[Al Brookbanks]

I agree with your points gwyneth there are quite a lot of variables here.

[Guest Scart]

Has anyone resolved this issue I am still getting called from people that can use the shopping cart and that defies the purpose of having on online store if you have to take phone orders... I am using version 3.0.12

I agree with your points gwyneth there are quite a lot of variables here.

[Guest gsnet]

Same problem as most of you guys. However I do know what is causing the empty cart:

* The problem is only caused when SSL is enabled.

This is because when the customer views the cart they are viewing it under SSL.

A customer goes to http://www.yourstore.com and buys a pair of socks. The item is added to the basket however when they go and view the basket they are actually viewing https://yourstore.com which means the cart is empty. Then they click 'Homepage' and it takes them to http://yourstore.com they then buy the same pair of socks however this time when they view the cart the item is there!

Effectively you are running two stores when SSL is turned on meaning that an item has to be added in both for it to exist in the basket.

Hope this makes sense. Just need someone to find the answer!

[Guest]

Okay, just replicated it (see, I told you it was easy...first try! - not actually excited by this...)

Browser: FF 1.5.0.8

Mods: SEF URLs, Estelle redirect to basket

login status: Not logged in

I didn't do anything to the cookies in my browser, but have visited the site before...The very first time I land on the homepage, then click to a product page, then "add to cart" (and am subsequently redirected to the cart), viewing empty cart.

The issue went away when I clicked "Homepage" in the left nav and repeated the process.

Anyone else?

I was also having this problem and in my case have found it to be related to the sef urls mod. For those of you who have this mod installed, this may be a solution for you.

Here's what was happening with my cart...

When you enter the site from the index page of the cubecart, a site-wide cookie (path of / or / shop) is issued and everything works normally (You also will get the same cookie if you go to view cart). But if you enter the site at another page (ie a view product or view cat page) from a google link or something, you would not get the site-wide cookie but rather a category/product specific cookie (path of /shop/category1/product1 etc.) that is only good for that category or directory. When you go to a new category, you get another cookie as if you are a new customer again (shop/category2/product2). You would keep getting new cookies with each category and each cookie would hold it's own information (ie shopping cart contents), thus the fluctuation of cart contents. Once you visit the homepage or the view cart, you get the site-wide cookie and the cart starts working from that point on.

I installed a fresh 3.0.15 cart and the problem went away. Then I installed the sef urls mod and enabled it and problem returned. So I investigated the files that were changed with the mod that were related to sessions and think I found a fix. I am no expert, but this has solved the problem for me. I have told rukiman about the problem and he is looking into it. Maybe he will have a better solution, but so far this seems to be working on my cart.

To see if this is happening to you, erase all your cubecart cookies and enter your site from a category or product page (without visiting the index or shopping cart). Keep your cookies window open, then click on some other categories and see if you get multiple cookies as I described.

Here's what I did to correct the problem:

in sessionStart.inc.php:

@ini_set("session.cookie_path",$sessionDomain);

Replace $sessionDomain with your cubecart directory ("/" or "/shop" etc). Mine looks like this now:

@ini_set("session.cookie_path","/shop");

Or if your cart is at the index of your site then:

@ini_set("session.cookie_path","/");

in session.inc.php:

// set cookie to extend expire time meaning if the visitor visits regularly they stay logged in

setcookie("ccUser", base64_encode($sessId),time()+$config['sqlSessionExpiry'], $sessionDomain);

Again, replace $sessionDomain with the same "/" or "/shop" whatever directory your cubecart is in.

Delete your browser cookies and test your cart again.

Like I said, I am no expert, but this fixed it for me. If anyone sees a potential problem with these changes, please let me know. Oh, and I don't use SSL, so I can't comment on that, but maybe it's a similar problem/solution?

[Guest]

I've been having this same probblem- I got 9 calls today about this. In the motorcycle biz, you only get one shot so I assume I am losing quite a few sales because of this. We are very busy- I think the high traffic may be making it worse.

[Guest conspicuouschick]

I had my first report of this issue a couple of days ago.

I don't have the mod mentioned as a possible culprit.

When it happens, you can't help but wonder how many other customers you've lost because of this, and reading posts by a seemingly unconcerned CC developer's on this thread really doesn't provide much in the way of consumer confidence.

Thanks everyone, who IS trying to find the origin and solution to this problem.

[Guest stu2008]

I am having a similar problem but ONLY in firefox. Latest version of CC installed with no mods. Customer adds items to basket, logs in or registers, then reviews basket (all items are there still) then chooses PayPal as gateway (only gateway i have) but when passed to the paypal page the cart amount shows 0.00 (empty). In IE7 this is not a problem, it works fine. Only in FireFox this is a problem - i can't work it out. Someone please help.

[Guest Lynne Veness]

Hello,

There is a huge number of threads in this forum relating to an unresolved issue that is causing a lot of issues for many cart users and because this issue has been around for so long and is not recognized as an issue by the developer – this problem is hurting the cube cart community overall.

The issue is – some (but not all) customers add an item to their cart and then go to checkout and the items have disappeared. The can continue to add items and try to check out, but they are unable to do so unless they do a “workaround†as listed in other posts.

But forget all the debate of whether this is an issue or a bug or if it’s not. We have recognized that this clearly is an issue affecting at least some portion of cube cart installs. My personal opinion is that this is a problem effecting all cube cart stores, but because most cube cart stores don’t have a large number of sales, they would rarely see it come up – and if it did just attribute it to the customer doing something wrong.

So – let’s find a solution. I will personally debug this code to try and find a solution – but the first step is recreating the problem. I have so far, been unable to figure out what exact steps are taken to cause the problem. I only know that from about 100 orders, there are consistently about 5 or so people (at least) that have run across this problem. Most likely those 5 people are just adding items to their cart in some specific way that causes the error. Whether you have any programming background or not – you can help solve this problem just by trying to figure out what is causing it. So please, if you have had (or think you might have had) this issue come up – test your store and see if you can recreate the problem and make sure to document all steps exactly here.

Thanks,

Cole