PostNuke

For the discussion see: http://community.postnuke.com/module-Forum-viewtopic-topic-53152-start-0.htm



Here is what Jørn has in mind:



[quote=Jørn Wildt]Dear PostNuke community



One of the things that always comes up when comparing PostNuke to other Content Management Systems is its lack of real content management. All we have is some old News, Pages and FAQ (and some more) management modules - nothing really fancy. You can add fancy modules like PagEd, Pagesetter, pnWiki and others but somehow they all lack, well, something - something which I find rather difficult to pinpoint. They are either too complex, too simple, impossible to extend and do not integrate well with each other.



I have been doing some thinking about this issue and would like to present some ideas for a new Content system in PostNuke. A framework that newbies can work with right out of the box, an extensible framework, and a framework with well integrated components that are aware of each other. My ideas are by no means rocket science and most, if not all, have been implemented else where - just not in PostNuke.



If you ask me then PostNuke is going to dwindle away unless something serious is done to add a good content framework. Here is my suggestion.



[b]Content Types[/b]

The core component is the "Content Type". For those of you that knows Pagesetter this is exactly the same as Pagesetter's Publication Type. This will be a separate module that takes care of defining content types, editing and displaying content items - but without user navigation! Think of an Article, with it's title, lead-in text, main text and image, as a content item of the type "Article". The type specifies the fields that are available for a single instance of the type - a single content item - a single Article.



Content Types are management by the site administrator (but can also be created by other modules). The admin can choose from an extensible (through plugins) list of field types. Here are some examples (mostly copied from Pagesetter):



- String (one line text), Text (non-HTML), HTML (using Scribite!)

- Number, checkbox, date

- Media files (using Mediashare)

- File uploads

- URL, email

- Computer code (text displayed with line numbers in mono spaced font)

- Category (using PN .8 categories), both single and multiple select.



Now you can create an article as a title (string), lead-in (text), main text (html) - and many other types of content. But there is still no navigation - neither on the admin side nor the user side. All you have is a Content module that allows you to create content types, content items and then display these - assuming you now the URLs. Navigation is delegated to other modules - more on that later on.



The core framework does also handle input form generation: it will auto-generate input forms (using pnForms in PN .8). These can then be copied to another location and re-designed using the standard Smarty templating system.



The core content module handles a few other things: for instance revision history (who changed what and when).



[b]Content Management[/b]

So far there's nothing new compared to Pagesetter. So lets take a look at the admin side of navigation - how to store and locate your content items. I suggest that all content items are stored in a folder structure identically to your standard disk drive. On the harddisk you manage folders and store files in them. In the CMS you also manage folders - but now you store content items in them - indifferently of the content type.



The first challenge is how to handle user contributed content since normal users don't have access to the administrative folder system. Now remember that the core Content system allows anyone (with the right permissions) to add content, but where should it be stored? I suggest a standard "incoming" folder is created for this purpose (much like your mail system). The editors can then keep an eye on this folder and move new content to the right folders.



Actually there should be one "incoming" folder for each content type and it should be possible to specify which it is. In addition to this the system should have a flexible workflow system a'la Pagesetter (now already in the .8 core). So that different editors and authors and admins can be notified when new submissions arrive.



[b]Content Structure[/b]

But there's still not much difference from Pagesetter. So what's the point? Well, enter CoType - this little module, which I'm rather proud of, has some nice layout features that I would like to copy. First of all you have Boxes - elements that can be floated left/right/top/bottom relative to the current content. In CoType you have boxes for media items, program examples, and general text. I would like to extend this so that you can put any content item inside a box. So you can display and Article and put one or more Media type items in boxes as illustrations.



Another thing to copy from CoType is the use of nested content - sections in sections. This concept should be extended, just like the boxes, with the ability nest any content item inside another item. The only problem here is how nested content should be displayed? In CoType you always have sections in sections (in a document) - and there's a well defined standard way to display this. But what happens if you sudden nest a Music album inside a FAQ inside a Media item ... and then box it? Well, that will have to be solved as we go.



I suggest the Content Type configuration lets the admin specify which types of content you can nest inside another.



The system could also enable boxing of other modules contents - assuming some kind of API/interface the external modules have to implement (just like PostNuke's search API).



[b]Content Layout[/b]

The proposed layout scheme is so far rather fixed - something like this:



- Top content item title is displayed inside ... tags.

- Nested content title is displayed in ... (and so on for further nesting).

- All nested content is displayed on one page.

- A small table-of-content is displayed at the top (linking to sub-content anchors).

- Each (nested) content item is displayed with a standard auto-generated template.

- Boxes floated to the left/right are displayed in 50% width (like CoType)

- Top/bottom boxes are displayed in 100% width (like CoType)



This will allow newbies to quick and easy created new content without having to also design their own templates. Assuming of course that the system comes with a suitable default set of content items.



Experienced users can edit and change the auto-generated templates. But these will be recreated everytime the administrator changes the Content Type configuration. So experienced users must copy the templates to another location and then edit them to fit their own needs.



[b]Navigation[/b]

So far I have ignored the concept of navigation between different content items completely. This is because it can be done in so many different ways - and this is mostly where the different types of PostNuke modules distinguish themselves. A media gallery has a completely different navigation paradigme than a News list, a Wiki and a Weblink collection.



So I propose to delegate navigation to other modules. This has already been done with success with a calendar (pgcalendar) and a news archive (pgarchive) for Pagesetter. These two modules takes a specific Content Type and displays it's items a calendar view and a monthly listing view. This combination is extremely strong - you can add all the fields you want on a Calendar item - and still display it using the standard calendar view. Throw in the nested content and the boxing ability and you get an extremely flexible and yet simple Content Management System.



[b]List Navigation[/b]

The basic navigation is simple a pageable list of items ordered by some criteria. You create different lists and then refer these in the URL. For each list you configure which content type(s) to include, the default sorting order, the display template to use for each item - probably more. Including more than one content type gives some problem with respect to sorting.



This implements the typical News list on the frontpage.



[b]Catalog Navigation (collections)[/b]

This is the typical Weblink and File Up/Download navigation through a collection. The hierarchy is mirrored directly from the content folders.



[b]Calendar Navigation[/b]

Displays content items by date in a calendar (see for instance [url=http://www.fgc.dk/index.php?module=pgcalendar&tid=40]http://www.fgc.dk/index.php?module=pgcalendar&tid=40[/url]). You need to specify which date fields to use as start/end date of the entries.



[b]Archive Navigation[/b]

Displays content in lists organized by month (see for instance [url=http://www.fjeldgruppen.dk/arkiv.html]http://www.fjeldgruppen.dk/arkiv.html[/url]).



[b]Menu Navigation[/b]

On thing that frustrates me with PostNuke is the horrible way you edit menus through the Block interface. No - lets allocate a complete module for menu editing and then just select which menu to display in which box (I believe Content Express does this). With the integrated content framework you can now let the editor select content items from dropdown lists or similar - and avoid having to copy/paste raw URLs into the menu editor (this has always been a intellectual bottleneck for the people I have created websites for).



I would also like to see editing of the menu directly in the front-end. The editor should always have an "add current page to menu" icon in the menu. He should also be able to drag and drop menu items without having to jump to the admin interface.



[b]Frontpage Setup[/b]

This is just another idea of what you can do - not necessarily something to actually implement. But the frontpage need not necessarily be a list of latest items as on most portal websites. It might also be a fixed setup based on a grid where you can assign different content items to different locations. For instance Articles to the left, Banners to the right, and a few images at the bottom.





[b]Where to go now?[/b]

Now who's going to implement all this? Good question considering the speed of the core development. I would love to be on the team (and will be) but my time is restricted (especially now that I got my first kid) so I work rather slowly.



Any volunteers?



There's also the question of organizing the code - we cannot have much more than one or maybe two developers on the core Content module. But as soon as that is ready we can take more people in - one for each kind of navigational scheme. Other people can then work on the default content types.



We also need to consider how a system like this fits into the PostNuke distribution. Does it have it's own release cycle? Is it integrated with the core?



Enjoy 8-)



/Jørn[/quote]