I'm working on v6 again. The "project from hell" is over and I'm at a job now that doesn't crush my soul, so I've been a lot more excited about working on BlogCFC again. I hope folks have not given up. The most recent changes to V6 SVN include:

• The settings file now includes a reloadkey value. This is the key you use in the URL to reload the application. I'm still reloading the app on every hit for now, but this was an old request to help improve security.
• The application name now uses a hash of the current template path. You do not have to edit the application if you have multiple blogs on your box now. You should edit the settings file to set a proper blogname if you share a db, but you don't have to edit Application.cfc anymore.
• The red template was updated to demonstrate a 'home' link using $$HOMEURL.
• Comment support has begun. A new CFC just for comments was added. Comment display isn't done yet. Currently I just dump the query on the page.

Any questions, please let me know. After I get comment display working I'll do another checkin. Then I'll work on the comment form itself. That will be "the end" of templating pretty much and I'll start working back on core functionality again.

The last update (over at http://blogcfc.riaforge.org) was just to get rid of the icky Mac files in the zip. Nothing has changed in 5.9.002.

Earlier this week I had a discussion with Patrick McElhaney about a possible security issue with BlogCFC. Patrick pointed out that the Pod Manager lets you add any CFM code you want to your pods. Patrick felt this was a danger as a blog author could put malicious code up on their blog.

Now my feeling is that this is no different then the file manager. Also - you have to trust your blog authors somewhat. I mean, if I'm a blog author and wanted to screw your box over, I could always post porn or other damaging material.

While I see the risk - I just see it as more of an edge case. Anyway, you can easily disable the File Manager via an INI setting, as well as disabling the ability for blog writers to change their settings. Scott Pinkston sent me a mod to give the same ability for the Pod Manager. It would completely turn it off - not just the edit ability.

Thoughts?

Jax wrote me this morning to tell me about a new spam plugin for BlogCFC: SpamStop plugin for BlogCFC released.

I've got to say - this looks darn impressive. I haven't thought a lot yet about spam stuff for v6, but this is definitely something I'm going to consider rolling in.

As for v6... folks may have noticed I've slowed down quite a bit. For the past two months I've been working on a project that is going a bit slowly. The project will end soon, but frankly my mental capacity for BlogCFC has been next to nothing. I'm certainly not giving up on v6, but I wanted folks to be aware that I know I'm going slow, and to not give up hope.

NerdFusion has a good article on modding BlogCFC to remove the need for an ini file:

Hacking BlogCFC: Part 1 - Replacing the INI file (read) with XML

Jax has created a very cool Lighthouse Plugin for BlogCFC. Check it out here.

I've done a bit more work on the template. You can now view an entry, although comment display isn't there yet.

If you get latest, please be sure to use the Red template, as the Green one doesn't have entry.html yet.

Feel free to play with it a bit.

A user, wfinley, posted on my forums an interesting way to improve podcasting in BlogCFC:

http://www.coldfusionjedi.com/forums/messages.cfm?threadid=8A63DBA4-19B9-E658-9D546CA3B79EB6E7

Ok, as folks know, I've been stuck for a bit on the whole template engine because I wasn't sure how to handle forms. I think I have a solution and I'd like feedback.

Consider the Add Comment process. In core BlogCFC, this involves launching a popup window. You enter your comment, save it, and the popup closes and the main window reloads. Other folks have modified this. They either use a comment form on the page itself, or they do it but hide the form display with JavaScript.

My thinking is this. While I can see folks wanting control over how the form shows up, and control over the fonts used in the form, I can't see them wanting control over the layout of the fields. So for example, the first fields asks for your name, the second your email address, and so on. I don't think folks would care to switch email and website.

So to handle the comment form, your template will simply use a token like so: %commentform%. That one tag will be replaced with the form. It will also handle displaying the errors. The output will be standardized, so you know exactly what CSS to modify if you want different fonts. This means you can change the basic layout, like padding, etc. You just wouldn't be able to change the order of stuff. Or change that errors show on top. I think this is a fine compromise. The only detail I'm a bit unsure of is how to handle success. Right now on success we do: reload opener, close window. But for folks who want a different type of 'Add Comment' logic, I'll need to think I'm a bit more. I may just use one more file for comment completion. This file would be run when stuff is done.

Anyway - thoughts please? This was the last thing holding me up before I wrapped the prototype.

Please check this entry on my main blog:

BlogCFC Export/Import Code

I probably should have just posted this here. Sorry for the duplication.