PostNuke

Using pnmodcallhooks you can call the hooks directly inside your templates and assign the result to an array. The content of the array now can be displayed everywhere in the template - you can even place the Ratings above your content and the comments right of it.

An exact "How to" can be found in the Developer Wiki".

For attackers it is of example possible to read the server's password file simply by calling a special URL.

Links:
File Disclosure in Pagesetter for PostNuke,
Download Pagesetter 6.3

The formula is: Customization in the theme only!

Step 1: The Postnuke templating engine looks for templates in different places and it always looks first in the theme and then in the module folder. So if it finds the needed template in the theme it stops searching:

/themes/YourTheme/template/modules/ModuleX
is the equivalent for
/modules/ModuleX/pntemplates

Everything that is contained in the module's templates folder can be stored in the same manner in the theme's folder. For example EZComments contains several template-sets in subfolders these can simply be copied into the theme. The same applies of course for the plugins that are stored in the module's templates folder.

Step 2: If you have to write your own plugins, store them in
/themes/YourTheme/plugins/ModuleX
instead of in
/modules/ModuleX/plugins or something

Step 3: If you change a module's style sheet you can place it at
/themes/YourTheme/style/ModuleX

You see: There is a place for everything that can be customized in the theme folder. And the best thing is, that this feature had been in PostNuke ever since version .750. In the end you won't have any customizations inside any other folder but the themes folder - and if you don't overwrite that folder, you will never again lose changes during updates.

Now there is one objection you could make: When you don't update a module's templates you might not benefit from new features - the old templates might also be disfunctional. - Of course this is a problem. But with the above solution you can at least keep your layout and then include the new stuff.

Note: Only for the language files is no such solution available yet. This will be solved in future version though. The redesign of the language system is a .9 topic.

1. On the way from Postnuke 0.1 to Postnuke 1.0 the step between 0.7 and 0.8 will account to roughly 80%.
2. PostNuke .8 is the big step to get rid off the old PHPNuke code.
3. PostNuke .8 will get rid off the old content modules and make them community projects so that the core development does not have to take care of them anymore. Modules are better developed by module developers.
4. Postnuke .8 will contain a lot of stuff that will make module development much easier and save a lot of code. But as always in PostNuke: The APIs are an offer. You can use them, but you don't have to. And if you want to start using for example DBUtil for easier database access you don't have to use pnForms for your forms-validation.
5. With .8 all modules that were at least semi-compliant to .7 code guidelines should work or should work with little adjustments.
6. The idea is to make PostNuke a full-fledged web-application framework that can flexibly be used in various scenarios from simple static pages to complex communities.
7. Nevertheless there will be "distributions" of PostNuke to match the basic needs of communities, blogs, static pages aso.
8. So Postnuke .8 will not be .764 with more features. It's a different but compatible system.

Even though you might not really hear much from "the inside" of core development - besides the bi-weekly reports - You can be assured that core developers are not an arrogant or ignorant bunch of code wizards. They read the forums, they read the feature request tracker and they read e-mail. And they make uo their minds on what you say - but they won't always answer and nevertheless implement your suggestions. ;-)

First of all, due to the release of 0.8.0.0 MS3 on Feb 7 2007, some information in this article has already been applied to this MileStone release, and some is part of the current nightly build from SVN. The items that are part of the MS3 package are indicated with a (*).

Installer and upgrade path

The installer for .8 now also checks for a web-user writable pnTemp directory. Before, only it's subdirectories had to be writable. However, more and more modules need a (temporary) writable directory of their own (for example cache directories for image creation or rss feeds). With a writable pnTemp, these modules are now easily allowed to create that directory themselves if it does not exist. (*)
The upgrade path from the historic .7 family has been updated: Some code has been added to migrate blocks placements into the new block_placements table. (*)
Furthermore, old style (legacy) blocks can now be stored in the /config/blocks directory. The specific files do need to be copied manually from the old /includes/blocks directory to it's new location. (*)

Core (API) and environment variables

In the core pnAPI, get_magic_quotes_runtime() was called lots of times for different purposes. With an internal caching method, the result is stored in the global PNRuntime array. Big advantage is that the site's speed has been significantly improved. (*)
Robert has added an enhancement to allow the pnSessionGet/Set/DelVar functions to accept an (optional) path argument (arguments 'autocreate' and 'overwriteExistingVar'). This will allow for easy setting of complex array structures. The change only adds extra arguments to the existing functions and are backwards compatible. At this moment, no direct usage has been committed yet.

PostNuke Object library

At this stage of development, a lot of changes are (and have been) made to the object library. Most of them are 'simple' bug fixes, but some changes are worth mentioning here (additional functionality or changed methods).

In the DBUtil class, there now exists a new method to increment a field with the function incrementObjectFieldByID. This can be used by module authors for updating read counts of content items for example. (*)
Additionally, the function selectScalar has been added (which takes a SQL quesry as argument). This is mostly useful for places where you want to do a "select count(*)" or similar scalar selection.

The utf8 conversion functions (convertFromUTF8 and convertToUTF8) have moved from AjaxUtil to DataUtil when solving a bug to keep the users input in Ajax driven fields as they are intended.

While solving a Google AdSense script bug, where the script tags were automatically cleaned by the safeHTL output filter, a new feature has been added to FormUtil: Before cleaning posted input on an already installed site, the FormUtil now checks if the current user has overall admin permissions. This allows site admins to input potentially harmful tags (javascript for example), but it's their site after all!
Jörn has improved CSS style handling in pnForm plugins, as he has changed some pnForm classes to be derived from pnFormStyledPlugin, which in itself is derived from the original pnFormPlugin.

Because it's better to read the languages directory first for available languages and compare that result against the full list of languages in stead of the other way around, the LanguageUtil has a new function getInstalledLanguages. This now significantly reduces the number of directory checks.

To ensure that most commonly used plugins are found as early as possible, the order in the pnRender class, where the system is searching for plugins, has been modified. The current correct order for the 0.8 distribution is:

1. system/pnRender/plugins
2. system/Theme/plugins
3. config/plugins
4. current theme-directory/templates/modules/$module/plugins
5. current theme-directory/plugins
6. current module-directory/pntemplates/plugins

Furthermore, two new variables can be added to the rendered output page using the PageUtil class. First is 'description', which is default set to the current site slogan. Second is 'footer', with the ability to add custom content just prior to the closing body tag. The latter function is applied as an outputfilter.
Finally, an additional parameter 'display' is added to the pager plugin, which can be set to either 'page' or 'offset'. This is (why am I explaning, isn't this rather self-explanatory?) to allow paging by pages, rather than offsets. It also mirrors the 'show' parameter that exists in many templates (based on the example module) but was never actually implemented.

Last but not least, the Theme class has now added support for a filters section in a page configuration file. This allows for loading of, in the first instance, custom output filters. Note there is no user interface to the functionality the moment.
And, why not, the Atom theme has been updated to Atom 1.0

Module modifications

The following modules have been updated for improved .8 compatibility, or just to make administering those modules easier.
The User module now has the long awaited alpha pager for browsing users. (*)
All occurences of the block rendering APIs (read by the Blocks module) have changed from the old style call "return themesideblock" to "return pnBlockThemeBlock". (*)
To the Settings module there has been added a configurable separator for permalinks (*)
Furthermore, a switch to globally disable JS Quicktags (which adds a set of buttons for common html tags to enabled textareas) is now part of the Settings module. (*)
Both the Ratings and the Multisites module are modified to meet the new standards of coding and templating. Work still needs to be done to both modules, so testing functionality for these modules may not be that worthwhile as yet. (*)
The Theme module takes over from the Xanthia module in an upgrade. This doesn't mean that it is not Xanthia anymore: it still is actually the Xanthia 3.0 engine (*).
To the Recommend_Us module a display hook has been added. This will add a list of social bookmark links, like the Diggers plugin also does.

Language files overhaul

The language defines in some modules have been reviewed and adjusted to the naming conventions of .8 (see also Dev Update 2006-06). This means that module-specific language defines start with a module-name specific prefix. Additionally, some new general language strings (using the pnML function) have been added to the core language file. The major effect this will have is to subtantially reduce the number of strings that need translating.
These changes are applied to the following system modules: Admin, Admin_Messages, AuthPN, Blocks, Mailer, legal, Settings and SysInfo. ValueAddons modules will follow later.

PostgreSQL DBMS testers wanted

The .8 DBUtil class, as mentioned many times before, makes it possible to run PostNuke on different DBMS platforms, like PostgreSQL, Oracle and MSSQL. Most of our test users still use MySQL, but the Dev Team would also like to encourage users to test the .8 package on a PostGreSQL installation. Windows users having a Xampp environment can find installation packages on the PostGreSQL website (Win32 FAQ here). As Oracle and MSSQL still have known bugs / issues, testing in these environments may lead to already known errors, so reporting those at this stage is not that useful. When these environments need testing, this will be announced in the specific release or a Dev Update.

There requirements are:

* Distribute under an OSI-approved license.
* Have at least 200,000 public internet users and 5,000 downloads per month.
* Implement OpenID 2.0 support as a Relying Party (RP) or Identity Provider (IdP).
* Pass the OpenID compliance testing tool (to be released in August 2006).
* Make enabling OpenID no more difficult than changing one configuration setting (there can be more optional configuration settings).
* Distribute the implementation as part of the project's core (it cannot be an additional download or patch).
* Place an OpenID logo in the signon form (as on this site).
* Answer "What is OpenID?" (or link to an answer) near the signon form.

I think the 2 requirement is hard to meet for any piece of software. But IMHO PostNuke is popular enough.

As you know Postnuke .8 includes a new login system which is open to all kinds of authentications. It should be a piece of cake to implement the OpenID-system. So if you are interested in doing the job, you should get into contact with the OpenID-people.

Moreover PostNuke could use some pro comments on the OpenID page.

Links:
OpenID Code Bounty

Development Updates

If you're interested in what's changed between the release of MS2 and MS3, links to the development updates published since MS2 are available below:

• Development Update, January 2007-01
• Development Update, December 2006-06
• Development Update, November 2006-05
• Development Update, October 2006-04

Simon Birtwistle
PostNuke Steering Committee

Semantics is the science of language structure. Microformats are a means to add meaning to internet documents. With classic HTML you can e.g. mark that a paragraph is an address with the address-tag. However, a machine can't recognize where the name or where the street is. Microformats specify a number of classes that you can use to mark all parts of an address. E.g. you put the first name into a pair of span-tags and give it the class "given-name". The same you do with the last name - the class-name would be "family-name".

You can mark all parts of an address in this manner. The result is a program that knows which class is what, can split up the address and work with that. For example you can move an address to your Outlook Address Book with a single click (see Live Clipboard).

There are several of these Microformats. Only few a are fully specified by now (hCard, hReview and some formats for the description of links.) But there are about 50 in discussion.

As an example for the technique and the way you can implement it into your own modules or templates I designed 3 publication types for Pagesetter: hCard, hCalendar and hReview. You can import them into your Pagesetter installation and look at the templates. You can also build your own address books, calendars or reviews with it. I would love to see them working on the one or the other site.

Links:
microformats.org

First of all, a happy new year to all users of PostNuke on behalf of the complete PostNuke team: Coredevs, Steering committee and other Board members. Let's all hope this year will be productive and succesfull for all of us. And of course: a finished .8 version of PostNuke is something we are all waiting for.
MileStone 3 is waiting around the corner: A feature freeze so far has speed up the progress and only a few bugs are blocking a release. The next development update will probably be submitted after the MS3 release.
OK, here goes!

API functionality

Introduced is a pnShutDown function to gracefully terminate the application framework. This now replaces all use of exit or die and also fixes some oddities caused by PHP's shutdown process.
Mark has replaced all old themesideblock function calls with newer API call pnBlockThemeBlock. Furthermore, he has added a raw text option to the PageUtil::registerVar (former pnPageRegisterVar) system.
The AjaxUtil is now using internal json_encode() if PHP >=5.2.0.

Object Library and classes

For the SessionUtil / RandomUtil, Drak has put his hands on improving the randomness in the generation of the AuthKey and passwords. This is done by extending the possibly characters used, and the length of the key (length also now being random).
Also, the AuthKey generation makes now use of the (updated) RandomUtil class. A big advantage is that the random data generation is done in one place, so a change will affect the complete system. This is actually with the complete Object Library: changes can be made in one place with the benefit that all calls are updated.

The DBUtil has now a renameTable method and a renameColumn method for easy manipulation of table properties without having to worry about SQL code. The latter (renameColumn) is a quite new function, so there may be some adoDB bugs.

Finally, pnPage.php is converted to the PageUtil class. This means that any 3rd party module developers should update their modules to make use of the new class. A call to (for example) pnPageSetVar('title', $title_var) must be updated to PageUtil::setVar('title', $title_var). The pnPage.php does not remain for backward compatibility. Examples for the needed changes can be found in SVN submission 21099. The Wiki documentation for Page variables still needs updating however.

pnForms: functionality and documentation

Jørn has been updating the pnForms toolkit extensively. Most important is hat the documentation in the files is more complete, and the Wiki documentation page has been updated. A summary:

• Added authkey checking to pnForms.
• Added min/max validation for integers.
• Changed "classHtml" to "cssClass" in "pnForm" plugin for consistency with the other classes.
• Added a language selector "pnFormLanguageSelector".
• and much more...

All plugins now render unknown parameters "as is", so you can add "onclick" and such like that the system doesn't know of.

System modules: Categories, Search and Blocks

In the Categories system, there has been added support for a 'field' parameter.
The search module is as good as finished, and also displays a sum of all search hits too. An additional parameter is added to allow for searches that aren't going to be performed on a DB. Finally, it is now possible to search in RSS feeds.
The Blocks module has been updated, and now has a user friendly functionality for drag-drop between block positions and placements in one screen. This is done with Ajax technology (thanks Frank for simplifying and enhancing this), so javascript should be enabled to use this (non-js fallback available). Furthermore a XML/XSL block has been added (a generic xml/xslt block and modifier).

ValueAddons modules

Faq: implemented custom short url handler and permalink structure
News: implemented cache handling
Feeds (was RSS): implemented categorisation in admin panel, added short url handler, added title field.
Also, the RSS module is renamed to Feeds to better reflect it's purpose and to prevent clash with rss theme when using directory based URL's.
TinyMCE: Upgraded tinymce to v2.0.9
Reviews, Referers, Stats: Converted to API and pnRender compliant module, updated table management code.

pnRender Plugins

Mark has added an output filter in order to auto-magically title the administration pages, which makes navigation a bit easier.
Also, Axel added a new optional parameter to the pager plugin for link anchors (e.g. #comments). For example, these Development Updates rquire me to manually add the anchors to an (non existing) url.

Let's take an example you probably recognize: input of data for a new article on your CMS. You have fields for the title, the content, and an expiration date, and the title is mandatory, so the user *must* write something.

To do this you must go through the following steps:

1. Read the posted values one by one.
2. Verify that the title contains text (validation).
3. Verify that the date is really a date (validation).
4. Generate an error message if validation fails (error handling).
5. Regenerate the input form, but this time include the previous user input (state management)
6. Possibly convert the date to a format readable by the database (database access).
7. Transfer posted values to database.

All of these things must be done for each web form you create. This is very tedious and error prone work, which is why pnForms was introduced to PostNuke: pnForms address all of the 1-6 issues above, and with the use of PostNuke's DBUtil API you can start creating web applications with much much less programming than ever before in PostNuke.

Features

(excerpt from wiki docs):

First of all - pnForms is a clean extension to pnRender! You can do all the stuff you are used to, but you can also make life easier with the extensions.

pnForms is event driven - you supply an object (the page event handler) to the pnForms framework which will in turn call different methods on this object when interesting things happen, like for instance the click on a button.

pnForms builds on Smarty's plugin system and allows you to extend the framework with new plugins (like for instance a GPS input field for your next project). Plugins are heavy on object oriented programming which means you can reuse and extend existing plugins by simple OO-inheritance.

Plugins are also event driven like the page event handler, so your plugin will get notified when certain reactions are required such as rendering the plugin or reading data posted from the web form.

pnForms manages state for you - all variables in your page handler object is persisted accross different calls to the browser. So if you save an article ID in the event object during the first page rendering, well, then it's still available after the next postback of data from the form.

pnForms handles input validation - you just insert a plugin in your template and pnForms takes care of the rest. You will just have to ask the render whether the page is valid or not.

pnForms simplifies database driven data: you supply the database field name to the plugins (defaults to their ID), assigns data to the render's template variables, and then pnForms take care of the rest. If you also use PostNuke's database utilities (DBUtill) then there's very little work left to do for you.

Please read the rest of the article for a complete example.

Current state

All of the above is working now and mostly documented in both code and in the Wiki. So grab the current SVN snapshot of PostNuke .8 and start playing around with pnForms. Look in the Wiki docs for an introduction and pointers to complete code examples.

If you want to try out the user side then look at turmappen.dk which is 100% PostNuke .8 and pnForms based. You can also look into Frank's Multihook module (SVN version only) for ideas - it should already be converted to pnForms (so I was told at least).

If you have questions then please post them in the forums, but since I don't read these regularily I suggest you send a short notice to me at jw-at-fjeldgruppen-dot-dk.

Happy hacking to all of you guys and girls :-)

/Jørn (www.elfisk.dk)