Blog 2.1 is now posted. Changes include:
-
Authenticate method is now in blog CFC where it belongs.
-
blog.ini file structure has changed. Before, there was a root section called "blog" with one value, name. This allowed you to say, the default blog is 'foo'. Now, we have a root section called default. If you do not specify a name when you call init, these values will be used. If you specify a name and do not specify one of the values, the default will be used. If you try to init("fred") and fred isn't an ini file section, you get an error.
Warning - This update changes the ini file structure. Be sure to carefully integrate the new changes.
-
Remember Me function added to Add Comments.
-
Logout link added (for when you are logged in, of course).
Coming Soon: Support for N blogs w/ one database.
Question: Should blog support non-db persistence? Ie, should I allow you to store your data in xml files instead of SQL Server?
Archived Comments
there's already a cfXML based blog. it requires cffile, which is even more of a workaround than re-writing yours not to use createObject.
is your blog i18n ready?
Yes, an XML based blog would be nice instead of requiring a DB. Of course I haven't yet looked at your code to know the implications of that, but I think that's a good feature.
I think XML storage is a more "blog-like" way of doing it really. You relieve yourself of dependency on another resource (db server) and have more of a "living document" for your blog entry's "permalink". How about an either/or option? No need to toss out the old code! Really, the BEST way that I could even think of would be to render them to (X)HTML directly - a true "permalink" that requires no server to process other than the web server. You could even potentially have the admin upload the files to a non-CF site, pure HTML. Radio and others do things this way I believe, and it would be cool to see a CF implementation like this (though it would involve a lot of work).
That said, my own CF blogging software works with a database as well, so I am facing the same decisions. I have been thinking of abandoning mine and switching to yours already as a matter of fact, so make it store XML - I'll switch for certain! Heh.
Scott, if I do allow for XML, it will not be a conversion, it will be either-or.
Yeah, I don't know why I said that, Ray - I should've assumed you weren't thinking of dumping the DB capabilities rather than the reverse! ;)
XML as an option would make sense (make it an INI flag per blog), but not in lieu of a db. Some things (search, for starters) are just going to perform better in a database.
Definately don't take away db support. It would be nice to have pure xml, and it does make since from a pure weBLOG standpoint... But DB is more powerful.
A little off topic, but I know in the last versions I still had to change a couple areas (email and page titles mostly) to be dynamic rather than hard coded to Camden info. Any plan to change this?
Let me repeat. I have NO plans of taking away DB support. The mod (IF I do it), will allow for DB or XML.
As for hard coded parts - I still look at this project as a blog CFC and my client. So, I assume people will tweak the client (layout, etc) and not just unzip and run. So I don't see a big need to make the client completely dynamic. Does that make sense?
Of course, if many people _want_ this, I can look into it. Certainly you will almost always have to edit the stuff in the right hand column, unless you play the exact same games and read the same books as I do. ;)
Don't get me wrong, I love the fact that you released this code to make a simple blog... you are not required to make the code user friendly.
BUT, you recently made a bunch of things call from variables anyway... so when I grabbed the code I made variables out of these other things right away. For simplicity sake, here are the places that need changing (I think these are it)... there are only 5 lines total (which can pull from 3 variables in the blog.cfc ownerEmail, blogTitle, blogDescription):
addcomment.cfm (title)
editor.cfm (title)
layout.cfm (title, banner)
rss.cfm (email)
Yes, please. I was thinking about finagling your app to do this myself, but I'd much rather you do it and save me the time. ;) I wrote one of these things myself and stored everything that way, but your's seems more full-featured, and I don't have the time to keep working on mine, so I think I'm switching.
a) Thanks for 2.1 ... looking good!
b) I agree with the XML option, but I think I'll stick with SQLserver.
c) Customization. I made many of the changes that Randy made .. so I guess that answers the question ... making these components more dynamic would be a good thing.
d) Feature request. Here goes .. I have two ideas for features .. but I don't want to dump all requests into Ray's lap .. so ... Nate suggested Sourceforge/CVS ... any interest in this? ... We could all work on separate features ... such as ... 1) RSS 2.0 .. I'd prefer RSS 2.0 or even 0.91 to RSS 1.0 .. not too hard .. I've already started some work on it ... 2) ( a bit of a taller order) .. ability to use layout/formatting templates from blogger or movabletype.
Jacob: c) Will do. d) SOurceforge... still not sure. I don't mind sharing my work, but I kinda want to control it still. ;) 1) If you can point me to a good URL on RSS 2.0, and tell me why it's better, I'll defintely consider it. 2) Can you point me to resources on them - and also - would it be a copyright violation?
yikes .. the RSS politics are tricky and complex ... a (very) short version:
0.91 was developed by Netscape and Dave Winer. Pure XML, and very easy to implement and subscribe to.
http://backend.userland.com...
1.0 was a separate endeavor that didn't involve the 0.91 folks at all. Lots of bad blood over this. RDF rather than pure XML.
2.0 is a superset of 0.91 and developed by Dave Winer
http://backend.userland.com...
A quick look at some of the issue:
http://backend.userland.com...
...
and of course there is the gestational echo/pie project:
http://www.intertwingly.net...
Intent is to develop what is not being called RSS 3.0 .. (proposed names include Echo and Pie .. as in "easy as pie") ...
But .. bottom line in my head is that RSS 2.0 makes valid RSS 0.91 feeds, so it's the safest method of providing an RSS feed today. All aggregators will read 0.91 or 2.0 feeds, but they won't all read 1.0.
Ok, I think I will do that. I'll keep the RSS 1.0 method and add another method so people can choose which one they want to use. Thanks for the URL.
yikes .. the RSS politics are tricky and complex ... a (very) short version:
0.91 was developed by Netscape and Dave Winer. Pure XML, and very easy to implement and subscribe to.
http://backend.userland.com...
1.0 was a separate endeavor that didn't involve the 0.91 folks at all. Lots of bad blood over this. RDF rather than pure XML.
2.0 is a superset of 0.91 and developed by Dave Winer
http://backend.userland.com...
A quick look at some of the issue:
http://backend.userland.com...
...
and of course there is the gestational echo/pie project:
http://www.intertwingly.net...
Intent is to develop what is not being called RSS 3.0 .. (proposed names include Echo and Pie .. as in "easy as pie") ...
But .. bottom line in my head is that RSS 2.0 makes valid RSS 0.91 feeds, so it's the safest method of providing an RSS feed today. All aggregators will read 0.91 or 2.0 feeds, but they won't all read 1.0.
You don't lose control on SourceForge, necessarily. You still control who has access to commit things to CVS, and since you are already giving away the code there shouldn't be any issue. But, it would let you provide it via CVS, so you could have stable builds and development still going on more easily. It would also move discussion of features of the software off your blog (which may or may not be a good thing).
hey ray...
...didn't see it posted already, but here's that cfxml blog, written by some folks in italy...
http://www.veggiani.it/avbl...
...not bad...was kinda dead for awhile, but it looks like Andrea Veggiani has picked it back up...
...and, last i checked, they were also on sourceforge...but that was a while back...