Data Center Hub

Have you recently installed Google Analytics to your site and found CartIt is broken?

If you visit a site which uses the CartIt shopping cart and has the Google analytics code (urchin.js or ga.js) installed you will get several cookies. One called __utmz breaks the ability of CartIt to read it’s own cookies because years ago, when Urchin first started using JavaScript cookies, the coder (or pointy headed boss) did not follow the standards (well, they were only suggestions and still are such). Standard cookies use the equals (=) sign as a delimiter so if the cookie contains multiple equals the application attempting to read the cookie mail fail if it was never intended to read this non-standard cookie.

RFC 2109 (the original Netscape proposal) lists a name=value pairing with “The VALUE is opaque to the user agent and may be anything the origin server chooses to send, possibly in a server-selected printable ASCII encoding”

So when Google is using characters which are also delimiters in cookie text, they should escape them using URL encoding such as “%3d” but they did not. The cookie is broken and has been for years, apparently there is no intention of correcting this as the newer analytics code (ga.js) creates the same broken cookie.

Unfortunately, when this __utmz cookie is set, it is set for *.domain.com, which is the same as what cartit sets. When your browser sends your broken __utmz cookie to your server, your shopping cart, cartit.cgi, creates a new shopper cookie and because it cannot match up the shopper (you) with a cart cookie, it makes a new cart cookie with your one item. So the result is only one item in the cart period until you remove the Google code, or “fix” the cart and then CLEAR all the cookies for the domain.
I have “fix” in quotes because the CartIt shopping cart is not really broken, cartit is a victim of Urchin/Google poor code. If the designers of cartit could have anticipated someone would:

1. Intentionally create software to create a cookie which appears to not URL encode field delimiters e. g. (=)

2. Intentionally install this broken software to create a cookie with invalid characters, thereby shooting you in the foot and breaking your ecommerce site

Why doesn’t google fix this? Well, there are many more people using Urchin than CartIt- and all you need to do to fix cartit is modify the cookie reading code on line 927 of cartitlib.cgi so it is straight-forward if you know PERL. This is not simply a cartit problem as there are doubtless many other programs which could be affected- anything on your server which reads cookies could choke on the __utmz broken cookie.

Here is an example of what the __utmz cookie contains

__utmz=247895813.1206552801.1.1.utmccn=(direct)|utmcsr=(direct)|utmcmd=(none); path=/; expires=Thu, 25 Sep 2008 05:33:20 GMT; domain=domain.com;

So it is fixable- but it’s an unfortunate fact poor code never seems to fade once implemented. In the end, you’ll likely have to pay someone to fix your (not really broken) cartit code. After all, the Google code is free- and it is worth having on most ecommerce sites- but you don’t need to change your site shopping cart as a result.

CommerceBuddy Version 3.0 for CartIt 8.0 was released in 2003 and while not designed for Vista, you should be able to make it run with a few tweaks. CommerceBuddy was designed using Delphi tools, when it runs it creates a small file called PDOXUSRS.NET at c:\. Because the new way of running programs with Vista is a user mode with limited permissions, you’ll need to run the program with Administrator privileges. If you do not run it this way, you’ll get an error of “Permission Denied” on creating the PDOXUSRS.NET file.

It is easy to fix this by simply browsing to the CommerceBuddy program under StartàAll Programs. Right click the CommerceBuddy Program, point to and select Properties. When the CommerceBuddy Properties box appears select the Compatibility tab and under Privileges, tick the box labeled “Run this program as Administrator” in order to allow you to run it. You will likely get a nag screen at each invocation and the program will now run.

Another issue on Vista is the use of .hlp help files. CommerceBuddy has no printed manual and therefore without the help you will have trouble learning how to properly set up CommerceBuddy. Microsoft has a KB article on this- KB917607 but unfortunately at the time of this writing it appears they have removed the link to the file download and simply have a terse statement “the Windows Help program has not had a major update for many releases and no longer meets Microsoft standards. Therefore, starting with the Windows Vista operating system release, the Windows Help program will not ship as a component of the Windows operating system. Also, third-party programs that include .hlp files are prohibited from redistributing the Windows Help program together with their products”

I found the download of the Windows Help Program (Winhelp32.exe) for Windows Vista 32 bit version thanks to Google. Once you install this update you should be able to use the help files in CommerceBuddy as well as any other legacy applications.

Of course, if you’re doing a new install of CartIt CommerceBuddy, you have to apply your license (under HelpàAbout), set your options and configurations, and finally publish the setting to CartIt on your server. CommerceBuddy is starting to show its age but the CartIt application (server side) itself is written in Perl and is still one of the most flexible (and eminently customizable) carts I’ve ever used. CartIt has features no other cart has- such as the ability to have products at a zero price, unlimited products with unlimited options, and much more. Also, being forms based means you design ecommerce around the site rather than forcing you to design your site around the shopping cart.