CMS Requirements for Doom9

First the basics:

The site is hosted on multiple servers around the globe and the load is balanced via DNS servers. There's no direct coordination between the various servers and it would be impossible to have any coordination. Furthermore, servers have different setups in terms of RAM, CPU power and server software. Furthermore not all servers allow for dynamic content which gives us requirement number one: A static HTML dump must be possible. This HTML content is then uploaded to the servers via FTP (this process is already automated). But the backend can run on either IIS or Apache platform and use a database if required (MySQL preferred).

Content structure

Let's have a look at the guides now. Most of them are not a 1 page deal, rather I prefer to use the lowest common denominator to put information into separate documents. This allows me to re-use certain information everywhere. As an example the DVD2AVI guide is used in a variety of guides, starting from DivX guides and ending with DVD-R guides. I will call such documents subguides from this point on. As mentioned subguides can be used in a number of full guides. These guides can be part of one or several category/ies or subcategory thereof.
The site currently has 8 top categories: News, Old News, Guides, Download, Links, FAQs, Glossary and the Basics. Some categories contain one document only (Glossary as an example), some contain various sub-categories. Take Download for instance: There we have 3 documents: software.htm, software2.htm (the full software archive) and source.htm (the sourcecode archive). And then we have the guides which has a multitude of sub-categories. For instance we have the DivX guides, in that subcategory we have DivX3, DivX5 and XviD (the latter two containing one document only) with DivX3 branching into two guides.

Content creation and update process

When creating a new guide the following should be possible: First one uploads the subguides that have been created off-line. Each uploaded file has to be associated to one category and one or multiple sub-categories. Then it should be possible to assemble guides from these subguides. The traditional way is to have one main guide page linking to different subguides. By making these links an association is created allowing to see which guides (and therefore sub-categories) the document is associated to. Here's an example.

An alternative way would be to create one page documents, that is you define which sub-guide is to be used for which step. From this selection an automatic TOC should be generated. Each new guide should be listed under the right category in the document overview page and the corresponding subcategory page. A guide based on the "put everything on one page paradigm" can be seen here. Note that the linked guide isn't pushing the paradigm to its limits but it should give you an idea.

Yet another idea would be to have subguides as usual, but have a TOC visible at the bottom of each page. The currently active document is specially marked, and there's a next and previous link that would go to the next / previous step in a guide. Those links and the TOC would have to be dynamically generated after creating a guide in the CMS and assigning a document for each step.

Most documents will be written off-line, yet it would be great to have some kind of online editing facilities as well. Maybe even WebDAV could be integrated so that people working on the site can keep on using their tools of trade. When documents are written off-line, the links reflect the relative site structure. Upon importing a document links should be recognized and adapted if required. For instance, a link goes to Soft21/Editing/VirtualDub1.5.1.zip. The CMS has to identify that VirtualDub software on the server and convert the link to whatever link structure it uses internally. If possible, when a new version of a certain software is out, the link should be adapted (or at least the question be asked if the uploader wants to change that link, including a directory listing of the appropriate directory so that file selection is easy).

As for the news and software: News can be written online using an interface similar to posting a message in a forum. The difference is software: When news are being written often a new software is to be added. This software can be uploaded right in the news creation dialogue (select a file on your HD, select which category the software belongs to, if it should be listed on the abbreviated software page or both software pages (it goes to the source page if it's part of the source category), then we have short name, 1 line description, long description, author, version number, URL of the official homepage and an image for the software - only the first 3 pieces of info are mandatory though, the rest is optional) and upon uploading a link is added to the news. News will be added for the day they are written but there should be a possibility to write news for the day to come, such news should only be output to HTML once that day has begun. There should be a preview of the news table before committing as well. For the software archive it also has to be possible to add software outside of news, to edit software descriptions (the fields I've mentioned before) and remove software.

Permissions / user rights management

As for permissions: Permissions should be similar to filesystem permissions on *nix systems. For each subcategory (directory) there can be owner and group permissions. For instance people having permissions for the DivX3 subcategory can edit all the files present in that category. Subguides belonging to multiple sub-categories are to be considered as symlinks, the permissions for the original file matter and permissions to members of a certain usergroup or specific users have to be handed out manually in order to ensure that crucial documents like the abovementioned DVD2AVI guide can only be edited by people having the proper rights to do so.

Checkin / checkout & version control

Users wanting to edit a document will have to check out a document, which will block any updates from 3rd parties. Only upon checking in the document again can other people make changes. But it has to be possible to turn on/off this functionality on a user level (Doom9 as the primary document editor has no interest in checking in / out 10 documents a day when he's the only one working on the site anyway). When users who don't have to checking/checkout make updates they are informed about checked out documents, and when the document gets checked in again, a diff between the version when it was checked out and the version that the user is trying to upload is shown and the user is given the choice to abort the operation. In any case, it must always be possible to restore any state of a document for privileges users (and regular users can get diffs between any version). Difference documents should be WYSIWYG.

Translations

The CMS should support existing mirrors. Mirrors have their own user, permission and document database. All software links are automatically updated in the translated pages as soon as the original is updated. When documents are checked out for a mirror, the user can get a copy of the most recent version of the English document. That original version is then stored so that original and translation can always be properly associated. When an original document has changed and the user is checking in a translated document that corresponds to an older English version, the user is informed about this fact and can opt to get a diff document and adapt the translation before checking in the translated document.

The admin of a mirror can get full statistics about changes, including all the diff files. Admins for a mirror have the same rights as the admin for the main site, except that the main site admin also has full controls over creation, management and deletion of mirrors.

Perhaps, when software links change in the original, new translated documents can be automatically generated and uploaded so that the links are always recent. In that case, when the mirror admin returns he's shown a list of software links that have been changed and has the possibility to change the corresponding software descriptions.

The CMS system should support multiple languages so that the mirror operators can use their own language (they could translated it themselves though, all that is needed is a mechanism that allows the language switch).