• 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
      • Pdf
        • 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 it’s 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 don’t 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 don’t 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 it’s “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), that’s 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 haven’t put much thought into this yet – the bug-tracker has some nice ui for this, not sure yet if it matches the way I’d 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 don’t 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
  •