cf_ezcart ColdFusion Shopping Cart Application
General ColdFusion MX Development Issues

As with any new software product, there are bound to be different behaviors, unforeseen issues, etc. Below are a couple that plagued us that we have since fixed. For example, when ColdFusion moved from version 4.0 to 4.5, Allaire (the company that originally developed ColdFusion) introduced mandatory CFLOCK-ing along with the "scope" variable. Adding the scope variable caused errors in 4.0. Not adding it caused errors in 4.5. Annoying, but plain to see.

ColdFusion MX has also introduced some different behaviors. Some of these may adversely affect your pre-MX built applications, and may also affect the way you must program in general. The problem is, some of these behaviors are NOT so plain to see. Hence this page, which we have geared toward helping the ColdFusion community. Here are some issues that have arisen in the process of assuring that cf_ezcart is ColdFusion MX compatible. We will add to this page if and when we find other issues. Hopefully that is never.

For the non ColdFusion developer types reading this, please don't take this page as a knock on ColdFusion. As a whole, ColdFusion is still as powerful as PHP, ASP, .NET, etc. have ever been, and even more so with the release of MX. Especially for what we do, which is building affordable solutions for the small to medium sized business. Development and maintenance time for ColdFusion solutions compared to other solutions is generally in the 33% to 50% range. This means that it's going to cost you 2-3 times as much to build your application in PHP or ASP, and again, 2-3 times as much to maintain and update it.

• Client Cookies - This one is a little long, sorry. It deserves an explanation though. By default, when setting setclientcookies="yes" in the cfapplication tag, ColdFusion sets a cookie that never expires. Several versions ago, we began setting these cookies manually to expire in 1 day due to occassional login issues. At the same time, we began to set a "control" cookie with the current date and time to check when these cookies were set. If this control cookie was older than 24 hours, or didn't exist at all, we deleted the CFID and CFTOKEN cookies. We would do this immediately before the cfapplication tag (the point at which client.cfid and client.cftoken are created if they don't already exist for the current user). Immediately after the cfapplication tag, we reset new client cookies, along with a new or updated control cookie, which was again set to the current date/time.

  In versions prior to CFMX, this worked wonderfully. ColdFusion would read the CFID and CFTOKEN from the cookies being deleted (they would still exist at this point), see that the empty values had no match in the clientstorage datasource, and create a new, unique client.cfid and client.cftoken. Right after the cfapplication tag, we would recreate the cookie.cfid and cookie.cftoken and set them to the values of the new client.cfid and client.cftoken. The code looked similar to this:

  <cfcookie name="CFID" value="" expires="now">
  <cfcookie name="CFTOKEN" value="" expires="now">

  <cfapplication
  setclientcookies="no"
  etc...>

  <cfcookie name="CFID" value="#client.cfid#" expires="1">
  <cfcookie name="CFTOKEN" value="#client.cftoken#" expires="1">

  Amazingly enough, ColdFusion MX will actually take those blank variables and add a record to the client storage datasource with blank cfid and cftoken values. Now everyone that this happens to is sharing those same client variables. Application sufficiently "fried".

  We have now stopped deleting existing client cookies before the cfapplication tag. We also no longer set the control cookie. What we do is check for the existence of the control cookie, and if it does exist (meaning the user was here using an older, perhaps problematic version), we delete it and reset the client cookies as "session" cookies, meaning they will expire when the browser is quit or exited. This will still allow sessions to remain alive if the person leaves the site and returns, or goes to a non CF page and returns, as long as they haven't quit their browser. This may also allow the client cookies necessary to keep the session alive to be set more readily for folks using IE 6 with it's new, more restrictive default security settings.

• CFFORM - What a mess Macromedia has made of CFFORM. Admittedly, as a developer CFFORM is an "easy way out", but when we began this application we were very green to ColdFusion and used CFFORM extensively. But it has always served it's purpose well, until MX. Here are the issues (that we are aware of) surrounding ColdFusion MX and CFFORM.

  The default javascript functions used by CFFORM previously loaded right into the header of the .cfm template containing the CFFORM. In MX, Macromedia decided it would be wise to call it using a source file instead of loading all that code directly into the page. While this is a good idea in theory, they gave the developer no way of specifying where that source file may be, but rather call it with a relative path from the "server's" web root as "/CFIDE/scripts/cfform.js". The problem with this is, the vast majority of ColdFusion sites are running on virtual hosts on shared servers. So by default, there is no "/CFIDE/scripts/cfform.js". This is easy enough to fix on the main hostname (see below) as we just include a "dummy" CFIDE/scripts directory containing the files from the ColdFusion MX installation.

  What do we mean by main hostname above? Simple. If your domain name is mywidgets.com, "http://www.mywidgets.com/" and "/" will be pointing to the same place, relative to the files in your web site's directory (web root). Many, if not most copies of cf_ezcart are installed using a shared SSL certificate. So, the path to your website under the shared SSL will be something like "https://ssl.yourhost.com/mywidgets/". When beginning checkout and moving to the secure URL, the relative "/" no longer points to the directory where your web site is, "/mywidgets/" does. "/" points to the default directory that "ssl.yourhost.com" is mapped to. You won't have access to this, and from what we've seen, most CFMX hosts have not taken it upon themselves to place a "CFIDE/scripts" directory there. And trying to explain to some ColdFusion hosts why you need them to place a CFIDE/scripts directory there is like pulling teeth.

  So, what happens if you CAN finally get all these things in place? Well, the one data type validation we use in the cfinput tags is "creditcard". This just tests against an algorithm to ensure that the person has typed in a real credit card number. We also set the "required" attribute to "no". So this credit card validation check should not kick in (and never has in the past) unless you enter something in the field. With MX though, even if you choose another payment method, and leave the credit card field blank, you get a popup saying to enter a valid credit card number. ARRGGGHHH!!!

  Consequently, we have removed all CFFORM tags that are used by the shopping cart, the checkout pages, and most of our site integration custom tags. We still use CFFORM within the administration pages, so you will probably still wish to install the CFIDE directory into you web root.

  As a desirable side-effect of this change, preliminary testing on ColdFusion 5.0 seems to show that the cflocation/header bug may have gone away with the CFFORM tags. We believe that was caused by all the excess code that CFFORM places within the <head></head> tags of the templates.