Forum Moderators: buckworks
The copany that developted the site software says the cause is increased traffic. But traffic is not that high compared to what we had before and everything worked fine.
My opinion is that there is an increase on users that are afraid of virus and other exploits, so they are disabling cookies and javascript. My site depends on cookies to handle the checkout process. That's how we know what is in the shopping cart. When cookies are disabled, we use a session ID, but this doesn't guarantee the ID won't be lost if user is browsing several sites or going back and forth on ours.
Do you guys have any feedback to help me?
Thanks a lot!
Im not too sure how youd get around this some of teh more technical bods here will be able to help, however id seriously consider terminating your relationship with your cart firm.
Appears that they didnt even bother to look for teh problem.
I just need feedback from you guys if you think my suspicion of what is causing the problems are correct?
Thanks
skuba- you don't have to settle just because they wrote your application. If you have the source code, you can ask someone else for maintenance help; if not, you can use another cart, or get someone to decompile their work (assuming that's legal).
I think your situation is an excellent example of what can happen with closed source. If you decide to change carts, definitely consider going open-source!
I suppose the only reasonnable thing to do is to ask people to allow cookies for the site at least for that session... a trivial thing to do, but I wonder how many sales were lost over this.
My site depends on cookies to handle the checkout process. That's how we know what is in the shopping cart. When cookies are disabled, we use a session ID, but this doesn't guarantee the ID won't be lost
This sounds like negligence on the part of your developers. It is entirely on-topic for your discussion. You pay them to give you a 100% functional shopping cart solution. You're not getting it.
This sounds like negligence on the part of your developers. It is entirely on-topic for your discussion. You pay them to give you a 100% functional shopping cart solution. You're not getting it.
So, please tell me how you identify what is on the users shopping cart without using cookies or a session ID? Or how you identify who is the shopper?
Thanks
Besides, we (programmers) often get absolutely ridiculous specs, and are sometimes expected to code for them despite our concerns.
And even if they did not foresee this situation, it still wouldn't be a sign of negligence. A lot of people honestly recommended such an approach.
Finally, even with good specs and no malice, bugs happen, or people forget things. We're human and no coder is above bugs.
My opinion - people should be expected to use cookies. If skuba agrees, he can ask his programmers to change the application's behaviour. You can then judge their worth by how they react to the request.
When cookies are disabled, we use a session ID
There's nothing you can do if the user comes back with a virgin URL.
If somebody wanted to buy something from you, couldn't, then bothered to email you about it they probably didn't leave your site. You can examine the server logs to see if this is the case.
I have had the same problem with a custom cart. If a user has cookies completely disabled they can't add anything to their cart, but the cart does generate and an error that informs them that they must enable their cookies. So that solves that problem.
But I still had users who got all the way through and order and when they hit submit they got an error that tells them their cart is empty. Yikes! All data gone.
My host said it was due to high traffic and suggested we upgrade our server, which we did and it hardly ever happens anymore. But once in awhile it does. I think either the server or the database hiccups... and wipes everything out.
Wackal
How hard would it be to modify our carts to issue unique ID to each visitor? Are their any cons to this route?
But I still had users who got all the way through and order and when they hit submit they got an error that tells them their cart is empty. Yikes! All data gone.
This happens a lot too. I think this is when the user was able to get to checkout carrying the info on their session ID, but then they loose it during checkout.
I agree with you skuba because we also use user sessions.
Upgrading our server did eliminate 90% - 95% of these errors. But even a few are too many. Recently, we had one client try to place a HUGE order and this happened. I felt so bad because it probably took him a couple hours of typing. Thankfully he called and he was willing to fax the info rather then resubmit. Now he will only fax because he doesn't trust our cart. Not that I can blame him.
I’d be very interested in finding a fix to this.
But then sometimes, we have 500 users and 1 of the orders will get lost because of the session ID/cookie problem.
So you guys think that increased traffic can play a strong role in those errors problems, even if normally it's not a problem if everybody has cookies?
I mean, do you think that althoug traffic is not that big or nor a problem if all users have problems, it CAN be a problem if 1 of the users don't have cookies?
DO you know what I mean?
Thanks
The cart is designed to use cookies and "fall back" to session IDs. Has it been load tested with multiple (hopefully many) ID based shoppers active? Has it been tested with many of both types of shoppers active? Has it been tested to insure it doesn't wipe out cookie based shoppers when an ID based shopper fails? And vice versa?
I guess I was confused as I thought the post was referring to a session ID stored in an ASP session. This still wouldn't work in ASP with cookies disabled and thats why I made the post about putting something in the URL. Sorry!
