State of the CMS
My content management system work has been … considerable … in the past few days.
You can take a look at the login window and the main editor screen. Although the editor has some “simulation” (i.e., cardboard cut-out un-functionality) still active, most of what is visible on the screen is working off of real data.
This program does not use a database, instead opting for an extremely complex version of something like the file-based back-end on Cluster 2.0. Much more complex, though.
The basic model is this:
You have a user. The user has a login, a real name, and an e-mail address. The user also belongs to one-and-only-one group.
This group has permissions associated with it: the ability to modify {all, a selection of} files, and yes/no permissions to:
- Add and delete content
- Administer users and groups
- Upload files and images
- Manage the site menu
- Manage revisions to content
Note the correspondence to the tabs on the top of the screenshot. Now, you have the concept of a “page,” which, not much of a stretch, is a page of content on the site. Whenever a user without the “revision control” permission but with the “modify this page” permission actually modifies the file, the system saves a backup of the previous page’s content before saving over with new data.
An administrator with the “revision control” permission can then view past changes and/or roll back the file to a previous state. If an administrator modifies a file, it is the administrator’s option as to whether or not a revision document is saved. This helps cut down on full file backups when commas are added, etc.
Anyway, that is about the entire system, and the only reason it takes so much time is spending all the extra thought power on usability, stability, and fault-tolerance. When you design a system that essentially opens a technical field up to less-technical users, you pretty much have to think like a toy company, because the small parts can certainly be a choking hazard.