Requirements for a CMS in Debian-Edu and/or on skolelinux.org ============================================================= The parties: * Debian-Edu/Skolelinux (hence "Skolelinux"). * eZ Systems (hence "eZ") The key words "must", "must not", "required", "shall", "shall not", "should", "should not", "recommended", "may" and "optional" in this document are to be interpreted as described in RFC 2119[1]. Part 1 - eZ Publish on skolelinux.org ------------------------------------- = Requirements for eZ Publish (hence "eZP") = == Sections == It must be possible to have different sections in the site. Different sections have different content and structural layout and may look different, albeit this is not a requirement. Different sections we need, is the default section "skolelinux" and the sections "developer" and "translator". == Support for multiple languages == Every piece of content must be translatable. It must also be possible to have different content for the various languages -- e.g. the Norwegian version may have news articles not of interest for the rest of the world. For every change of a version of a document, eZP must be able to notify a set of mailing lists that should be configurable on a per language basis. eZP should also inform about what has changed, e.g. provide a "diff". Each change should also carry a note of what has changed. == Version history == Every piece of content must have a version history, containing the date of the change and who changed it, and should as well show the change note, mentioned above. eZP should be able to list the differences between to versions. eZP must be able to show old versions in its entirety, and it must be possible to restore a document to an older version. == URLs == URLs must be sane. Documents and folders should(/must) be identified with names in the URL and not with numeric IDs making it impossible to get an idea of what the page contains. == Cacheability == It must be possible to cache content in some way, while still keeping it fresh. Skolelinux has been slashdotted once and survived easily because today's setup utilizes Squid as a caching surrogate. eZP may either use Squid or another caching accelerator or generate static HTML-documents of the common content. If Squid is used, eZP should be able to send PURGE-requests upon updates to content. In the latter case, eZP should update the static documents immediately to ensure they are up to date. Administrators should always have access to fresh content. (i.e. HTTPS should not cache at all, see next point) == Secure administration == All administration must be securely through HTTPS. It should not be possible to even get a login- or registration form without using HTTPS. The authentication cookie should use the "Secure"-bit. Using mod_rewrite and/or mod_proxy to ensure this is perfectly okay. == Access Control Lists == It must be possible to create groups and assign different parts and/or sections of a site to a specific group, so that group has write access only to that part of the site. It should be possible to require that certain parts of the site require and editor to approve the changes before a document is published. == Actual editing == Editing must be possible in Mozilla, Opera, Konqueror and Internet Explorer, but it should be possible in any browser. The site itself must be viewable in any browser. It must be possible to sync external content into eZP -- e.g. content that is primarily managed in CVS. It should also be possible to use external editors and upload the content to eZP in an easy way, without having to use a web interface. Preferably, a Subversion interface to the content should be provided. The tool used to create the original document must not limit which tools later editors choose to use -- i.e. it must be possible to edit the XHTML of a file while still being able to edit it using e.g. Wiki-syntax (must does not affect Wiki-syntax) or in OpenOffice. eZP should provide an easy to use syntax for editing, with the Wiki-syntax of MediaWiki being a fine example. It is by no means necessary to provide the full capabilities of XHTML with this syntax. == HTML headers == It should be possible to specify different headers to different pages, making it possible to e.g. embed a JavaScript on a page or override CSS. == Components == (This is what's called "templates" in MediaWiki, but I (Alex) think of it as components and to avoid name-confusion with eZP's templates, I named it such :) It should be possible to create easily accessible components that using some syntax is included in a page. With MediaWiki one creates a page with the name "Template:Foo" and access it with {{foo|argument1|argument2}}. Such components make it easy to use more complicated page objects while it is still easy to maintain. Example: {{quote|Forty-Two|Deep Though}}. The quote template then contains something like (using MediaWiki-syntax):
«{{{1}}}»
– {{name|{{{2}}}}}
(The MediaWiki-syntax and implementation is far from optimal, so an enhanced implementation is very welcome.) == Menu == The menu must not be restricted to what content is actually contained in the various folders. E.g. "Get started" might be a top-level menu item, but is actually contained in "Help/Get Started". == Site access == www.skolelinux.org/ should make a guess based on the browser's language preferences and provide a specific based on it. www.skolelinux.org/(no|de|es|..)/.* should present the content in Norwegian, German, Spanish, etc. = Installation and configuration = eZ obliges to help *install* eZ Publish on skolelinux.org and to *document* this installation. The documentation must be thorough enough to get a plain installation of eZP up and running in the same way, although it may refer to existing documentation were fit. "Install" is defined to installation and configuration of the eZP-software, and to assist Skolelinux in getting eZP to work according to the rest of this requirement specification (part 1). Skolelinux obliges to provide a server with the necessary prerequisites and to provide eZ with the information they need. Skolelinux is responsible for maintenance, given proper documentation of the set-up is provided. == URLs == [1] http://rfc.net/rfc2119.html