Jun 9th 2009 × CubeCart problems: no shopping bakset and login functionality for some users
There’s yet another one of these problems that are inherently weaved deep into CubeCart that you just wouldn’t know about… It displays different versions of pages to search engines and to humans, namely–it disables the shopping basket and checkout functionality as well as the login and registration.
First of all, needs to be said that troubleshooting this and finding the reason for users being unable to purchase off a CubeCart site is an absolute nightmare. When a customer says they use ‘bog standard’ IE8 and report their ‘add to basket’ button doing nothing whatsoever, one tends to think ‘has the javascript handler gone wrong?’. You go on a wild goose chase, trying to reproduce the problem and failing despite of installing various javascript exception tracking modules, looking through logs and quizzing puzzled shoppers. All the while, you can’t help but wonder about the possible extent of the problem, how many users get this? And then – you catch a break by accidentally discovering customers unable to purchase also lack the login/register links – time to start connecting the dots…
From session.inc.php, which controls the login / register links in CubeCart:
if (!$cc_session->user_is_search_engine() || $config['sef'] == false)
The template does not get shown to search engines? That makes sense… having different versions of pages shown to users and to spiders is not only a bad practice (google really don’t appreciate “cloaking” techniques), there is just NO need for it whatsoever. In order to prevent spiders from indexing pages that are deemed irrelevant to e-commerce and spill page rank / relevance, they could have been disallowed from within the robots.txt file. A rel=”nofollow” could have been applied to links to such pages… but what have the clever folks at CubeCart done instead?
They created a boolean method into the sessions class that decides if the user is a bot or not, user_is_search_engine(). It does so by comparing the contents of a file called spiders.txt, filled with “known” extracts from the user agent strings of various spiders from around the web, against the user agent string of the visitor. To be fair, the original idea for this kind of testing comes from OS Commerce…
The problem is when a legitimate customer is being discarded from using the site’s e-commerce because their user agent string is customised in a ‘bad’ way. How does that work? The original CubeCart spiders.txt file has lines that reject things like:
‘googlebot’ but also just ‘google’,
‘msnbot’ but also just ‘msn’
And so forth… multiply by x number of toolbars and custom strings CubeCart may never know about and you have a HUGE problem. For instance, users with Google Desktop get their user agent string set to Mozilla/5.0 (compatible; Google Desktop) so they promptly get rejected. Luckily, that’s not a very popular application but the “MSN” string and the absolutely COUNTLESS numbers of people that have got a user agent string like this one: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; Sky Broadband; GTB6; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; InfoPath.2; .NET CLR 3.5.21022; MSN OptimizedIE8;ENGB) presents a VERY real problem. MSN optimized IE8? Not on my shop site, mate.
edit: check your spiders.txt version, if it predates august 2008, you are affected.
I have been looking at the user sessions table and have thus far found over 3000 genuine users that have been rejected by CubeCart’s loose user agent matching routine. That’s a lot of business to lose and the store owners are understandably upset. It’s not free software and at a testing time like the credit crunch we’re enjoying, having your own store work against you is far from ideal. The real frustration comes from the fact that people had reported an intermittent loss of shopping cart functionality on the CubeCart forums and on their bug / ticketing system. Reported and dismissed – apparently, too difficult to trace or unsupported due to store being customised. Every programmer makes mistakes, but being unable to rectify them and failing to provide support to your paying customers – it’s just bad business. I am sorry to say, CubeCart has failed to impress once again…
The fix to the CubeCart user agent problem:
1. apply nofollow to the links for login, register and checkout
2. empty the contents of spiders.txt in your cubecart root folder (don’t delete it)
or
2. change user_is_search_engine() to always return false.
To test if your store is affected, use FireFox and check this post on how to change your user agent string, set it to the one I put as an example above and visit your shopsite, then try to add a product to your basket.
update: I am being told that this problem is no longer to be found in current releases of cubecart. Well done, the team 
Now, how many existing customers on versions pre-dating august 2008 have been notified?
7 Comments to CubeCart problems: no shopping bakset and login functionality for some users
Hi
It is great that people review commonly available products and spend time writing about their experiences. However it is a real shame that before publishing a negative article like this that you havent done a bit of basic research.
Yes there was a problem that caused this error and it could obviously have been causing lost customers which is never good. However, it isnt difficult to fix has not been rejected as such by the people at CubeCart. When doing your testing, please at least try to use the latest version available. A simple check with the people at CubeCart would have given you all of the information regarding this
regards
Ian
erm, this is not meant as a product review, on the contrary, there’s a very real merchant running cubecart that got a very real problem. and then, there are posts like this one, in addition to the tickets being raised: http://www.cubecartforums.org/index.php?showtopic=592&mode=threaded&pid=2572 – reported over 2 years ago and without a solution. How many posts and searches later do you need before you can deem something problematic? I really cannot comment on how recent a version this shopsite is running, it’s whatever was current around mid April 2008. If you are saying this has been rectified in a later version, then perhaps it should be made clear in the changelogs… – http://forums.cubecart.com/index.php?showtopic=38542 – “bugs fixed” doesn’t cut it.
So you’re using a post that is more than two years old (May 2007) and is using version 3 (when they are very soon going to be releasing version 5) to put down CubeCart ? I am not connected with CubeCart but have been using the product myself for 5 years and installing and supporting others through my hosting business (www.havenswift-hosting.co.uk) for 3 years and would not have stayed with it if it was anywhere near as bad as you infer.
Of course everyone is entitled to their own opinion but at least try to keep it based on a current version of the software and backup your allegations with specific facts
it’s 4.2.0 and the install is about an year old.
I am not basing this on any posts, but on my own experience – the posts I found later on whilst looking for others experiencing the same issues. as you say, cubecart is not THAT bad, if one doesn’t care if their store does the best possible job and have plenty of CSA time to spare whilst using cubecart’s cumbersome orders system. In fact, your Average Joe would not be able to identify and deal with bugs such as the spiders.txt one or the ‘customers who also bought’ performance degradation–and they shouldn’t have to, in my opinion.
[...] have found a solution thanks to this post at fragged.org which fixes the problem by emptying the spiders.txt file in the web root. We have [...]
I’m a big fan of CubeCart but appreciate that ecommerce applications are different things to different people. I wasn’t aware of this potential bug with 4.2.0 and whilst none of my clients are on versions that old, it’s good to know what bugs have existed, which were fixed and which remain!
Thank god for this blog post is all i can say. I run a digital store and get hundreds of orders a month and I have at least 20 people contacting me saying that cant freaking login…register…add to basket!!! And im running 3.0.19. So ive got the free version..it does it too. Interesting to add though. ITs really mostly Rukispot’s SEO mod that he offers that is the damn culprit. Yeah its nice..but jesus..fix the effing thing to not have this issue..I’m having several of my clients now test a second store setup just for testing this change to see if it indeed fixes it. I have tried everything and now I notice that free cubecart unlike cubecart4 doesnt come with rukispot’s mod already installed. CC$ has it built in. CC3 doesnt..you have to buy it. Then you have a spider.txt file to edit. I deleted everything inside. These modders of cubecart piss me off to no end as does cubecart which is exactly why ive decided to write my own cart software. Cubecart can just go suck it.
Would you like to leave a comment?
You must be logged in to post a comment.
