Just a quick note here. If you are running ColdFusion and you know that your bindings are set up correctly, but web requests being sent to the default root of websites on your server other than the intended one, it it highly likely that the “Cache web server paths” option was mistakenly (or unwittingly) set, causing all manner of havoc in directing among multiple sites.
Turn it off, restart the ColdFusion Application Server service, and enjoy proper web routing once again!
I have been converting applications from ColdFusion 8 to CF 11 over the last several months, and some of the challenges have been quite a bit more daunting than this one. Even so, I felt this was worth mentioning.
After copying all the code for my most recent upgrade candidate from the old server to the new one and setting it up in IIS, I proceeded to set up the CF Scheduled Tasks on the new server.
One of the tasks that I set up runs under a blank user name. In order for that to work, you have to make certain that several settings related to authentication are set properly in IIS. First of all, if the app as a whole runs under anything other than Anonymous Authentication (such as Windows Integrated Authentication or Forms Authentication), your Scheduled Task URL will have to be inside a folder that has Anonymous Authentication enabled, even if it’s turned off for the rest of the app.
Secondly, you have to make sure that the “jakarta” virtual folder that is set up during IIS configuration of the website also has Anonymous Authentication enabled.
Having Anonymous Authentication disabled on the jakarta folder will cause no end of irritation if you don’t have the output of the URL sent to a file, as neither the application log file nor the Security log in Windows Event Viewer will tell you exactly why the task is failing. If you send output to a text file, you can rename that text file with an HTML extension (I’m still not sure why Adobe doesn’t just allow output as HTML for this…) and then see more clearly why your task was failing.
So set your authentication properties correctly to avoid this frustration!
I’m still working on upgrading some older CF8 applications to CF11. I came across an interesting problem, the exact cause of which I have not found, but I do have a solution of sorts.
When the particular application I’m working on now was written, the standard browser that would be accessing it was Internet Explorer 8. Over time, as we have upgraded our browsers, but not had time to make changes to the application to accommodate those new browsers, we had used the dreaded Compatibility View to keep the look and feel of the application unchanged.
This is the result:
After stepping through the code using Internet Explorer’s Developer Tools, I determined that the reason this “createCFWindow” function threw an exception was because the ColdFusion.window.create function was returning null rather than a new window.
When testing the website on Chrome – which this application was not designed to use – I discovered that the error did not occur, and decided to turn off Compatibility View. Sure enough, this error disappeared in IE 11 – though a host of other issues have now developed.
Now, I’m working to upgrade the application to be HTML5-compliant so it will work on IE 11 or Chrome.
This is a quick change that is easily missed when adding AJAX functionality to an old ColdFusion site with CFAJAX tags. In my case, I was adding this functionality to a site that had originally been developed about ten years ago. This site runs on a Windows server with IIS.
After getting the site upgraded and working properly in the dev and test environments, I discovered that several errors were happening in prod that never happened in test or dev. The most common of these errors was “Coldfusion is undefined”.
Of all things, the Virtual Directory to CFIDE had never been created. As is so common, major problems can be caused by tiny bugs in code, or in this case, in the Web server configuration itself.
Create a Virtual Directory in the root of the website and name it CFIDE. It should, in most cases, point to C:\inetpub\wwwroot\CFIDE. Once this is done, the CFAJAX errors should be no more!