After converting devCorner into a blog, the thought occurred to me: "Is there really a difference between a CMS (Content Management System) and a blog?"  I've done a lot of thinking and a fair amount of research (okay, so I read up on some things on Wikipedia after finding them through a quick Google search), and here are my thoughts on the subject.

What is a Content Management System?

Look up Content Management System on Wikipedia. Basically, it is:

1. A way of being able to create/manage content on a website
2. Defined roles indicating who can edit what content
3. Ability to require approval before updates, additions, or deletions go live
4. Version control, so changes to the documents can be handled

There seem to be many other more complex features, but those are the basics.

What is a Blog?

Look up Blog on Wikipedia.  Basically:

1. Create entries
2. Entries generally displayed in reverse-chronological order (newest first)
3. Readers can add comments

Skewing the Lines...

The current blogger system basically is just a way of storing documents in a database and has code that allows for updates to that data and creation of new data.  In essence, CS-Blogger could be used to do very simple online content management: instead of editing pages on a computer through some HTML editor, CS-Blogger gives the ability to create and format those pages on-the-fly.  In fact, through an oversight on my part, it actually supports loading of template vars, which seem to remain dynamic until it is edited and saved (at which point they become static).

So here's how CS-Blogger, at present, matches up with a CMS:

1. Creation/maintenance of content:  cs-blogger allows content to be created and edited (though not deleted) any time.
2. Defined roles (stating who can edit what): cs-blogger has an in-built permissions system, allowing multiple users to edit the same blog (a user with permission on a blog inherently has permission to edit all existing entries as well, even if they didn't create them)
3. Approval of updates, additions, and deletions: cs-blogger makes something live as soon as it is submitted.  There is no ability to set an action as pending.
4. Version Control: cs-blogger does not do any sort of version control... but for a given page, cheap version control could be attained if it were setup as a blog and no entry was ever editted (changes would actually then come as new entries, wherein the previous content was copied & then modified)

Basically, out of four requirements, CS-Blogger scores 2.5.  Maybe 2.25, as the pseudo-version control that it can do is based on a very cumbersome process of creating new entries & always copying the previous entry's data into it.  Still, that's pretty decent.

Evolution of an Idea

As you may have guessed, my idea involves building a CMS which is at least somewhat built upon the CS-Blogger system.  The concepts are essentially the same, in that they both are a way of storing content.  There are some differences, which I will go through now.

My idea of version control is basically doing what SVN (Subversion) is doing: storing a copy of the entire document, then subsequent changes are actually stored only as deltas (incremental change), and therefore more efficiently than storing the entire document.  I'm not sure what other systems do for this sort of management (many Wiki systems can show differences between revisions, but I wonder if they are storing the entire document for each new revision & showing only the differences, or storing the deltas as SVN does).

Foregoing the idea of "real version control" (i.e. storing deltas instead of multiple full copies), implementing version control would be very simple.  There is a "vertical" table, which stores all available entries (some may be in a "deleted" state).  Each entry has a "horizontal" table which intersects the vertical one on an entry-basis: it hold all revisions of the document, and indicates what version is the most up-to-date.  Here's a visual example:

While the initial implementation may not be space friendly, I don't think it'll be a big deal.  I would imagine the size of these documents actually isn't going to be terribly large so space shouldn't be an immediate concern.  Future updates can convert all the changes into the "delta" format that SVN stores, freeng up plenty of space and still preserving each revision's full content.

Approval of Changes

The approval process for updates and changes can be fairly easily integrated into the version control process.  Whenever something is changed, a log should be stored--actually two--for storing the reason for the change/creation/deletion, and one for when the action was accepted or rejected... maybe a third for making it active (depending on the choices given in the interface and how tightly version control and the active status are bound together).

To Merge or Not To Merge...

One of the biggest questions in my mind as I contemplate building a full Content Management System is how to handle the correlation between it and CS-Blogger.  It would seem as though moving it into another project would be the most logical idea (I would imagine some people would have a problem building an enterprise-level website off a product that has "blogger" in the title), but it also seems as though there is a lot of places that the functionality is duplicated.  I have considered the idea of merging the two projects to avoid having to duplicate a bunch of code, as I am a big fan of the "Once and Only Once" (OaOO) philosophy...

There is another possiblility that I have been considering.  Take the CS-Blogger code and turn it into the base CMS system.  Once that's done, implement the database changes needed to allow for holding multiple revisions of a single document (blogger calls them "entries").  I think at that point the goal would be to either build a more robust permissions system or to include another project, like PHPGACL.

Storing Images

So now we've gone over revision control and permissions, but that's just the content (i.e. text) and doesn't really touch on anything like images (or other media content; for the sake of sanity, we'll refer to it all inclusively as "images").  Storing some of the information on the filesystem has proven difficult in the past, especially when selecting images through the filesystem (I like to version-control everything, and the FCKeditor system will show ALL folders, including the ".svn" folder).  Plus changes to the images aren't stored, meaning that a change to the main page would be logged extensively, but changes to the logo wouldn't be (that seems bad).

Storing images in a database isn't bad.  Pulling them from the database isn't that terrible either.  But allowing the user to select them from a list or from a filesystem browser type view is quite a bit more difficult (this would actually require a big rewrite of the embedded FCKeditor system so the filemanager would display information that was retrieved from the database).  There's the option of leaving things the way they are, so the most current image files are stored on the server: once an image change is approved, the updated image (which already resides in the database) is written to disk.  This would have to assume then that alterations to the file on disk will not occur, or there would need to be extra checks in the instance where that happens.