PostNuke

3000 public schools, around 80000 teachers and 1 million students use Postnuke for their school websites. The Department of Education offers a Postnuke sites to every school in Catalonia and some 500 of them use it.

Besides Postnuke Moodle and MyScrapBook are in use for the project. MyScrapBook is an easy content solution that the schools use to produce book-style web sites.

As a first step the projects main site has been migrated from Joomla to Postnuke - a point that was criticized last year ;-) But more importantly during the last year 450 teacher were trained in the use of PostNuke. Theses courses are repeated this year with another 400 teachers.

Albert Monfort and his collegues for their project integrated Postnuke with the eLearning system Moodle very comfortably. Moreover they imporved some of the old core modules so that they can handle massive numbers of users. For their special requirements Albert Monfort and his collegues programmed several modules. For example "Agendas" handles Agendas for single users or groups of users. Teachers can even handle presence lists with Postnuke. All modules are available via their homepage only most of they are currently Catalan only.

They even build up an internal FAQ system for common problems with Postnuke. It's in Catalan - so if you are able to speak Catalan feel free to translate it for the wiki. ;-)

For the future the Catalanian Deparment of Educations plans to at once move to .8 and run it only with one installation. That will reduce the maintainance work and the risk of problems with hundereds of installations.

The project "Intraweb" can be found at http://phobos.xtec.cat/intraweb/web/.

Robert evaluated other category systems and tried to imitate the best he found and to avoid the mistakes they contained. He explained the various fields that you find in the category administration an how you can use them in your own module.

The system was considered quite complex by the audience but Mark West and Robert assured that this will be taken care of. The use of basic categories will be as easy as possible.

But first of all the system works and can be used by the module developers. It is also their duty to create intelligent user interfaces for the categories in their modules.

There are basic plugins available that display category lists aso. Further plugin can be developed on demand of the community. So if you feel there's something missing - make it a feature request in the NOC.

During the discussion various ideas for simplification came up and will certainly be implemented among of which were the security domain, the custom data fields and the needed -1 value for main categories.

Robert also explained that it is also possible to put for example one article into several categories.

Frank's first example regards the use of DBUtil instead of the usual SQL code. DBUtil reduced the amount of lines of code by 60% and at the same time made all calls trans database compatible. Less lines of code reduce also the risk of errors. And Frank presented the way the result of the SELECT gets filtered through the permissions which is also done in a few standard lines of code.

Of course Formicula 2.0 makes use of pnForms. This reduces for example the edit function for the contacts to 3 lines of code plus the few lines that build the form and automatically validate the inputs. The programmer doesn't have to handle all kinds of wrong inputs - that is all done by the the forms API. The module will only receive validated values.

In a general overview Frank picked out single lines of code from Formicula and pointed out the differences to .7 - Among others were the use of the LogUtil with takes care of occurring errors and the fact that the pnRender object now has a parameter for disabling the caching.

Frank emphasized the fact that the correct use of all .8 APIs reduce the size of a module by 30-50%.

There are several sites that offer open source web-templates - you can take them and build your own site on them.

You choose one of their templates and turn them into a theme in 20-30 minutes with some experience. So if you watch the recorded presentation you will be able to follow Mark explanations step by step. We will put them online within the next few days.

Additionally there is already a lot of information in the development wiki.

In Mark's presentation you will also learn about the need to still provide table style sheets and how to correctly implement them.

Also a theme isn't only the template for the general layout - with for example the RSS theme you can generate RSS from every templated module. Of course it is also possible to generate other kinds of XML or other ways of displaying content.

One major advantage of the new theme engine is the possibility to completely port a theme with all settings from a sandbox site to the live site as all variables are stored in Smarty compatible .ini files.

We hope that this presentation sparks a new wave of themes and inspires new people to design their own layouts as these steps do not only apply to open Source web templates but also for your own designs created in Dreamweaver, NVU and so on. Mark already converted more than 100 free web templates that are available for .8 in the NOC or on Mark West's homepage.

BTW: Some more photos

Only few have heard about DBUtil, even fewer have used it themselves. Robert Gasch aimed at changing this.

DBUtil frees the programmer from the need of writing SQL. You rather work with objects and all your selects will be checked for permissions. So if you fetch a set of 10 articles you will only receive that 10 articles that the users is allowed to see. This alone is a major enhancement and saves lots of code lines.

Robert presented the object library as a powerful yet quite easy to use system for the handling of objects. After the initialization of an object you can select, edit, delete aso the object. For a more detailed look into the ObjectLib you should watch the recorded presentation which we will publish within the next few days. Or watch the other presentations live.

Do you want to see how our location looks like? Look here!

We released .764 and .8 RC1 - RC2 is supposed to follow within the next few weeks. We did a redesign of the NOC and appointed a new Steering Committee.

Postnuke is now in the process of a rebranding. A new name has been chosen by the Postnuke Foundation and as soon as all legal issues are solved the new name will be presented to the community.

Mark's next topic were the central features in Postnuke .8 which are also the main topic of this years meeting. The German Postnuke Foundation tried to assemble a panel that explains all the new features to the broad community.

Believe it or not - .9 is already in the planning. There's already a branch in the SVN and we decided to make it PHP5 only. The Object Library will become core. The language system will get an overhaul - other systems will be evaluated. .9 will deliver UTF-8 and it should be possible to really have multilingual content.

Mark West pointed out the power of the Postnuke permission system - but also the problems with its complexity. Frank Schummertz volunteered to work out the next generation permission system.

If you want to help, Mark asks you to work on the wiki, do some testing, report bugs, submit patches or develop your own Postnuke extensions.

In the following discussion, Frank Schummertz reported the experience some users made with the UTF-8 conversion of Postnuke.

The URL for the broadcast is
http://breeze.serv.uni-osnabrueck.de/postnuke

There you login in with you forum nickname and change the connection speed from LAN to DSL or whatever connection you have. There's a videos stream, the presentation and a chat. So if you have any questions or remarks - use it.

If you are in Osnabrück per chance, you can visit us in the Seminarstraße 20, room 103.

There are many general CMS, Coding, PHP aso communities all over the web. Tell them what we are doing.

Some examples:
Ohloh.net is an open source network that connects people through the software they create and use. This is were you can meet other developers and see what they are doing. The registered projects are analyzed and can be compared. On the Postnuke project homepage you find some very interesting information about Postnuke. Ohloh.net regards not only the Postnuke core but also some of the better known modules. Thus the statistics reflect the development of Postnuke as a whole. You can add your own repositories there and claim your code. Show those other devs, that you are there and what you are working on.

cmsshowcase.com collects websites and sorts them by the used CMS. There's not one Postnuke site in that list. You should take 2 minutes to submit your best Postnuke work.

If you are registered at xing.com you find a Postnuke Group with more than 50 professional Postnuke users - join us there.

Give presentations about Postnuke at Web Mondays or at BarCamps.

When you look for other CMS at youtube.com you find a load of tutorial videos - why don't we have any of those for Postnuke?

If you have a personal blog: write about Postnuke and what you do with it.

Maybe you have some ideas of your own that you like to share with us. Simply add a comment here!

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]

The new committee consists of:

• Simon Birtwistle
• Frank Schummertz
• Robert Gasch
• Axel Guckelsberger
• Steffen Voss

The Steering Committee will serve for a period of 1 year beginning on the 1st of September.

Congratulations to those appointed to the committee, and here's to another successful year for the PostNuke project!

Drak