Delbridge.Org

When moving your ColdFusion website to a commercial hosting provider, between providers or even from an internal development server to your own production server, problems may arise from inconsistencies between the two locations; problems that are most easily remedied by that proverbial, cruel, mocking "ounce of prevention."

Relocating a site between hosts already implies downtime and frazzled nerves.  The last thing you need in this situation is a slew of fresh page errors.  Here are some very simple tips for improving the portability of your ColdFusion site.

"What Could Go Wrong?"

So, what might "go boom" when moving your ColdFusion site from one server to another?  To begin with, the physical path to your hosted files (e.g., D:\my_site\www\) will almost certainly change between commercial hosts, effectively breaking any of your ColdFusion templates that employ CFFile, CFDirectory, CFDocument or any other tag that specifies a physical path parameter (e.g., "file='D:\my_site\docs\report.pdf'").

Furthermore, and particularly in shared hosting environments, popular data source names (e.g., "dsn") and mappings (e.g., "/include") may prove to be unavailable.  As such, alternates must be specified in ColdFusion Administrator, effectively breaking all of your ColdFusion templates that contain a CFQuery tag - that's most of them, right? - and any referencing your mapped directories.  For myself, that's all umpteen-thousand of them.  And that's a lot of search-and-replace.  Under duress.  Good luck.

For the purpose of demonstration, the following code snippet represents a typical ColdFusion form handler; in this case, an image uploader, as may be found on Flickr or Facebook.  In short, an image is uploaded to the server by way of a form field and its filename recorded into a database.  For tidiness, common HTML components are rendered in the included templates header.cfm and footer.cfm found in "E:\Delbridge_Org\www\include\."  Because ColdFusion doesn't allow absolute paths in CFInclude statements, that directory is mapped to - you guessed it - "/include."

In fact, the code logic is unimportant while serving up a nice example of the three common trouble spots described above.

<!--- ************************************************************* --->
<!--- Include page header                                           --->
<!--- ************************************************************* --->

<cfinclude template="/include/header.cfm">

<!--- ************************************************************* --->
<!--- Index the uploaded image                                      --->
<!--- ************************************************************* --->

<cfset Timestamp = DateFormat(Now(),'mmddyyyy') & TimeFormat(Now(),'hhmmss')>

<cfquery name="Index_Image" datasource="dsn">
	INSERT INTO GIFs (Filename)
	VALUES ('#Timestamp#.gif')
</cfquery>

<!--- ************************************************************* --->
<!--- Upload the specified file                                     --->
<!--- ************************************************************* --->

<cffile action="upload"
	filefield="form.Filename"
	destination="E:\Delbridge_Org\uploads\images\#Timestamp#.gif"
	nameconflict="overwrite">

<!--- ************************************************************* --->
<!--- Include page footer                                           --->
<!--- ************************************************************* --->

<cfinclude template="/include/footer.cfm">

When the site employing this template is ported to another host, these ColdFusion statements will require maintenance if the physical path changes - it most certainly will - or the specified mappings or data source name are already in use by another hosting customer.

"More Better" Portability

To protect ourselves, the solution is to simply encapsulate these environmental inconsistencies into variables defined clearly in your root application.cfm template and then use those variables in place of absolute declarations throughout your site.  Here's the application.cfm file we might use with the aforementioned example:

<!--- ************************************************************ --->
<!--- Define site-wide portability parameters                      --->
<!--- ************************************************************ --->

<cfset DSN = "Delbridge_Blog">
<cfset Disk = "E:">
<cfset Root = "Delbridge_Org">
<cfset Include = "/my_unique_include">

Now, the aforementioned form handler may be recomposed to look like this:

<!--- ************************************************************* --->
<!--- Include page header                                           --->
<!--- ************************************************************* --->

<cfinclude template="#Include#/header.cfm">

<!--- ************************************************************* --->
<!--- Index the uploaded image                                      --->
<!--- ************************************************************* --->

<cfset Timestamp = DateFormat(Now(),'mmddyyyy') & TimeFormat(Now(),'hhmmss')>

<cfquery name="Index_Image" datasource="#DSN#">
	INSERT INTO GIFs (Filename)
	VALUES ('#Timestamp#.gif')
</cfquery>

<!--- ************************************************************* --->
<!--- Upload the specified file                                     --->
<!--- ************************************************************* --->

<cffile action="upload"
	filefield="form.Filename"
	destination="#Disk#\#Root#\uploads\images\#Timestamp#.gif"
	nameconflict="overwrite">

<!--- ************************************************************* --->
<!--- Include page footer                                           --->
<!--- ************************************************************* --->

<cfinclude template="#Include#/footer.cfm">

...and when I decide to change hosting providers again - perish the thought - those parameters may change on me without inducing panic.  A quick update to the application.cfm file is all that is needed to morph my entire site into compliance with the host's ColdFusion hosting requirements.

Needless to say, these represent only the most common environmental inconsistencies a ColdFusion developer might stumble over.  One may, of course, carry this principle to everything from Verity and Solr collections to Scheduled Tasks - any user-defined server resource that might decline your first choice of instance names.

Lastly, this practice affords developers one additional benefit:  that of consistency.  For those power-coders who juggle many ColdFusion development projects at once, when you employ this simple strategy across all of them, you need no longer fumble for the right physical path, the right data source name or the correct mapping again.  For every site, "#DSN#" is the correct data source, "#Include#" the correct mapping, and "#Disk#\#Root#" the correct physical path.

I hope this information has been helpful.  If so, you can follow me on Twitter at @circa3000.  And please consider Circa 3000 for your ColdFusion hosting needs.  I look forward to hearing from you!