Feature List

Content types

Pre-defined types available to the user:

Plain text

Store plain text in db

Html

Store html in db

Image

Store image in fs
Store image info (height/width etc) in db
There could be a folder type photo album which thumbnails all enclosed images

Rtf/word

Store file in fs
Store file info (author, num bytes etc) in db
Store html representation (via inso libraries) in db

Store file in fs
Store file info (author, num bytes etc) in db
Store html representation (via inso libraries) in db

Binary object

Store file in fs
Store file info (num bytes etc) in db

Custom defined types:

I think its ok to make the developer write code or code-like type specs (a la the new workflow create_from_spec), but the cms ui must let it be enteredvia the web ui.
So we will need some fairly simple wrapper proc around the CR tcl/plpgsql api called create_type_from_spec or similar it would also register the mime type and anything else required like a default (initially empty) template
From memory it is no longer necessary to create the table yourself, or is that broken. One of the two, I dont remember which ;)

Content creation

Allow for batch upload of zip file content type chosen by file extension, including create folders where necessary. Relative links in html will work without modification.

There should be an option to strip msword type cruft out of html files
In any case, only the html between <body></body> will be used, although <javascript> sections in the header should be retained

Create new page -> overlay dialog (dhtml) asking for page name, title and content type

->depending on content type, go to the appropriate editor in the rhs frame, and refresh the left hand frame (content edit for binary/word etc would be file upload)
There are separate tabs of the page edit (rhs frame) that allows details/attributes and parameters to be edited

Details would include standard details like name/title, but I think for the standard text & html etc. content types we should define some other standard CR attributes like author, url, etc. and some useful amount of generic ones like synopsis, extra1, extra2 etc., so that most users will have places already provided for the littlebits of metadata they will need
I would like to see arbitrary name/value pair attributes for every page. In fact midgard usefully allows group/name/value triplets which allows you to programmatically loop over different lists of metadata provided by your content editors
I dont see immediately how CR currently supports this

Revisions

Every edit creates a new content revision
By default a new revision DOES NOT GO LIVE this fact is indicated by the icon in the cms tree representation, and in your task list of documents requiring approval
In the revisions tab of a page, the user can view a list form (showing person, dates etc), and approve or revoke any particular revision
There is also an option to view a side-by-side colorised diff of any two versions of text or html content (or other content type where it makes sense)
Approval can be done by marking an individual page live in its approval tab, or by picking tick boxes in a task list of documents awaiting approval
Check in/ check out

If we implement our internal api around some form of check in/check out mechanism now, then doing locked DAV support etc. later wil be much easier than tacking it onto a system that relies on the acid nature of db updates

Content organisation

Where should cms be rooted?

Separately for each instance?

Allows cleaner separation where different people are responsible for different parts of the site

In one location, and each mount point of cms in the site map is a sub-folder off the cms root

Allows one cms ui view of all cms managed areas of a website
Means that internal symlinks can be made across all cms pages
The responsibilities should be able to be kept separate with permissions anyhoo

Do folders have content/templates of their own (like n auto-toale of contents or photo album, or plain content) OR do folders need an index content item like in etp?
How do we deal with page elements ie. Html subsections of a page

Do we even want them ? (I like them)
There could be a neat way to handle page elements and attachments (like embedded images) in the same way
We possibly only need to support the element concept for styles I am now getting my brain into a bit of a knot thanks to the midgard trifector of styles, folders/pages, categories/articles
Cansomeone bring some clarity here?
This stuff seems to map to the parent-child relationships discussed in the CR documentation

Portals / Page snippets

a special tag (actually i think there is one already) along the lines of: <include name="top-news" some-parameter="10"> - where top-news is a tcl/adp pair living somewhere special - maybe a fs folder or cr folder...

Templates

The content repository allows you to associate templates with content types and individual content items
Ok, so all content types have a catch-all template (will have to think where that fits in the ui I already have a good idea), thats easy enough.
In the cms tree, apart from the odd one off where you want to allocate a unique template to a page, I think we actually want to allocate a template to a folder, and then all pages default to inherit for the template type (sub folders could also be inherit by default).
Template editing

Simple textarea allowing for adp editing that later gets rendered (adp + some cms extras some things we deem security risks)
Templates are already stored by the CR under a whole different root and tree. I think we should therefore duplicate whatever rooting strategy decided on above for CR content rooting but also allowing templates to be used across all mount points make sense?

Keywords

CR allows for nesting of keywords there should probably be a whole ui section for keywords.
I havent put much thought into this yet the bug-tracker has some nice ui for this, not sure yet if it matches the way Id like to see it work for a CMS package
Ideas anyone?
Keywords would be used to populate META tags in the rendered html for search engines

Indexing
Workflows

Making a ui for people to easily generate workflows for publishing/document creation will be a killer feature, but possibly wisest left for v2?

Il8n

Multiple language versions of the same page we dont want to do it here, we want it done in the CR.

When it is, then we can figure out how it fits into the ui

Il8n of the ui

I guess we should do it my vote would be for il8n in v1.5

url parser

Rendering

Use cr to retrieve content & template