Today at work we realized that there is a ColdFusion 8.0.1 hotfix (subtly different from ColdFusion 8.0 hotfixes) that we haven't applied and would explain and resolve an issue we've been noticing.

Specifically, I'm talking about the ColdFusion 8.0.1 Cumulative Hotfix 2 which has been available since October of 2008, and blogged about a little bit yesterday, but otherwise seems to have mostly flown under the radar since its release.

Why is this update important for framework users in particular? For one of the included fixes:

Fix for memory leaks with CFCs stored in memory scopes. Note, this does not eliminate need for proper use of VAR scope in CFC methods.

This is a subtle way of saying that there are memory leaks associated with storing CFC instances into "memory scopes" (Application, Session, and Server). Every framework that I've used or looked at — and probably all of the ones I haven't — store the core of their functionality as CFC instances in the Application scope; and that means that over time (if your application lives long enough), your java heap will grow out of control and server stability will suffer.

That means if your application uses Fusebox, Model Glue, Mach II, Coldbox, ColdSpring, Transfer, Reactor, DataFaucet, onTap, Co-Op, or other frameworks, you probably have a memory leak. To be fair, it's a small leak in our experience; but a leak is a leak, right?

Left un-mended, a pinhole could sink an oil tanker.

Not just for Framework users.
Any application that stores CFC instances in Application, Server, or Session scopes would likely benefit from this update. For example, that includes BlogCFC and Mango Blog, even though neither uses a framework. Carefully consider what applications you're running or writing, and make sure you update if necessary.

In addition, there are 14 other issues that were resolved and included in the hotfix, so it's worth 15 minutes of your time to read the release notes (very brief, I promise) and decide if it applies to you.

How do I know if I already have it?
In your ColdFusion administrator, there are a few icons in the top right corner. Clicking the "i" icon shows system information. A ColdFusion 8.01 Standard Edition, with the first cumulative hotfix installed looks like this. Specifically, look at "Update Level":

After applying hotfix 2, it will look like this:

Why has it been so obscure since October 2008 (21 weeks and counting)?
There has been some speculation that its release was right around the last round of Adobe layoffs, and this may have caused a disconnect between the Engineering team and the Customer Care team, which is responsible for authoring and publishing Tech Notes. It's entirely speculation at this point, but seems possible and not at all unlikely.

Help spread the word. Hopefully, we'll eventually get Adobe to pick up the pace and list this update on the ColdFusion 8 hotfixes page.

Mango Blog 1.3 added the auto-installer, and I immediately stole Seb Duggan's style for displaying the download & install link:

Originally I used the RIAForge download URL for my plugins here, but I've since switched to a custom URL on this domain that redirects to the RIAForge download URL. I did this because the RIAForge URL is too long and was forced to wrap in the box, and I just didn't like the way that looked. I thought some people may be interested in how I got this working, so here you go.

I started by creating an array of structures that define my available plugins and their download links:

if (not structKeyExists(application, "_pluginForwardBot") or structKeyExists(url,"reinit")){ application._pluginForwardBot = [ {name="BurntMango",url="http://burntmango.riaforge.org/index.cfm?event=action.download"}, {name="Lightbox2",url="http://mangolightbox.riaforge.org/index.cfm?event=action.download"}, {name="LogViewer",url="http://mangologviewer.riaforge.org/index.cfm?event=action.download"}, {name="PopularPosts",url="http://mangopopular.riaforge.org/index.cfm?event=action.download"}, {name="RelatedEntries",url="http://mangorelated.riaforge.org/index.cfm?event=action.download"}, {name="SmartType",url="http://mangosmarttype.riaforge.org/index.cfm?event=action.download"}, {name="SweetTweets",url="http://sweettweets.riaforge.org/index.cfm?event=action.download"} ]; }

Next, I want to be able to go to this url: http://fusiongrokker.com/get/index.cfm?plugin=[PluginName] and be forwarded to the RIAForge download page:

This works just swell. Notice that I'm adding "&doit=true" to the URL, which you normally won't see when downloading from RIAForge. This extra URL parameter tells RIAForge to skip the page that says "Your download will begin momentarily" and just return the file.

The problem with this, however, is that RIAForge won't count the download in your stats. To get around that, I've added a background thread that will view the download page so that the download count is updated:

I've learned that you always have to assume that some users will be evil, so we also have to make sure we validate the URL parameter:

And the final product of the code looks like this:

//initialize data if (not structKeyExists(application, "_pluginForwardBot") or structKeyExists(url,"reinit")){ application._pluginForwardBot = [ {name="BurntMango",url="http://burntmango.riaforge.org/index.cfm?event=action.download"}, {name="Lightbox2",url="http://mangolightbox.riaforge.org/index.cfm?event=action.download"}, {name="LogViewer",url="http://mangologviewer.riaforge.org/index.cfm?event=action.download"}, {name="PopularPosts",url="http://mangopopular.riaforge.org/index.cfm?event=action.download"}, {name="RelatedEntries",url="http://mangorelated.riaforge.org/index.cfm?event=action.download"}, {name="SmartType",url="http://mangosmarttype.riaforge.org/index.cfm?event=action.download"}, {name="SweetTweets",url="http://sweettweets.riaforge.org/index.cfm?event=action.download"} ]; }

Then, a quick URL Rewriting rule to get the nice looking URLs:

##### Plugin Forward Bot RewriteRule ^/get/(.*)$ /_pluginForward/index.cfm?plugin=$1

All in all, not a difficult project.

This blog, before I bought the domain FusionGrokker.com, lived at http://tuttletree.com/NerdFusion/ — a subfolder of my family blog. While there and operating under the title "NerdFusion," I setup FeedBurner using the same title, NerdFusion. When I bought this domain and moved my blog here, I knew I would rather have my FeedBurner URL reflect my new blog title; but I also knew from past experience that changing the FB url causes problems. Doing so abandons any and all subscribers, and after you realize that, you can't get the old url back, because it's "in use" (by whom, exactly?!) So I just left well enough alone, and until today I have been continuing to point my RSS links to the old FeedBurner link.

In my mind, this is retarded because the whole point of using FeedBurner in the first place is so that you can change your blog domain or blogging platform without losing subscribers in the process. If they have the same problem — albeit, not exactly the same, but close enough — then what benefit are they really providing? Ideally, they would allow you to create an alias that points back to the original feedburner url, as long as it was unique and available. Heaven forbid the easy, correct method be available though, right? This started as an informational post and has derailed into a rant.

*Cough* Back to business.

So FeedBurner has some, erm, "problems." I would really recommend that you not change your FB url.

Instead, create a new one and have your subscription links point to it. Let your old readers continue to use the old FB url. It won't hurt anything, I promise. The only down-side I've found to this, so far, is that your stats are now split between the two. I'm not much of a stats whore any more though, so it doesn't bother me that much — which is to say, at all. Half the time I can't remember my FeedBurner password, let alone feel like checking my RSS stats.

Now, my RSS link is what it should be: http://feeds2.feedburner.com/FusionGrokker/

I hope this helps prevent people from making the mistake of changing their FeedBurner URL only to find they have kicked their subscribers to the curb.

I'm not married to Tweetdeck. I find myself going back and forth between it and Twhirl. Both have features I wish the other did, and I haven't been able to strike up the right balance. I wish Tweetdeck felt as polished as Twhirl. I wish Twhirl showed groups like Tweetdeck. And so on.

Anyway, the other day it occurred to me that most people that use Tweetdeck probably have a Misc column — I do. I thought it might be fun to put up a list of people you follow that don't fit into some major category that gets its own group. For example, I have groups for CF Community, and IRL (In Real Life — aka Meatspace), so you won't see any ColdFusion people or family memebrs in my list.

So here, in no particular order, is my Misc group.

• @BarCampPhilly — Missed the first one, hoping to go next time.
  
• @DarthVader — Do I really need to explain?
  
• @DrHorrible — Eagerly awaiting chapter 4.
  
• @FakeSarahPalin — Comic Relief
  
• @FeliciaDay — See: Dr. Horrible.
  
• @GreebleMonkey — A blogger whose path crossed mine.
  
• @HigherEdCampPHL — Hoping to attend, expecting big things.
  
• @ICHC — Comic Relief
  
• @Jarrod_dixxon — Yes, I am a Stack Overflow fanboy.
  
• @Jeresig — … and a jQuery fanboy.
  
• @JimBreuer — For comic relief, if he would ever post…
  
• @LeoLaporte — For awesome links.
  
• @MarsPhoenix — I guess maybe I'm a space nerd at heart? Who knows. Just darn interesting!
  
• @NerdMeritBadges — Yeah. Nerdy. That's me.
  
• @Newegg — My favorite hardware retailer.
  
• @Nothingface1 — One of my favorite bands.
  
• @NotSam — A member of the Opie & Anthony radio gold team.
  
• @OpieRadio — The O&A title character I would never have expected to embrace twitter…
  
• @ParentHacks — I'm something like 5,000 posts behind on the PH blog, but I feel obligated to catch up one day…
  
• @PennJillette — I love Penn & Teller. (Especially their Showtime show) Nuff said?
  
• @PhillyLounges — Followed me randomly one day, looked half interesting. Decided not to block.
  
• @RockBandDLC — Ahhhh, Rock Band. My favorite video game. How I love thee.
  
• @SarcasticMomLC — Another blogger whose path crossed mine.
  
• @SomeECards — Early notification of new cards so I can be the first to send them to my friends, winning all the coolness points.
  
• @Spolsky — Who hasn't been following Joel for years?
  
• @SuperDalgas — Another Stack Overflow team member.
  
• @ThatKevinSmith — Yeah, I just like fat guys from NJ?
  
• @TheToadies — Another favorite band.
  
• @WilW — I had a crush on his TV mom.
  
• @Wiseacre — Spectacular photographer; true to his name.
  
• @xpdev — Free private SVN hosting.
  

Ok, so I lied. That was alphabetical order. I showed you mine, now you show me yours.

In part two of this three part series, I'm going to show you how to create a pod from a plugin and discuss the implications of doing so.

Just as with Template Pods, you need to have a pod-enabled theme. There is actually still one way to get your pod content displayed in a non-pod-enabled theme, but let's not get ahead of ourselves.

This post is going to be long enough as it is, so I am not going to cover the fundamentals of plugin creation here. (Maybe some other time.) To get you started, I would recommend you read the plugin documentation, followed by Seb Duggan's posts on plugin architecture changes in Mango 1.3+ (here and here). From there, my advice is to find a plugin that does something similar to what you want to do, and reverse engineer it. I'm also going to assume you have a basic understanding of how Mango dispatches (aka broadcasts) events, and how to respond to them. (Not to be redundant, but that's a fundamental of plugin creation in Mango.)

Before you can create a pod, you have to understand exactly what it is, and everything that it does. In it's simplest form, a pod is a small block of HTML that is typically added to a website's sidebar, and its location — at least the order of things on that sidebar — is easily configurable from admin. You can make it more complex if you want, but for the sake of simple explanations, let's just think of it as a block of HTML. But in addition to creating that block of HTML, your plugin must also respond to various events so that customization through configuration is possible.

If you've seen Mango's pod manager, you know that it works by giving you a list of available pods and their associated IDs, and a text box for you to pick which pods to display, and in what order, by typing in the IDs in the order you want them displayed (one per line). How does Mango know that your plugin creates a pod? And how does it know what that pod's ID is?

Mango knows these things because your plugin responds when it dispatches the event named "getPodsList". Your plugin is listening for that event, and responds with a structure of information about it's available pod including the Name and ID.

plugin.xml:

plugin.cfc:

This information is used in the Pod Manager to give the end user the option to display the pod, and the choice of where to display it. The next event that Mango will dispatch that your plugin needs to respond to is "getPods". You also have to check if your pod has been enabled, by checking for it in the list variable event.allowedPodIds. Obviously, if the variable contains an asterisk, (meaning display all) you should count that as a match:

plugin.xml:

plugin.cfc:

Pro-tip: Did you notice that I just included a CFM template from inside our plugin CFC object? You can do that, and the code inside the CFM template acts as if it's written in the CFC. It has access to the same local scope and variables scope — as well as everything else — that code written directly in this spot would. This content is not cached with the CFC instance, either, which makes modifying and debugging its content during development much faster and simpler. There's no need to clear the cache or de-activate and re-activate the plugin. I use this method for all of my rendered content areas: settings pages, pod bodies, and content added to events (like Related Entries).

So now your plugin properly informs Mango of your pod's existence, and properly renders the pod content when it's requested. What's left to do? Well, what about non-pod-enabled themes? We don't want to just leave these users out in the cold, do we? No, we don't!

Another beautiful thing about Mango is it's ability to create custom events, and the simplicity of doing it. Listening for your own custom event to display the pod content will allow users with non-pod-enabled themes, or users who want to put your pod somewhere outside the pod group (in a "custom" location, if you will) to use your plugin. Listening for the custom event is as simple as adding a message listener to your plugin.xml file, and adding the event name to your if statement:

plugin.xml:

plugin.cfc:

And dispatching that event? Even easier. You just instruct the user to add this line of code where they want the pod to be rendered.

I'm pretty sure this covers everything about creating a pod from a plugin. If I've missed anything, leave a comment to let me know and I'll update the post accordingly. Next time, I'll show how to make an existing theme pod-enabled, when it's not already.