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.

So I'm beginning to think about the install process for BlogCFC. I will admit that Mango (as reviewed by Brian here) is what I consider to be the minimum standard for V6. Now I can handle creating DSNs and a multistep process. What I'm curious about though is how to create the database. Creating tables is easy enough. But given a valid DSN (and assuming you have permissions), is it relatively easy to create the initial database? (I'm just concerned about SQL Server and MySQL for now.)

And if folks want to help out - this would be an area where you could help right now. You could write a script that has a hard coded DSN on top (again, assume the DSN is valid), and that then reads in a file for SQL commands to create the DB and tables. All I ask is that if you want to do this - "claim" it with a blog comment so we don't duplicate efforts. (And if you are late and want to help another commenter, just say so.)

If you get the latest from SVN, you will now see basic templating with GoldenSnitch. There is a LOT going on here, so let me try to cover it bit by bit.

First - in the settings.xml file is a theme property:

The app looks in the template folder for a folder named red. You will also see a green folder. The name specified in the settings must match the directory name.

What is in the folders? Right now just two required files, template.html and entries.html. Both also have a style.css, but that is optional. You see - all themes will have rules for what is required, and the app will check at startup to ensure those files exist. Along with template files will be an XML file that defines the theme's metadata (title, author, version, etc). All of that is coming later. Outside of the required files, a theme can have any number of additional files. JS libraries - CSS - images - you name it.

So let's take a look at template.html first:

As you can see - there is no code, but I'm using $$FOO to represent variables. Right off the bat you see $$TITLE, which will be replaced with the title. Ditto for $$BODY. TEMPLATEURL is a cool one. As a theme author, you don't know the exact URL of your crap, so it makes it hard to include your CSS/JS/images. Well by using $$TEMPLATEURL, you get a base URL that will always work.

The template.html file will be used for the main page layout for all parts of the blog. It is essentially header and footer.

Now to render entries we use entries.html. The contents of this file is repeated once for every entry, and has variables as well. Here is red's entries.html:

Note that some variables above have arguments. Both POSTEDTIME and POSTEDDATE let you pass formats. The last variable is an interesting one. What if - for each list of blog entries - you want an HR between each entry, but not at the end? That's what you use NOTLASTROW for. And it is smart too - it will work correctly if only one entry exists.

So let's compare this to green's entries.html:

This one uses a table, and demonstrates two additional variables, FIRSTROW and LASTROW. As you can guess, they are only run on the first and last row.

Thoughts? I'm a bit worried FIRST/LAST/NOTLASTROW are a bit complex - but I think you can look at them and still get a good idea of how the site is going to layout.

As an FYI, the code in template.cfc is a bit rough. Don't consider it final by any means.

Other random/stray thoughts in my head:

• I see at least one more template, entry.html, that will be used for single entry display. I'm really scared about the forms and how I will template-ize them. In fact, now that I think of it - Add Comment may need it's own form, and I'll need to think a bit about how to separate the form UI from the handling of adding comments.
• Due to the above - I may delay then other non-essential forms - like add trackbacks.
• How in the heck do I do search? On my blog, it is in the main template. I could simple allow for form action=$$SEARCHURL.
• Internationalization. Um. So.... thats a bit scary as well. In BlogCFC now - every bit of text is resource bundled. But does that even make sense if we have templates? I mean - someone could easily build a French skin and just hard code the layout. If BlogCFC were to stop having localized text versions, would people crap?
• Other pages I need to do off the top of my head - contact page, slideshows page, stats page. Although does anyone really skin their stats page? For that - I could just use the core template header/footer. That's my plan for Pages anyway.

Comments, please!