Dreamweaver not closing cfquery

We recently upgraded to Coldfusion 9 here at the office, and most of us are using Dreamweaver CS3 as our text editor of choice for CFML, which very has a nice little upgrade that will make code complete work for the new tags and the changes to the existing ones. If you didn't know about it, you can download the patch here.

After I applied the patch I started noticing that the code complete would not auto close a cfquery tag, and would in fact, auto close the parent tag. This was highly annoying behavior that easily goes unnoticed during rapid fire coding and results in instantaneous bugs. I have Dreamweaver set to auto close a tag as soon as I type </ which made this even more annoying as a quick attempt to properly close the cfquery tag, would just result in another wrong close tag being inserted. So I would have to carefully highlight everything after </cf and type in the rest. Fatal bug? No, but after three or four times, annoying enough to need immediate change.

Of course it's not obvious what the bug is, so I have to sort through a lot of results thrown back from the search engine before finally finding a forum post from someone going by the name 'Krakajap' who figured it out. He got me pointed in the right direction, but his solution was a little excessive and I figured out a simpler way to do it.

The problem is a typo in the config files for Dreamweaver. You can find all the xml files that tell Dreamweaver what to do with tags at approximately:
C:\Users\[you]\AppData\Roaming\Adobe\Dreamweaver 9\Configuration\TagLibraries\cfml
or wherever in your OS Adobe sticks these folders. You will see a htm and vtm file for all your cfml tags. You want to edit the vtm for cfquery. You'll see the problem right away on line two. Just change:

<tag endtag="no" name="CFQUERY">

to:

<tag endtag="yes" name="CFQUERY">

Restart Dreamweaver and away you go.

Coldfusion 9 Fails to send mail when using cfMailParam to set the content type to text/html

We recently upgraded to ColdFusion 9 and have had our share of migration pains. Today I discovered a new one. We have a newletter that goes out on a fairly irregular basis and today was the first one since the migration. Hours after it was scheduled to be released I got notified that no-one has received it yet. So I check the undelivered mail and yup, there are almost 4k messages that ColdFusion refused to send to the mail server.

As Sherlock would say, the game is afoot. First, let's rule out the most likely suspects. Looking at the mail log, I see errors for them all, but the error message is blank. I check the mail server connection, it's fine. I try dropping a few back into the spool, but they just get kicked back to undeliverable. I check the SVN logs and see that no code changes have been made to the file involved. Great, not going to be an quick and easy bug hunt.

Interestingly, while looking at the undeliverables, I was still able to see messages hitting the spool and processing normally. Thinking to myself, "what makes them different" I manage to open one before it processes out and start to compare it to the ones that won't. Fortunately the difference was on line one: the ones that won't sent say "type: text/html" the ones that will say "type: text/html; charset=UTF-8". So I change that line on one of the failures, send it back over to the spool, and it processes normally. Great! Fix it in all of them, send the batch over to the spool and we are in business.

But why did this happen?

I pull up the code for the mail that went through fine, and for the one that didn't and look at the cfMail tag. and here is the big difference:

Good:

  <cfMail [typical settings] type="html">
    Mail Message
  </cfmail>

Bad:

  <cfMail [typical settings] [no type attribute]>
    <cfmailparam name="content-type" value="text/html">
    Mail Message
  </cfmail>

The bad code here worked fine in CF7, but just results in undeliverable mail in CF9. I can't tell you why, but hopefully my investigations help save someone out there some time.

WTF Users?

So today I was again reminded that users will do things that I, as a developer, would never think of doing. And of course they either don't remember how they got into their predicament, or refuse to tell. Today's conversation went something like this:

User: It's broke.
Me: Which browser?
User: IE.
Me: (internally: Noooooooooooooooo!) Seems to work okay on my end, which version of IE?
... insert some back and forth while I guide the user into determining the version, and which browser mode and document mode is currently active...
Me: Still seems to work fine, see what happens in another browser.
User: How do I open the page in another browser?
Me: Open browser, copy address from IE into other browser.
User: When I copy the address, it looks like it has a lot of question marks in it.
Me: Interesting, IM that over to me.
User: "http://www.webaddress.com/folder??x=y?x=a?x=z"

So now I'm trying to figure out how the user made this happen, and between the server log and that IM I have determined that the user made a selection, hit back, selected the null item of "please select something" before making another selection. While I couldn't believe that someone would take these steps, it did teach me to take better care what I do with my Javascript. instead of writing:

window.location += "?x=y";

I changed it to more correctly be

window.location.search = "?x=y";

Arguably I should have done that in the first place, but it took a user doing something I would never expect any user to do in order to show me the error of my ways.

The moral of the story is get the worst possible users (I'm talking about the ones that need a new PC from IT every 3 months because they have 10 browser tool-bars and a bajillion viruses and other malware installed, or they somehow accidentally deleted windows.) testing your work at the earliest possible stage. It's really the only way to fool-proof your code.