PostNuke

Site search

Search results

Number of hits: 122

Jørn Wildt Proposes New Content Module   (News)

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]

Generated on September 4, 2007.

Development Update, March 2007   (News)

Dot 8 evolving: language files progression and legacy functionality
Thanks to the testing of the community users (yes, YOU!), some legacy functions (residing in /includes/legacy/ have been updated by Simon to solve some bugs. This is another proof that we do need everyone to test the releases and help not only yourself to make this release a success! The following files have also been marked 'deprecated', with an accompanying comment in the DocBlock: admin.php, backend.php, banners.php, error.php, modules.php, print.php and user.php. These files shall be removed in the next (post-dot8) major release.
The overhaul of language files has also applied to the Groups, Theme, Users and Profile modules. These modules now have better multilingual options and (by using the pnML function), making it a lot easier to translate the package and showing better logic in grammar for localisations. Furthermore, lots of open bugs have been solved and the templates have been revised also. For example, the emails sent by the Users module can now be adjusted by just editing a template!
David Nelson has offered to completely review the language files for dot8, and we all have to thank Olaf Fichtner for helping revamp the current language constants. The PostNuke Languages Project is actively following the development!
Important change in the language strings is the use of the _CREATEDBY / _CREATEDON and the _UPDATEDBY / _UPDATEDON constants. For better support in other languages, these are replaced by the following:

'_CREATEDBY', 'Created by %username%'
'_CREATEDON', 'Created on %date%'
'_CREATEDBYON', 'Created by %username% on %date%'
'_UPDATEDBY', 'Last updated by %username%'
'_UPDATEDON', 'Updated on %date%'
'_UPDATEDBYON', 'Last updated by %username% on %date%'

and can now be accessed through the normal pnml plugin in the templates.

System modules: pnForm and PageLock
Jørn has moved the pnForm framework to it's own module location within the system directory. Major reason for this is to properly save some pnForm specific javascript and style files. Usage of the module should be quite the same. In addition, some new context menu plugins have been added. These plugins create a popup menu to be used as a right-click context menu. More information can be found in the added files in the pnForm plugin directory, and at the pnForm Wiki Pages.
Also introduced by Jørn is a new system module. The PageLock module is a module that helps enforcing single user access to a specific page, by blocking access to other users when one has it open.
Example: User A opens article X for editing. This is registered on the server. User B tries to open article X for editing too. But as soon as the article editing window is opened, it is overlayed with a transparent dark film and a box in the middle tells the user "Sorry this page has been locked by user A - please wait or come back later".
Functionality: The lock is maintained by an Ajax plugin that keeps pinging the server as long as user A keeps the editing page open. When user A closes the window then the pinging stops and the lock times out. If user B chooses to wait then his page keeps pinging the server for the release of the lock (also Ajax) - and when that happens he gains access to the page. The module can be used on all pages that edites a single item - articles, user data, news items, book pages, permissions settings - you name it.
To use this system, a module author has to use API calls in their own code for adding or releasing a block: pnModAPIFunc('PageLock', 'user', 'pageLock', ...) and pnModAPIFunc('PageLock', 'user', 'releaseLock', ...). To see al this in action, grab the latest nightly snapshot and play around with the HowtoPnForm module: edit a recipe in one browser, and try to edit the same in another browser.

ValueAddons modules: Members_List and EZComments
The Members_List module has been revised by Mark West, with some added configuration options. It is now possible to set the number of (allowed) registered users, and some new blocks (featured user last seen and last x users) have been added. Check out the latest nightly build to see the functionality and options.
Mark has now finished the integration of categories into the user side of the Reviews, Pages, FAQ and News modules. This way, migration of .7x categories into the new Categories module is now supported and can be tested by our users who want to upgrade their .7 site to .8.
Finally, there have been added configuration options for categorization and category titles in the permalinks with these modules.
One hot issue at the moment is the increasing amount of spam that is on lots of websites at this moment. More and more features are to be found on the internet to prevent spam showing on your site. Akismet / Bad Behaviour are one of these. As some already know, Akismet has been applied in EZCommnents for a while. For testing purposes, Mark has implemented a bad behaviour (http://www.bad-behavior.ioerror.us/) function also for testing purposes (as Steffen has found that this could also be a good application). It does need some code hacking to pnApi.php at this moment, so only advanmced users willing to help integreating this feature are invited to test this and report any iussues to the EZComments tracker at the EZComments NOC project page.

Core and API: ThemeUtil and Categories
The pnTheme system has now been converted to the ThemeUtil class. With this conversion, all occurences in the core were updated too. Both the old and the new file are loaded in pnInit for backwards compatibility, but the old file (onTheme) and its functions are now marked as 'deprecated' and will be removed in the next major release.
Also added to the new ThemeUtil is a getModuleStylesheet method which contains the logic from the modulestylesheet plugin. You can do PageUtil::addVar('stylesheet', ThemeUtil::getModuleStylesheet('modulename')) to include the value of pnModGetVar('modulename', 'modulestylesheet') or style.css (in this order) or PageUtil::addVar('stylesheet', ThemeUtil::getModuleStylesheet('modulename', 'special.css)) to include the special.css file in your rendered page.
While unnecessary for correct functioning of the website, one is now allowed to turn off session regeneration completely. This is added because it may be helpful with a couple of undecided bugs in the tracker at the moment.

Module Development: information for 3rd party Devs!
Axel introduced a very nice application called EasyDist. This allows you to create your own PostNuke package easily. You can find it at modulestudio.de. It is still in a very early stage, but you should get the idea. This is all still in development fase and is just for testing purposes at this moment.
A preliminary for the (automatic) creation of packages using EasyDist is that module authors package their modules in a standard way. Right now, there are different file structures in the ZIPs or TGZs the authors distribute. We came to the conclusion that the preferred file structure inside the archive should be - modules - MyModule - pnuser.php etc so that an unpacked archive could be copied inside the pnroot. More information is in t

Generated on March 21, 2007.

Google Summer of Code 2007: This Year We Want to be Part of the Party!   (News)

Program Schedule and Deadline Dates

March 5: Mentoring organizations can begin submitting applications to Google
March 12: Mentoring organization application deadline
March 13: Google program administrators review organization applications
March 14: List of accepted mentoring organizations published on code.google.com; student application period opens
March 23: Student application deadline
Interim Period: Mentoring organizations review and rank student
proposals; where necessary, mentoring organizations may request further
proposal detail from the student applicant
April 2: List of accepted student applications published on code.google.com
Interim Period: Students learn more about/integrate with their project communities
May 28: Students begin coding for their Google Summer of Code projects;
Google begins issuing initial student payments
Interim Period: Mentors give students a helping hand and guidance on
their projects
July 9: Students upload code to the Google Summer of Code project
repository; mentors begin mid-term evaluations
July 16: Mid-term evaluation deadline; Google begins issuing mid-term
student payments
August 20: Students upload code to the Google Summer of Code project
repository; mentors begin final evaluations; students begin final program
evaluations
August 31: Final evaluation deadline; Google begins issuing student and
mentoring organization payments


This schedule is subject to change and taken directly from Google. For the latest schedule please see Google SOC 2007 Wiki

PN Project Goals
The general goals of Google are recognized and extended with our own goals. In short, we want to improve the innovation within the project by offering students the opportunity to propose PostNuke related topics. We aim to offer students an inspiring environment to do research, access to field experts, the ability to create proof-of-concepts and the opportunity to create working functional tools that can be used with PostNuke.

There is a limited list of program goals defined below. Please keep in mind this is an initial list of subjects we would like to shoot for and the final projects are open for discussion. It's important to understand we need guidelines for project proposal evaluation otherwise we'll end up with all nice initiatives, but no choice between the individual project.

The following are a few examples of the types of projects we'd like to see during the SOC 2007.

Here are a few suggested project examples:



Version management of content. Add features to PN, either via hooks or extensions to DBUtil, to allow control of versions of content items. Additionally add workflow processes via the existing workflow module
Translation management. Currently a translation of a content item is an entirely different and un-related item. A project to introduce a method of translating content while keeping the the relationship to the original item (and hence related content e.g. comments, ratings etc.).
Loudblog rewrite based on PostNuke's API
A second project could be the implementation of a better language system + the import of the old system.
OpenID Implementation
Universally implemented content versioning such that it's possible to revert back to old versions of specific content items. DBUtil contains a feature called object-logging which basically gives you the ability to log all changes to objects as they are altered (and even revert back to old versions of an obejct), but a proper GUI with some nice administrative features would be nice.
Integration of the categories system with the nested-set algorithm. The current implementation is path-based which works and carries with it some proper semantic information, but for performance reasons integrating the nested-set algorithm would probably be a good idea.
Implementation of additional features to the category system on the GUI side. This could be advanced AJAX controls, a better user-side editing system, etc.
Integration with Lucene and other search engines ideally through a generic search-engine interface which can then be extended to other backend systems.
A proper universal web services interface for PN.
A proper test suite including a performance testing framework.
A proper data import/export system with the ability to generate multiple data formats (CSV, XML, etc.) including a proper control GUI.


Project Organization
There will be two program guides (admins) that will provide all mentors and students with help and guidance throughout the project. The structure will be flat so there won't be a lot of red tape in the process. The mentors are expected to work closely with each student to accomplish each project's goal and objectives.

For each accepted project into the SOC program there will at least one mentor and one student. Along with the one-to-one support the student will have access to the developers list so they have access to the entire team to bounce ideas off of in the process.

Overview of Mentor Selection Process
The general "criteria" for mentors are:


Mentor is familiar with the PostNuke project and API.
Mentor is expected to work well with others.
Mentor should have knowledge about the topic he/she is going to mentor.
The mentor is responsible for working directly with the student.


Note, before volunteering you should be aware there is a time commitment. We estimate it will take at the minimum 3 to 5 hours per week of your time over a 3 month period. Mentors should also expect to encounter cultural and time zone differences making this a challenging experience on many different levels especially since this will be a virtual mentor/student experience.

Expectations
Commitment to the goals/objectives of your project, your time, mutual respect, and open communication.

Remember when you were a student -- you were there to learn. This is the same thing -- students are here to learn and may not be experienced in working on a team, and will less likely have experience working with someone virtually so as a mentor you're expected to introduce the student to the protocals of this environment.

Students, remember, no question is stupid, don't expect to know everything, and if in doubt ask! Communication is key in a virtual environment and never take anything for granted especially in text based communication since things can often be mis-read or interpreted.

If you are chosen a mentor then what do you get? You get to contribute to a great project, experience working on a virtual team with an international team of great/inspiring people.

Team/Mentor/Student Communications
This is most likely the most important part of the process -- communication is key especially in a virtual environment. And communicating/sharing will be important to the success of each project. So students are expected to put together a weekly report -- it doesn't have to be anything fancy -- just an email updating your mentor about your progress and any problems you working on or having. Mentors are expected to take the lead in solving any problems that might arise with timing, language or cultural barriers. Note, the default language for the program is English so all mentors and students are expected to be able to communicate clearly and effectively in English. When disagreements or conflicts arise within a project team members are encouraged to resolve disputes amongst themselves. If they can't resolve it between themselves then you can ask a program mgr to get involved to mediate the dispute.

Project Tools & Support
You will have access to the following software tools:


The PostNuke NOC (Network Operating Center) where all project related
resources will be housed
Google Project Page (including wiki)
Mentor Application from Google
Developers Mailing List



Student Info
Google provides some time to allow the student to familiarize themselves with the project and tasks. During this time the mentor can prepare the stucture and any documents that will help the student in the goals and objectives of the project.

Some examples include:


Action/Tasks planning so the student will have a clear idea of milstones
for the project.
Provide the student with your communication expectations - i.e., how can
the student communicate with you, skype, instant messenger, email etc.
Review time committments and goals/objectives for the project.
Model good behavior -- take the lead when you see the student needs the
extra encouragement and guidance.

Generated on March 7, 2007.

pnMeeting 3.0 Planned for 12th/13th August 2006 in Stuttgart, Germany   (News)

also a call for papers to anyone who wants to participate. Submissions are welcome, please send them to pnteam AT pn-cms DOT de.

For more information we have a pnMeeting forum available, the recent status can be seen in our wiki and you can register here now. For questions and help about travelling and accomodation send an email to pnteam AT pn-cms DOT de

Generated on May 10, 2006.

.8 Development Summary   (News)

New Theme Module
Recently, the new theme module, which acts as a replacement for Xanthia in the .8 series was committed to CVS. This module corrects many of the established flaws in the .7x Xanthia codebase and also provides new enhancements. New in this module is the ability to assign a custom template to any page on your website, the use of .ini configuration files in themes, the removal of block control in favour of a new Blocks module and the ability for theme authors to provide a 'version.php' file in their theme to provide relevant information to site administrators.

Using .ini configuration files in the new Themes module brings two advantages over the current setup of Xanthia. Firstly, theme generation and display are much faster as no database queries are required to build the layout. This should provide a marked performance increase in .8 websites. Additionally, it is much easier for theme authors to export their themes, as in the new Theme module the details previously contained in xaninit.php in PHP code are now automatically generated by the Theme module.

Due to the sweeping changes in this new module, the user interface has been completely redesigned. While we realise this will take some getting used to, the new interface is more intuitive than previous versions and logically follows the layout of the Modules module when displaying the available themes. Additionally, all theme related settings have been moved from the Settings module to the Theme module, and the user theme switcher is now part of the Theme module display.

Themes used under the .7x Xanthia module will need upgrading to use the new .8 Themes module. This is a relatively simple process which is mostly handled by the Themes module itself, as both systems are based on Smarty the template logic is the same and there are few changes to the tags themselves. These by and large stay the same with one notable expection, block tags are replaced with the plugin call where name is the name of the block zone to display.

The recoded Blocks module has yet to be checked into CVS, however we anticipate this within the next week. Until that time, the Theme module in CVS is nearing completion and is fully functional.

New Themes / Removal of Old Themes
Two new themes designed for the new Theme engine have been added to CVS. These are free templates from Open Source Web Design, and serve as an example of what can be achieved with the new module. The new themes are tableless and HTML compliant, which along with the improvements in compliance in the rest of the codebase serve to ensure PostNuke remains one of the few content management systems to take HTML standards seriously. All output in .8 will be XHTML valid.

To this end, the old themes that have been present throughout the .7x series are no longer in CVS. While they can be easily converted to work with the new Themes module, they use table based layouts which do not conform to the standards PostNuke has set for output. A appearence overhaul is well overdue for the PostNuke codebase and so a set of new themes will be available with the .8 release.

Workflow Engine
The release of .8 will also bring a new statebased XML Workflow engine to PostNuke with simple API implementation. Additional enhancements are planned to include a workflow schedular to process workflows at timed intervals in batches.

Use of the module is simply a case of adding a directory 'pnworkflows' to your module containing a set of workflows with operations, states and actions. The workflow engine also fully supports the PostNuke permissions system. Documentation for the module will be released with the first .8 Milestone.


XML Event Based Forms
GuppyForm allows a developer to describe a form content and layout in XML with an event handler bringing automatic validation. This can drastically reduce the time taken to develop user input forms. Can be combined with pnRender templates or used standalone. For those that like OO, and descriptive coding, this is an interesting option in the framework.


Completion of Users Module and Profile Enhancements
Another recent change to CVS are updates to the Users and Profile modules. These now almost fully functional, with huge improvements to the dynamic data system now in CVS. New field types avaiable for user input are date fields, calendar 'select date' fields and combination fields where a number of seperate input types can be combined. The new users module also allows for the use of SHA-1 or MD5 password encryption, you can store the user's last login date in the database and finally the registration process has been improved to include the option to vaidate user's email addresses through an activation link. All these improvements are optional and can be enabled and disabled through the Users module administration interface.

Template Updates
As part of an overview of usability and update to the 'look and feel' of PostNuke many of the module templates have been enhanced. These range from subtle changes to much more obvious improvements in the location of links and reporting of status messages. As previously mentioned all templates validate to XHTML standards and further improvements will be made before the final release of .8.

Languages Changes and config Directory
pnDefineMachine is now the recommended tool to use for translating PostNuke into other languages. This third party module scans the whole codebase for language defines and provides an easy to use administration form for translators to write new language files. A new version of pnDefineMachine was released recently, and to facilitate its future development a number of internal define changes have been made. These should not, however affect translators themselves.

Another addition which does affect translators and site administrators is a global language file which can be edited by users and is safe from being overwritten on an upgrade. PostNuke now contains a 'config' directory where all PostNuke's configuration details are stored. The files config.php and config-old.php have been moved to this directory, and furthermore the directory can contain both global template overrides (in addition to theme-specific overrides in use in .7x) and also global language defines. While it is not currently possible to override core language defines through this change without generating a PHP Notice, you can store your own language defines for use in, for example, themes. Any changes you make here will then remain intact throughout any upgrades you may carry out.

.8 Milestone Release Date
After the Steering Committee Meeting held this Tuesday, a tentative release period for .8 Milestone 1 has been set. We currently aim to release .8 MS1 in the third or fourth weeks of April, however this may change if the codebase requires further work for the release to be of the required quality. A milestone release is an opportunity for third party module developers to test their modules with the upcoming release. It is not intended for a production environment and user support is not available for this release, however support for developers will be provided through the forums. The milestone will not be feature complete, and may not be stable.

The milestone can be taken as an indication that the codebase is beginning to get to a usable stage from which we can work towards

Generated on March 31, 2006.

PostNuke Organisational Structure   (News)

Task Forces
Task forces may be formed as necessary for individual tasks. An example of this are is PostNuke site redesign task force. These are more dynamic team elements, led by a specific member of the PostNuke team (not necessarily a team leader named above). Task forces are more temporary, and could include members of the community who are not PostNuke team members but offer a specific skill set needed for the task in hand. Leaders of task forces should also report to the Steering Committee monthly.


Reporting Structure
Each team and task force leader should report to the PostNuke Steering Committee approximately once per month outlining progress (if any has been made). 'Reporting' is meant in a loose sense, and can be a quick informal chat or an email. This information is then combined with information on the activities of the Steering Committee and sent to the postnuke-teams list for internal review. When internal discussions on the information presented have taken place (this could be setting goals, making suggestions, improving plans), a community announcement should be made.

This is not set in stone. Everyone is a volunteer and timescales are flexible as a result. It is also entirely acceptable to report 'nothing has been done', providing the project can be seen to progress at regular intervals. Deadlines and completion dates will not be set unless absolutely necessary, such as when one project is dependent upon the actions of another. In general, flexibility is the key.

Team Members
Team leaders in bold.
All teams come under the Steering Committee excepting development, which at this time has autonomy for the purposes of keeping the development of PostNuke software objective.

PostNuke Steering Committee
Simon Birtwistle
Frank Schummertz
Robert Gasch
Franz Skaaning
Frank Chestnut
Jörg Napp


Development Team
Mark West
Andreas Krapohl
Robert Gasch
Frank Schummertz
Frank Chestnut
Simon Birtwistle
Jörg Napp
Jørn Wildt
Drak



Support
Simon Birtwistle
Mike Halbrook
Documentation
Jörg Napp
Simon Birtwistle
David Nelson





Technical Administration
Drak

PostNuke Site Administration
Drak
Simon Birtwistle
Mark West
Andreas Krapohl
Frank Chesnut
Frank Schummertz
Franz Skaaning
Robert Gasch
Jörg Napp
Vanessa Haakenson

PostNuke Pro Site Administration
Simon Birtwistle
Andreas Krapohl
Mike Halbrook
Vanessa Haakenson
Drak
(Project leader yet to be appointed)

Server Administration + Remote Restart
Drak
Mark West
Andreas Krapohl
HostNuke Staff
Languages and Localization
David Nelson
Assorted Language Pack Maintainers
Communications and Marketing
Franz Skaaning
Simon Birtwistle
Design
Team yet to be appointed.
Security
Andreas Krapohl
Quality Assurance
Patrick Cornelissen
Sebastian Schurmann

Generated on December 2, 2005.

The Road to .8 - Where are we, and where are we going?   (News)

The modules included in .760 which are templated, and taken direct from the .8 CVS are as follows:

Admin
Admin Messages
Autolinks
AvantGo
Blocks
Censor
Credits
Ephemerids
Groups
Header_Footer
Legal
Mailer
Members List
Messages
Modules
Permissions
pn_bbcode
pn_bbsmile
pnRender
Quotes
Ratings
RSS
Sniffer
Typetool
Xanthia

This represents a significant percentage of the .8 code, but there is still more to do. The aim of this article is to try and outline some of what remains to be done before we can consider a release of .8.

Six Main Projects for PostNuke Development
We have identified six main sub projects vital for a release of .8. These projects cover wide areas, and each are at different stages of completion. The six projects, in no particular order, are:


Integration of Open Star object library and Database Utility
Integration of Open Star category management
Installer
Xanthia
User management
Finishing of content modules

This article also includes a little information on some of the other new code to be introduced with .8 this is at the end, where we look at EZComments and the Error Handler.
Integration of Open Star Object Library and Database Utility
The new Database layer reuses the existing pntables information to provide an
object representation of database rows. The advantage of this approach is that
it allows you to basically remove manually coded SQL statements and replace
with what's typically a 1-line statement. Some sample invocations of such code
are shown below:

[code]
$myObj =& DBUtil::selectObjectByID (, $id);
$myObj =& DBUtil::selectObject (, $where);
$myObjArray =& DBUtil::selectObjectArray (, $where, $sort);
DBUtil::insertObject ($myObj, );
DBUtil::updateObject ($myObj, );
[/code]
These functions all return an associative PHP array, or in the case of array
functions, an array of arrays. The fields in this array are cleaned up in
the sense that any field prefixes have been removed. This DB API also
gives you the ability to have generate associative (object) arrays, expanded
arrays with other table fields joined in (which means that you can save SQL
lookup calls) as well as store/retrieve dynamic attributes without altering
the underlying table structure. Together this provides a highly flexible API
which can take care of all storage & retrieval operations.

On top of the DB layer sits the Object Layer. Objects provide a component model
which features transparent persistence facilities. Objects/Classees are loaded
though the Loader API though
[code]
Loader::loadClassFromModule (, 'foo') //

Generated on November 3, 2005.

Moving on: Better PostNuke ShortURLs   (News)

meaning the search engines choke on them and thus doesn't index PostNuke sites well, while making the URLs hard to post to people in email or in forums. For instance, a news link looks like this:
/index.php?name=News&file=article&sid=123&mode=thread&order=0&thold=0

For some time now, PostNuke users have cried out for better Search-Engine Friendly URLs, and for the past few years, the only thing available has been a theme hack first detailed by Karateka (possibly E. Soysal before that, the links in the article are dead) way back in 2002, since worked on by ColdRolledSteel (Craig Saunders), and consequently me.
The advent of the ShortURL hack has seen sites hosted on Apache servers with the URL Rewriting module (mod_rewrite) enabled get URLs like
/Article123.html

for the above link, where certain assumptions have been made about the default settings for mode, thread and threshhold. A big improvement, but not very descriptive, and it comes at the cost of heavy post-processing of the site's content for links. Also, Search Engines use link keyword relevance in their rankings, and Article123 doesn't say much about the link, except that it's an article with the id 123.
As Karateka pointed out at the time in his article, a problem in implementing friendlier URLs with virtual directories is that all paths in PostNuke are relative, ie relative to the site root folder where index.php is located, and fixing it then would have required extensive changes in the core. That is, a URL like /Example/view.html would result in the browser looking for all links relative to its present location, ie in the nonexistant subfolder called Example, and subsequently it would fail to find the linked stylesheets, images etc, and all links from the page would similarly fail.

Unfortunately this situation has not changed in the intervening years, but as PostNuke modules are becoming API-compliant, they reference the same system function to build their URLs, so fixing this function and other associated functions to use root-relative links(1) will fix all compliant module URLs. But that leaves all other links, like images, Javascript, and stylesheets. The move to templating with Xanthia (for themes) and pnRender (for modules) is also making it easier, since Xanthia templates use a Xanthia variable to reference the theme's image directory path. So fixing Xanthia and pnRender will fix most paths in Xanthia themes. The exception are stylesheet and Javascript link paths and any links in the theme header, for which new path variables need to be introduced, so some updating of Xanthia themes is required. This makes the transition period to PN 0.8 an ideal time to introduced these changes, since few Xanthia themes have been released so far, and core modules are only just being converted to pnRender.
I stopped work on ShortURLs some time ago (before pn0.75) on the advice that a core module was being developed; however I have seen no evidence of this to date, and there is no indication in the upcoming PN 0.76 or CVS that there is anything coming. I got curious a month or so ago, and was somewhat dismayed at what I found.

Since then no progress seems to have been made on PostNuke ShortURLs. In fact, the current Xanthia filter hack has regressed, becoming bloated with complex and wholly unnecessary Regular Expression rules, many badly written with duplication and a number of bugs, especially in the accompanying htaccess file, going from the 15 rules proposed by Karateka to a massive 89. So, I set out to try and fix it, but ended up revisiting the idea of a core implementation using virtual directories to more logically structure the URLs in a way that is not only Search-Engine Friendly, but more User-Friendly.

Along the way, I've also been sidetracked and made a direly-needed new themable tab system for the Administration area based on AlistApart.com's Sliding Doors technique and consequently overhauled most of the Admin templates and a few User templates too, partly out of necessity due to the new Adminpanel, partly because they badly needed it. Those of you who have tried the pn0.76 Release Candidates would know that the templated output in them leaves something to be desired, drab and somewhat unprofessional-looking due to all the styling and CSS-classes having been ripped out, leaving a basic grey and white look with overly large headings and no theme tables for backgrounds. Hardly what you would call of Release Candidate quality. So pnRender and its plugins have been fixed to allow the use of Xanthia-like theme-colour tags as well as a tag for root-relative paths needed for ShortURLs, and the opentable functions have been fixed so that proper themed borders can be used. In fact most of the changes are in fixed templates, plugins, and module files.

My proposed implementation still retain the Xanthia filter for backwards compatibility with older themes, modules and blocks, but has been wholly rewritten and pared down to 24 rules, including a rule to fix all links to be root-relative. As PostNuke is in transition to be fully pnAPI-compliant by PostNuke 0.8, the remaining ones can gradually be removed altogether as themes, modules and blocks are updated. There's also a version for AutoTheme.

This particular scheme is experimental and may be tweaked or improved upon. It seeks to reduce the reliance on the Regular Expression(2) post-processing for links and introduce more user-friendly URLs that have more relevance for people and search engines alike by using virtual directories to visually distinguish sections of the site by module and function, such as
/Example/View.html

and for the News articles introduce Category, Topic, and Title information in the link:
/Category/Topic/ArticleXXX-title-of-story.html

For instance for a news story in the category Computers and the topic Postnuke called "PostNuke Shorturls", you'd have the URL
/Computers/Postnuke/Article123-PostNuke-Shorturls.html

This is a clear, concise and informative link that tells the user and search engine alike something about the link before going there, while retaining backwards compatibility with links of the old ShortURL scheme. It more closely emulates the way we think and organise information, using the folder analogy where we have a clearly-labelled Computer category folder, under which we have the various sub-categories - Topics - with various articles. In this case, we're using a virtual file anchored by the word "Article", clearly identifying it as such, followed by the article number and title. There is backwards compatibility, so that older links for Article123.html will still work.

In this instance I've excluded the News keyword altogether for brevity in favour of the Category and Topic keywords which insinuate News anyway, though there is nothing against being consistent with all the other ShortURLs and having the Module appear first, as in
/News/Computers/Postnuke/Article123:-PostNuke-Shorturls.html

This is for the special case of the core News module though, a more generic method is needed overall for URLs with various unknown parameters passed in the query string. This implementation uses the scheme:
/Module/Function-Param1:Value1-Param2:Value2... -ParamN:ValueN.(p)htm(l)
where the Query string parameters are tagged onto the virtual filename grouped by colons and separated by hyphens, the idea being to use commonly-used characters we might normally use in a list to make it look as natural and readable as possible. It may be a less-commonly used character than the hyphen is needed, like the tilde ~ character, since some parameter values may use a hyphen, in particular usernames. This is not a problem if passed as the last parameter, where it may contain any character. So if the module developer kept this in mind, it might not be an issue. I'm not aware of it being one so far. The PostCalender ShortURL plugin deliberately places uname, if present, last.

The extension is not necessary, but used for convenience. The 3 types used are either one of html, htm, or phtml, the latter useful to distinguish when you want to link to real HTML files on the site. The extensions as well as the option to use ShortURLs or not is set in the Settings panel, though I've only offered the option of html and phtml, since frankly the MS DOS-holdover extension htm annoys me.
Older URLs are marked with a + before the Function name, as in
/PNphpBB2/+profile-mode:editprofile.html

so that the server can translate it correctly. If the directory doesn't actually exist, entering
/Example/

will redirect to the Example module main page (Apache only)
/Example/main.phtml

which in return gets rewritten invisibly to
/index.php?module=Example&func=main

Otherwise, if it does exist, the index file of the relevant directory will be opened.
Similarly, with
/HTML/filename.html

if the file exists, it will be opened, else PN will look for
/index.php?module=HTML&func=filename

It is still possible to tag on query strings like
/ModName/main.phtml?theme=seabreeze

or
/ModName/main-theme:seabreeze.phtml

will both be translated to
/index.php?module=ModName&func=main&theme=seabreeze

There are any number of possible ShortURL systems, the simplest being to simply chop the URL into virtual directories, like /News/123/ from the above News example as some do. Xaraya uses a variant of this for news, though it doesn't use mod_rewrite, so appears like
/index.php/news/123

Again, this is concise, but contains few meaningful keywords other than the module name News. You can combine the two methods for News and have
/News/Category/Topic/123/title-of-article

which works very well, but loses some of the elegance of the above philosophy, since the latter part breaks up the virtual file into 3 with no anchor words, which is not how we organise information.
For generic URLs, there are a number of methods; for instance Mambo, another CMS, use generic ShortURLs like
/component/option,com_newsfeeds/catid,5/Itemid,7/

for a News URL like
/index.php?option=com_newsfeeds&catid=5&Itemid=7

where the querystring values are grouped by commas and separated by forward slashes (virtual directories). It is a ShortURL, though in this case not shorter, and doesn't have any useful keywords, other than "newsfeed", and is not very human-readable. For a generic URL, this is somewhat unavoidable, but can be better than that.
This implementation also contain a way to customise ShortURLs on a per-module basis through a file called shorturls.php placed in the module folder (see the Example module), such as the News URLs, or 3rd party modules like PostCalendar, which instead of the full URL like
/index.php?module=PostCalendar&func=view&tplview=&viewtype=day&Date=20050405&pc_username=&pc_category=&pc_topic=&print=

with the above generic ShortURLs would be rendered as
/PostCalendar/view-viewtype:day-Date:20050405.html

but with customised URLs become
/Calendar/05-04-2005/day.html


The beauty is, though, once we've created the groundwork in the core of PostNuke, any implementation will be fairly easy.

1) Root-relative links: Links relative to the server site root (eg /nuke/filename.html), which stays static, as opposed to relative to the present file (eg filename.html).
2) Regular Expression (RegEx): A complex pattern-matching language that can look a bit like a mathematical formula, used in the Xanthia ShortURL filter at /modules/Xanthia/plugins/outputfilter.shorturls.php.


----------------------------------------------------------------
If this were Mambo, I'd charge you 80 Euros for all this (the price for SEF Advance), but because you're all such nice people (except that guy up the back, you know who you are :) ), I'll let you have it for free.

A PDF of the ReadMe included in the package, but with additional screenshots, is found here (570kb).

I've also written a more technical ReadMe on installing ShortURLs, included in the package under the docs folder, and also found here.

here's a test of the tab system using the Aqua theme. It also comes with an XP-styled theme and the default-CSS-based one. I hope you like it, because it took a lot of work to perfect.

OK, screenshots: Well, no point having screenshots of URLs, so here's some of the tab system and modified SeaBreeze and PostNukeBlue themes' Admin templates instead:

1. The main adminpanel in PostNukeBlue with the Aqua-themed tabs, hovering over the Settings panel.
2. Same as above, but with the Theme Override set under Modify Config and with a tabs.css stylesheets in the theme's style folder. The rounded corners are only visible in Mozilla/FireFox.
3. The Luna tab theme in SeaBreeze, hovering over the 3rd Party tab.
4. The Xanthia Admin tabs using Aqua tabs in PostNukeBlue, hovering on Theme Settings.


And finally, the downloads:
I started out fixing PN0.75, so there are 2 downloads: One for PN0.75, and one for PN0.76rc4. I'll update it once the PN0.76 final is released.
Please backup your site before installing these patches, since a lot of system files are replaced. The PostNuke 0.76rc4 ShortURL package is rather large, consisting of some 400 files in a 1Mb zip file. The PN0.75 package has some 170 files and is around 800kb. Most of the changes are drop-in changes that doesn't necessitate updating of modules, but there are some exceptions in the PN0.76 package, in particular the Settings and Polls modules, where you need to first go to the Module list, regenerate, and update. Specific patches for popular 3rd party templated modules like AutoTheme and PNphpBB2 are included, but only a limited number of 3rd party modules have been tested with this package. No changes are made to the database, but it is still a good idea to back that up as well. You have been warned.

PostNuke 0.75 ShortURL package (833kb)
PostNuke 0.76rc4 ShortURL package (1Mb)

Two of the updated core themes:
PostNukeBlue (249kb)
SeaBreeze (120kb)


Feel free to discuss this proposal in the forums.

Enjoy!


Martin Andersen 8/7/200

Generated on July 9, 2005.

Email Virus Targetting PostNuke Users   (News)

Generated on June 15, 2005.

PostNuke Meeting Denmark   (News)

If you want to attend this meeting, please write Genix an email at Genix@genix.dk with your name and adress.

Place:

Gate58 (internet café)
Vestergade 58
8000, Ã…rhus C
Denmark

Gate58 homepage

PostNuke Denmark


Price 65 Dkr - Including a Sandwich and snacks :)

If you need a place to crash, there will be room in my apartment.

Generated on July 23, 2004.

Page 1 / 13 (1 - 10 of 122 Total)