BlogCFC 5.9.1 Released
I've just upated BlogCFC to version 5.9.1. This is one of the biggest releases in a while. It's mainly a guilt release. As folks know, version 6 has been well delayed. I decided to work on the 5.x branch again and clear up some old bugs and features that I had planned for version 6. So what's new?
- You can now delete a comment via email. When you get the email notification of a new comment (you being the admin), you have a special link. Clicking on this link will delete the comment without you even needing to log in. Basically, fire and forget.
- In the same vein, if you have comment moderation turned on, the email will include a link to approve the comment. (Thanks to Brian Kotek.)
- You can now subscribe to an entry without having to post a comment.
- Podcasting support. This was written by Brian Meloche.
- For entry enclosures, you can now manually enter a file name. This is handy for files that are too big to upload via HTTP (like files for podcasting).
- Multiple small bugs and other changes to generally approve the platform.
You can download BlogCFC from RIForge at http://blogcfc.riaforge.org.
Comments
Any plans to make the page functionality more complete? I'd love to be able to use BlogCFC on CF like I do WordPress in PHP... using it as a basic CMS + the blog as a news page.
I managed to get the login process integrated with our Active Directory, and then get a several year old Contribute-based newsletter thing imported into a copy of BlogCFC a few weeks ago (I'm still impressed with myself :D) and it would be great if I could use it more extensively. I really don't want to give my users the level of learning curve something like Sava would throw at them. And I really don't want to muck about with getting PHP and MySQL running to use Wordpress on our intranet.
I managed to get the login process integrated with our Active Directory, and then get a several year old Contribute-based newsletter thing imported into a copy of BlogCFC a few weeks ago (I'm still impressed with myself :D) and it would be great if I could use it more extensively. I really don't want to give my users the level of learning curve something like Sava would throw at them. And I really don't want to muck about with getting PHP and MySQL running to use Wordpress on our intranet.
Can you be more explicit about what you mean by making the page functionality more complete?
# Posted By Raymond Camden
| 8/1/08 10:17 AM
Sure! Basically, let pages have (where it makes sense to, anyway) the same functionality available that blog entries: rich text (easy enough to add in, but I expected it to do the page field when I did it on the blog entry field), allowing comments (or not), released or pending status, adding images & files. Also, being able to sort the navigation. Having subpages (and subcategories!) would be great, too, especially if you could opt not to display them except if you're on one of the pages in the parent category.
I'm still using 5.9.003 though, so maybe some of this is in there.
And what'd be ultra-super-fantastic is if the wiki-style versioning from Canvas was built in... the latest version of WordPress added that, and it made it significantly more viable as a CMS that you can trust the less tech-savvy users with. And I forget if BlogCFC already supports this or not, but having at least two user levels, so there's one that can submit content but not approve it, would be very handy (and bonus points if permissions can be on a per category basis or something similar to that).
I'm still using 5.9.003 though, so maybe some of this is in there.
And what'd be ultra-super-fantastic is if the wiki-style versioning from Canvas was built in... the latest version of WordPress added that, and it made it significantly more viable as a CMS that you can trust the less tech-savvy users with. And I forget if BlogCFC already supports this or not, but having at least two user levels, so there's one that can submit content but not approve it, would be very handy (and bonus points if permissions can be on a per category basis or something similar to that).
Comments:
a) Let pages have a RTE: This would be simple if I followed the same method as blog entries. Please file an ER for this at riaforge.
b) Allowing comments: Personally I don't believe this makes sense for a page.
c) Allowing pages to be released/pending: Unless you use the navigation pod, all pages are private unless someone can guess the URL.
d) Adding images/files: What do you mean? Right now you can use HTML to do so.
e) How would you setup categories for a page?
f) User levels for BlogCFC: That's a tough one. I know I'm improving user support for v6 though.
a) Let pages have a RTE: This would be simple if I followed the same method as blog entries. Please file an ER for this at riaforge.
b) Allowing comments: Personally I don't believe this makes sense for a page.
c) Allowing pages to be released/pending: Unless you use the navigation pod, all pages are private unless someone can guess the URL.
d) Adding images/files: What do you mean? Right now you can use HTML to do so.
e) How would you setup categories for a page?
f) User levels for BlogCFC: That's a tough one. I know I'm improving user support for v6 though.
# Posted By Raymond Camden
| 8/4/08 5:52 AM
Sorry for the late response, I've been sick for a week.
A) Sure thing!
B) Yeah, I rarely use them. Every once in a while it comes in handy to have comments available to turn on though. "Any questions? Comment below!"
C) Guess I use the navigation pod then. But a simple status flag for active/inactive or active/pending approval/not ready would be most welcome
D) BlogCFC's abilities to do this are somewhat limited anyway, but it would be nice if the page tool had access to the same functions for uploading images as the posts tool. (of course, using the rich text editor with uploading enabled negates this issue)
E) Actually I meant hierarchical pages and was adding in that having subcategories for posts would be handy, too. So you could do, say, intranet pages called Human Resources, Marketing, IT, and when you clicked to those primary pages, subpages would show up in the navigation for, say, department policies, memos, whatever... I know that's a big task and moves BlogCFC more to the realm of a simple CMS instead of a blog tool... but hey, can't hurt to ask/suggest, eh? :)
F) Again, even a basic Contributor/Approver distinction would be a huge improvement.
And G) versioning would be so very, very nice, and I bet you already have most of the code written from Canvas... :)
A) Sure thing!
B) Yeah, I rarely use them. Every once in a while it comes in handy to have comments available to turn on though. "Any questions? Comment below!"
C) Guess I use the navigation pod then. But a simple status flag for active/inactive or active/pending approval/not ready would be most welcome
D) BlogCFC's abilities to do this are somewhat limited anyway, but it would be nice if the page tool had access to the same functions for uploading images as the posts tool. (of course, using the rich text editor with uploading enabled negates this issue)
E) Actually I meant hierarchical pages and was adding in that having subcategories for posts would be handy, too. So you could do, say, intranet pages called Human Resources, Marketing, IT, and when you clicked to those primary pages, subpages would show up in the navigation for, say, department policies, memos, whatever... I know that's a big task and moves BlogCFC more to the realm of a simple CMS instead of a blog tool... but hey, can't hurt to ask/suggest, eh? :)
F) Again, even a basic Contributor/Approver distinction would be a huge improvement.
And G) versioning would be so very, very nice, and I bet you already have most of the code written from Canvas... :)
Hi Ray - *Great* app - cleanly architected. Thank you! And glad to see you survived Gustav....
Suggestion for V6 re: multiple blogs:
I have a test setup now with multiple blogs (using a dynamically generated structure instead of the .ini - neat), but the duplication of so many client files feels odd, especially as most files are common. It would be cool if you could set up a minimalist client folder - say, containing a index file (and Application?), an images folder, and an admin folder with its index/Application file - and dump the rest of the (common) stuff into the blog root.
You could then use website/blog/john, website/blog/jane, website/blog/jane/admin, with each client folder being somewhat separated (for images, specific config options) and under 100KB...and it would be readily usable for both single and multiple blogs. For us, I was only thinking of a few dozen blogs, but even so those client file duplications add up!
Comments? With your current code, it seems to be soooo close to doable I can almost taste it!!
Suggestion for V6 re: multiple blogs:
I have a test setup now with multiple blogs (using a dynamically generated structure instead of the .ini - neat), but the duplication of so many client files feels odd, especially as most files are common. It would be cool if you could set up a minimalist client folder - say, containing a index file (and Application?), an images folder, and an admin folder with its index/Application file - and dump the rest of the (common) stuff into the blog root.
You could then use website/blog/john, website/blog/jane, website/blog/jane/admin, with each client folder being somewhat separated (for images, specific config options) and under 100KB...and it would be readily usable for both single and multiple blogs. For us, I was only thinking of a few dozen blogs, but even so those client file duplications add up!
Comments? With your current code, it seems to be soooo close to doable I can almost taste it!!
# Posted By Paul
| 9/4/08 10:47 AM
Paul - the main reason I haven't done more to support multiple virtual blogs on the fly (and that's the critical part - virtual or dynamic blogs) is that evern implementation is different. So some folks want support for
x.blog.com and y.blog.com
and some want
blog.com/x or blog.com/y
Those are pretty different. The first requires us to look at the host name to determine which blog is loading. The second equires us to look at the cgi.path info and it also requires modification to every link on the system.
Also, what determines what a valid blog is? For RIAForge, which uses a dynamic system, I have to check the host name against a list of valid RIAForge projects, and those who have blogs enabled.
It is because of this I did the bare minimum - the "Instance" support, which lets you pass in config info at runtime. The _mechanics_ of your Blogger.com setup though are up to you.
x.blog.com and y.blog.com
and some want
blog.com/x or blog.com/y
Those are pretty different. The first requires us to look at the host name to determine which blog is loading. The second equires us to look at the cgi.path info and it also requires modification to every link on the system.
Also, what determines what a valid blog is? For RIAForge, which uses a dynamic system, I have to check the host name against a list of valid RIAForge projects, and those who have blogs enabled.
It is because of this I did the bare minimum - the "Instance" support, which lets you pass in config info at runtime. The _mechanics_ of your Blogger.com setup though are up to you.
# Posted By Raymond Camden
| 9/4/08 11:00 AM
As always, Thank you! Unfortunately I took on a different role that doesn't involve CF programming anymore. I will definitely pass on the information.
-Edgar