This one drove me nuts.. I would consider this behavior to be a bug in CFMX and I wanted to share my experience so no one else runs into this and wastes time.
First, the server is a Windows 2k box with CFMX 6.1. I'm not sure how earlier versions of CF behave, but I would guess that they act the same.
We have 7 different sites running off of one server. In the CF Admin under mappings, we have a mapping for each site so we can use absolute paths in <cfinclude> buy saying <cfinclude template="/site1/whatever.cfm">. This is useful as all of the sites share some content that we don't want to duplicate across the sites, and each site can access files outside of its own wwwroot folder.
Now, we also have some custom UDF's defined in site1, the main site. But, it got to be a pain always <cfinclude>ing "/site1/gloablUDF/something.cfm" in every other site, so we made a mapping in the CF Admin for "/" to point to wwwroot of site 1. This worked perfectly, as now we can use <cfinclude template="/globalUDF/something.cfm"> from any site and it will pull the file off of the main site, site1. We've been doing this for a long time and haven't experienced any issues.... until...
I went to add a new mapping to the CF Admin for a project I was working on. Without really thinking, I just clicked "Add Mapping" expecting a pop-up window to appear. Of course, the page refreshed and said I need to specify a name and location in order to add a mapping. That's a big "duh" on my part, as I just glazed over the form without thinking. Ok, so now I have the form in front of me again. I fill it out to add the mapping, click "Add Mapping" and the server blows up.
Well, it didn't explode or anything, but all of a sudden all of the other sites couldn't access any of the global UDF's we defined in site 1. So what happened?
It turns out that when I submitted the empty form to add a mapping, the CF Admin defaulted it to "editing" the "/" mapping that we had for site1 - except that it didn't auto-populate the Directory Path. Because of this, when I filled out the form again and added in my new mapping, I didn't know that I was actually overwriting the "/" mapping already in place.
It was easy enough to just add the "/" mapping back, but it took me a little bit to figure out what the problem was and why it was caused. I would consider this a bug, as attempting to add an "empty" mapping should not default to editing the "/" mapping, in my opinion.
Anyway, I hope this doesn't happen to you. I'll get off the soap box now…
Leave a comment