PostNuke

MileStone 3

The Dev Team is proud to conclude that MileStone 3 is quite near for release (check the .8 Development Cycle for details). With an enormous amount of commits from Robert, Oracle, PostGreSQL and MsSQL support are close (but not quite complete). The entire distribution should be tested for support to ensure the functionality. For this testing, there is an additional Theme plugin added for better / additional sql debug tracing output / options (function.sqldebug.php).

Patrick started finalizing the Search module, which involves every module that provides searchable data to have a pnsearchapi.php file and two templates, module_search_options.htm and module_search_results.htm. For better functionality, each searchplugin is given its own "namespace" via the array functionality of html forms. When each module is compliant to this standard, much gain can be achieved because (for example) inactive modules will not be called for a search query. Also, modules do not need to check for formdata themselves. See also Module Programming Part 4.

Drak has worked on an upgrader for 0.76x. This incomplete first version of upgrade76.php prepares the core so the usual upgrade script process can run.

Categories

The Topics module has been discussed within the theme. As most of you already know, the Categories module is much more powerfull for assigning categories (or topics) to various content on a PN site. The Topics module is an old style module, however lots of modules still rely on the presence of the module (or at least its tables), allthough the modules write directly to the code.
The Dev Team is currently looking for a way to import current Topics into the Categories so that, with an upgrade, on does not have to add these manually. It is up to module developers to support the new categories module, and not rely on the deprecated Topics module anymore. The import process of the Topics module will belong to the Categories module init.

We would like to urge all our test users (not necessarily has to be a developer) to take a look at categories, play around with it, test it, use it and come up with a list of bugs and suggestions for improvements. For feedback, one could use the 0.8-MS2 Feedback and (as always) bugs can be reported to the bug tracker.

System

Discussed in the team is the addition of config.php.dist files. In short, PostNuke is supplied with a dist file which will be read and modified by the installer, and then saved as config.php. The advantage is that config files can not be overwritten anymore when one upgrades it's PostNuke version. The disadvantage is that the webserver user (for example apache) will be the owner of the file. No decision about this issue has been taken yet, so for this time the historic way of config files is still active.

Jörg has worked on a basic check for module directory consistancy. This means, if there are duplicate module names (like system/foo and modules/foo, or even modules/FOO and modules/foo), the administrator will be noticed about this issue.

Another change is that module vars are now all serialized in the database and there is no longer any need for module developers to serialize or unserialize data before making the database calls.

The modules and system directories, and their purposes, were discussed. The system directory should only contain modules that are not allowed to be removed (the system wouldn't work without them), and the modules directory should include ValueAddons and 3rd party modules that are not a vital part to the core of the PostNuke framework. When you upgrade a module, it is left in an unactivated state, which isn't desirable to system modules. Therefore, System modules are now allowed to transition directly to active state after an upgrade.

The Error Logging functionality has been extended. If a pnRender template does not exist this will also be logged, which could be quite usefull for module developers.
The LogUtil::registerPermissionError() and LogUtil::registerAuthidError() methods are added. These method calls registerError and then logs the failed permission check and failed AuthID check respectively, so that they can be analyzed later. DB errors are now logged by DBUtil and Log Events can now be viewed in the Security Center.

Added by Frank is the option in the Users module to deactivate a user account untill the user re-accepts the terms of use. If he is logged in when deactivating the account he will be logged out during the next page load.
The returned header for a non existing user page now returns 404 in stead of 200, and the age check has been simplified and harder to get around.

Frank also enabled the addition of a generic object attribution (a very nice feature of the ObjectUtil) for the users table. Using this, one can add any datafield to the users table (as long as it is a string with max. 255 characters ;-) )
E.g. it is possible for pnForum now to store user related data this way, which makes its own user table obsolete. If you, as a module developer, need a new datafield, just add it and it is there.
Example: You have an attribute 'someattribute' with 'somevalue'. The array returned by pnUserGetVars() now contains an item '__ATTRIBUTES__' which is an associative array itself with key 'someattribute' and value 'somevalue'.
More information and code snippets can be found in the Wiki after the coding has completed.

Finally, the functions includeOnce and requireOnce were added to the Loader class, which speeds up require_once and include_once by a factor of up to 9 times.

New and updated pnRender Plugins

All pnRender plugins in the core will be renamed to lower case. The parameters used should also be lowercase. The Dev Team would recommend all module developers to do the same.
The following plugins were added or modified:

• add_additional_header plugin is replaced with the pnpageaddvar plugin.
• moduleadminlinks plugin is modified to add capability of separate title attribute, and allow links to be 'disabled'
• pndebugenvironment and pndebug plugins are extended with more info and multilingual support
• makelinks outputfilter (theme) plugin is a replacement for pn_bbclick, to create clickable links from urls

Finally, Jörn is planning to use the ExampleDB module as an example for the use of the pnForm plugins also.

ValueAddons

Some deletions have been applied to the ValueAddons directory, as follows:

• TypeTool: This editor hasn't been updated since ages, the corresponding sourceforge project seems to be inactive for a while, and the html code created by typetool is not following current standards.
  Replaced by Xinha (download)
• Autolinks and Censor
  Replaced by MultiHook (Minimum version needed is MultiHook 5.0 alpha)
• Downloads: Maintained by cmods-dev.de
• Weblinks: Maintained by cmods-dev.de
• Messages
  Replaced by pnMessages (download)
• Polls
  Replaced by AdvancedPolls (download)

Translations / Language defines

Another 'standard' that the Dev Team would like to recommend to module developers is the use of a naming scheme for translations, as it would help a lot to create more multilingual modules.
Each module should use module specific prefixes in their constant defines, e.g. _FOR_SOMETHINGISMISSING for Formicula or _PNMSG_INBOXFULL for pnMessages. This makes it easier for pnDefinemachine and can lead to more consistent translations.

This also enables us to implement an updated pnml plugin/function that offers the same kind of possibilities that the MultiHook has. All translated defines (or missing defines) get a little button that allows the admin to work on the translaton online while surfing his site. Changes will be stored directly in the pnDefinemachine tables to create the language files later on. Here the prefix enables us to attach the translation to the correct module.
Of course looking up translations in the database is a performance hog, but this should be used during development or if someone is not satisfied with an existing translation.

The current SVN packages can be more and more used as a basis for the .8 language packs: dutch and german translations have already been updated for use with .8, and can either be checked out through SVN or be downloaded as an alpha package.

.8 Stabilization: We need you!

To finalize and stabilize the last MileStone release (and to offer a first release candidate as soon as possible), we need you (the community) to test the current codebase. Install and uninstall all available modules, create users, play with hooks, create and use themes, develop modules, and so on.

Please download the latest Snapshot and install it on your test system (either a webserver, or your local Xampp installation). Wether you have IIS, Apache, MySQL, PostGreSQL or MSSql, it is interesting for all of us. Please also use the ValueAddons package and do the same. You may notice that no real new features are added to them, but this will come when the core is functional and as bug free as possible. If at all you find unreported bugs or errors, please report them in the bug tracker.

As already said: The Core Dev Team is at first interested in a working bug-free core framework and a functional upgrade path from historic distriutions. After that, new features can be added to several ValueAddons and other content modules. One could also use the current Theme module to generate Xanthia 3.0 themes. A useful help for this can be found on Drak's Theme Generator. Module Developers can find a Module Generator on the OpenStar site.

BTW, the .8 Developer Docs in the Wiki may already be very usefull, allthough the provided information is not as complete as one would wish for. Users may find lots of usefull information in the .8 User Docs.

Reminder: Please do not use .8 on any live production site! With MileStone releases or Release candidates, there is no guarantee whatsoever that the quality and security of your site and the product is assured!

Also (as read from the German Community Site) there are a few modules released in alpha status for users to test in a .8 environment:

• Formicula 2.0 alpha: Download (Bug reports)
• pnUpper 1.0 alpha: Download (Bug reports)
• pnTopList 1.0 beta: Download (Bug reports)

Severity

Critical

Impact

Directory Traversal

Vulnerabilities

Directory traversal vulnerability in error.php in PostNuke 0.763 and earlier allows remote attackers to include and execute arbitrary local files under certain circumstances via the PNSVlang session variable which is included by error.php.

Credits

Kacper

Solution

Users should immediately update to 0.764. PostNuke versions 0.764 and later are unaffected.

PostNuke 0.764 Downloads

see Release Announcement.

Andreas Krapohl [larsneo]
PostNuke CMS Development

There are no new features in this release, only a fix package for known issues with the 0.763 release.

PostNuke 0.764 Full Release Download

Download this release for new full installations.

Download (ZIP)
MD5: ad81b37751260fd3c55124e03a1ff1f8
SHA-1: d97bfaa70b5102c74469048de44be9e7e5189d7a

Download (TAR.GZ)
MD5: dd1cbfb601b855d7525f076a4f81f333
SHA-1: 93d5ddb9c388c1adb6780053dff1bf6144ee2ccc

PostNuke 0.764 Patch Files Download

Only download the patched files release if you are running a pre-existing 0.763 installation. This patch will not work with new installations or successfully patch versions earlier than 0.763. Note: due to a different SVN timestamp format this patchpacket might contain more files then expected.

Download (ZIP)
MD5: 1a17b829bafcea18ef609388b1c0e56b
SHA-1: 0244eca388ce6b11aad95d8a656d21f8bb220dbb

Download (TGZ)
MD5: 33f6c02662d26585b09df468a90d1d79
SHA-1: 7d25801a278307e9b5f307e15f60d71f6788b259

Bug Fixes

#3624, #3587, #3496, #3465.

Additionally the problems during installation in register_globals=on enviroments and problems with PHP 5.2 have been adressed.

Related Articles

PostNuke Security Advisory 2006-3

Simon Birtwistle [HammerHead]
PostNuke CMS Steering Committee

New teamlist member: Ammodump

Ammodump was asked to join the team. As quoted from his introduction in the team: "I enjoy being a community member, and that often my comments hold weight. Sometimes my comments and advice are misguided, but sometimes it is hard to understand others questions ;-) ". With two main hobbies (PN and beer), Ammodump seems to be born for the support team here at the community website.

Remote code injection problem

As some people already know, there is a remote code injection problem with the language parameter as mentioned in the Feedback Forum. Both the .7 and the .8 versions have been updated to fix this security vulnerability, so everybody is urged to upgrade their PostNuke version to the latest release (see also Release Announcement). Some background information: The FormUtil::getPassedValue() function also accepts an input vector GETPOST now. It allows to ensure that the contents of _COOKIE are not taken into account when you get data (as it would be when you go through _REQUEST). The input domain is limited to _GET and _POST and not through _REQUEST / _COOKIE anymore. This is applied firstly to the newlang and thistheme parameters, and has been (and will be) applied to the rest of the core functions additionally.

Session handling

Some features have been added to the session handling in the core system:

• Session id regeneration (random and on login/logout), making it even more difficult to hijack a session. This has been achieved without any extra writes to the database, so the feature has no overheads.
• The ability to rename the session variable (always was POSTNUKESID), and changing from session file storage to session db storage has been enhanced.
• Auth-id check to the user login screen (and block) - this has introduced a login bug which has been entered into the bug tracker and will be fixed by the release of MS3.

The session regeneration options are available in the (upgraded) Settings module.
Also fixed for both the 0.764 release as well as the 0.8 release are some PHP >= 5.2.0 issues due to session handling (See the forums, credits to fredatwork). It seems to solve the problems with PostNuke installations running on 5.2.0 or higher.

Minimum MySQL and PHP versions

The minimum version for MySQL has been raised to 4.1.x, due to some installer problems that are related to old 3.x databases. See also MySQL's lifetime philosophy at Planet MySQL. Due to security reasons, the recommended minimum php-version is at least 4.3.10.

Installer

Now fixed are some install problems with register_globals ON. In addition, there has been added a check for register_globals at the .76x install process for information only. The installation of PostNuke on these environments is nevertheless still possible. Sync with the .8 installer is to be done.

System and core modules

The internal variables statusmsg and errormsg are now arrays: it is now possible to capture (and display) multiple errors. Therefore, pnGetStatusMsg() is renamed to pnGetStatusMsgs() and LogUtil::getStatusMessagesText().
Float handling returns from Ajax has been discussed within the team. It appears that floats in the Non-US locales did not correctly set the decimal delimiters. Therefore, the locale has been set to en_US to ensure this. A solution for writing floats to the DB is still pending.
Robert has added the encryption / decryption methods, using the mcrypt library function, for use in the API.
In the Theme module, the plugins for showing the sitename, slogan and complete title have been altered to use multilanguage support.
The Settings module has some nice dynamic interface elements added to the Security and General function types, increasing useability in this one.
The magic_quotes_gpc recommendation for .8 has been changed. It should be off in stead of on. According to php security group, this feature is inconsistent in blocking attacks, and can in some cases cause data loss with uploaded files. Besides the revert of magic_quotes_gpc recommendation, the SysInfo module now also checks for allow_url_include (new in PHP 5.2) and the suhosin patch/extension.
Finally, all variables retrieved through FormUtil::getPassedValue() are now cached

ValueAddons modules

The Pages module now displays the category that each page belongs to in the overview.
The Error module (or Error handler, where error pages within PostNuke are handled) has been undergoing some changes. System errors, forbidden / not-found errors and specific API errors have their own templates and level of error reporting. A no-auth error will result in a more suitable 403 response rather than a 200-response with a status message. As a result, a lot of code has been altered to correctly use the new Log- and Error message handling.
The Wiki module has been renamed to more suitable 'Wiki_Code', as this module is a transform hook to enable Wiki formatting in content items.
The ExampleObj module has been reviewed, revised and updated by Robert. It should serve as a good example for any module writers using the new PN object model.

Bug Fixes

#2543, #2656, #2658, #2671, #2672, #2686, #2688, #2775, #2778, #2779, #2789, #2801, #2861, #2864, #2892, #2896, #2897, #2898, #2999, #3021, #3029, #3049, #3053, #3054, #3055, #3056, #3057, #3058, #3059, #3060, #3062, #3085, #3086, #3087, #3088, #3089, #3197, #3355, #3371, #3442.

Related Articles

PostNuke Security Advisory 2006-2

Simon Birtwistle [HammerHead]
PostNuke CMS Steering Committee

Severity

Less critical

Impact

Manipulation of data

Vulnerabilities

SQL Injection Vulnerability (when logged in as user with administrative privilages)

Credits

Omid (omid hackers ir)

Solution

Users should immediately update to 0.763. PostNuke versions 0.763 and later are unaffected.

PostNuke 0.763 Full Release Download

Download this release for new full installations.

Download (ZIP)
MD5: 13221d427059388d509176c2de77b2b1
SHA-1: d850f06e8632814faa6b1268cc2a787a50aa7cf3

Download (TAR.GZ)
MD5: 861fb337832cc86c2ac60ba0ed9de353
SHA-1: f4ba3e9e100229cd096ed1cd695f086dae46eccc

PostNuke 0.763 Patch Files Download

Only download the patched files release if you are running a pre-existing 0.762 installation. This patch will not work with new installations or successfully patch versions earlier than 0.762.

Download (ZIP)
MD5: e81a251b952757ec919e00589fedf0c6
SHA-1: 65d7fb1e76ce1b38f82f78de2c10543c547d3019

Download (TGZ)
MD5: bfa3f432800de453653748adc2df412e
SHA-1: a77bb37b7cc4b4e6831bdf510ade915536645a59

Simon Birtwistle [HammerHead]
PostNuke CMS Steering Committee

PostNuke and the aim regarding ValueAddons

There have been a lot of discussion about what release structure there will be in any future versions of PostNuke. Let us clarify this a bit.
As soon as the core codebase of PostNuke .8 is stable, it will be released as a core application framework, from which advanced users can create their own custom module set. Also available will be a package containing basic content modules, a simple page manager (Pages) and an News article manager.
Eventually, the aim is to build different distributions for different purposes. A good example of a (very very) extended .76x package is the current OpenStar distribution.

At this moment, there exist a few modules in the ValueAddons repository that have third party equivalents with improvements and better functionality than the historic ones. And even more important, these module developers have taken good thought about importing historic data from the original modules, so this does not mean you lose any when deciding to switch to an other module. Some examples are Downloads 2.0 to replace Downloads, MultiHook to replace AutoLinks, pnMessages to replace Messages and Advanced_Polls to replace Polls.
Maintenance of the 'old' ValueAddons modules is a lot of extra work for the core development team, which will not only delay any future releases of the core framework, but also increases the timeframe for functionality and feature improvements in these modules. So, the less there is to maintain for the core development team, the better they can work on security, stability and finetuning the core framework codebase.
We to make clear that adoption of old-style modules is encouraged! Please remember that there do not (and will not) exist 'official' ValueAddons modules. While we'd urge all third party developers to maintain high standards in their code (pnAPI compliancy, using hooks for better integration of existing functionality), this can't be enforced.

Secunia's vulnerability advisory on the core Downloads module

Secunia anounced a flaw which has status 'less critical'. The ability to exploit this flaw is limited, since it can only be exploited by administrative users: specifically, you need admin permissions to the downloads module . A new release for the 0.7x codebase is planned for next week, together with some other bug fixes. People who want to patch earlier can download modules/Downloads/admin.php from the SubVersion repository and replace their existing file.

Legal module

The German PostNuke community has hired a lawyer to update the German terms of use, because translations into foreign languages of the original legal module only work on a linguistic basis (and if at all they only apply to US-American laws). In some countries, maybe it is even better to not at all use the legals module, than to apply one that doesn't fit your country's laws. Every user should keep this in mind when using or activating this module for his / her site.

Sneak preview: Wendell's Admin theme

Wendell is currently working on a design for the PN Admin area. This is a first setup to make the administration interface much more user friendly and productive.

Code update for .8 Installation

Do you have a personal_config.php included in your installation of .8? That could be the reason for an MS2 installation problem. If you are having problems installing, try removing this file. Furthermore, lots of enhancements have been made to the installer routine. One can test it by pulling the latest nightly builds.

System Changes / Updates

In the Settings module, a link to the w3school page on each allowable HTML tag has been added to inform a user about the available tags.
The Modules module now shows a (more logical) indicator of a module's status: not initialised is red; installed but inactive is yellow; installed and good to go is green.
In the pnRender plugins, some additions and changes have been committed: The pnbutton plugin now utilises the button tag, and a suitable style for the button tag was added. On can add parameters like id, class, name and value. Furthermore, the date input validation was refactured, moving the parser into the DateUtil class. All pnForm* plugins have been reviewed and optimized by Jörn.
More information on the PostNuke Forms Framework can be found in the Wiki.

Miscellanious updates

Within the complete codebase, all occurences of extract($args) will be (or already have been) removed and replaced it with $args['myvar']. The reason for this change is that you should not use variables that are not expected within the function. We encourage module developers to not use extract also.
Error handling and Status reporting has been improved to also display module, file and line information depending on permission level. LogUtil has been updated and all occurences of statusmsg or errormsg in the codebase now use the LogUtil class (LogUtil::registerStatus() and LogUtil::registerError() respectively).

Those wanting to use categories in their modules can build off the quotes module. The quotes module supports multi-categorisation, one of the major changes from MS1, and use of the categories system has also been implemented in other core modules. We encourage third party developers to use this system for its ease of use and centralised approach, which is important to both developers and site administrators alike.

PostNuke 0.8 MS2 should also be the fastest PostNuke release yet. A further query has been removed from the sessions code, reducing page load times, and this coupled with the new theme engine and further enhancements across the core should result in favourable page load times compared with .762.

A great deal of progress and a number of important changes have been made since the release of MS1 earlier this year, so your testing is appreciated, but MS2 is still not suitable for a production environment.

As ever, please report bugs to the Bug Tracker.

From the team

Mark West has been moving house recently. Since Mark usually takes holidays just after each new release, some of the devs thought this was just a new kind of "holiday" he was taking before new releases. This is now confirmed :) but this type of holidays comes with far more debt than the other type and isn't anywhere near as much fun. However, the joy of a new home came with consequences: no proper internet connection at home... But, Mark is not the only one moving. Also Wendell, Frank and Vanessa have moved or will move in 2006.
Another milestone has been reached: On September 7, 2006 (10:25:52), Mark committed revision 20000 to the repository. A celebration and big party still needs to be organised.

PostNuke.eu

For about a month, the domain name postnuke.eu is in hands of the German PostNuke foundation. This domain and the accompanied website aims to be an informative portal with information in several languages, and links to the various communities. This a call for translations and links, you can send them to pnteam (at) pn-cms (dot) de.

Status on release(s)

Read this article now, as this one is probably moving a bit downwards on the portal page quite soon. MS2 is scheduled for release by the end of the week, and if this is announced, nobody will be interested anymore in this article... So read on now, while you can! :)

Date Format change

Discussed in the team, and committed to the repository, is a better structured way of date formatting and display. First, the date formatting in the DateUtil class was changed. Default formatting is the same as before, but it is now generated using strftime() instead of date(). Furthermore, the behaviour of the smarty modifier <!--[dateformat ...]--> has been changed: Instead of defaulting to Y-M-D format, it now defaults to the language constant _DATEBRIEF which is like "Sep 29, 2006" in english. Finally, both smarty plugins "pndate_format" (modifier) and "dateformat" (function) are now using DateUtil::formatDatetime. This makes both plugins consistent.
Module authors are encouraged to use the DateUtil functions in their modules, and the smarty plugins in their templates.

Categories, plugins and core system changes

On the categories system, the mainCat parameter has been renamed to a more common rootCat parameter. To summarize all the commits last weeks by Robert Gash and some team members, the categories integration code has been finalized for testing and the Quotes module serves as the categories example (and has been configured to allow multi-categorization). One item can belong to more than 1 category.
The footer meassage (see <a href=http://community.postnuke.com/Article2778.htm" title="Development Update, August 2006-01">DevUpdate 2006-01) is backed up to pnTemp/footermsg.htm with the MS2 release, so make sure the pnTemp directory itself has write permissions.
In the pnRender plugins, some cleaning up has been done by Axel to the pager function: it forwards also $_POST now (i.e. for search results) and other parameters from plugin call. Furthermore, all pnForm* plugins have been improved for handling inside foreach loops in templates, and pnFormImageButton and pnFormValidationSummary were added. New interfaces for render methods in the pnForm class are now part of these plugins.
The deprecated pnVarCleanFromGET, pnVarCleanFromPOST, pnVarCleanFromREQUEST, pnVarCleanFromCOOKIE and pnVarCleanFromFILES are removed from the codebase. This means for a module to be .8 compatible, functions should now use FormUtil::getPassedValue (with a proper type parameter set), or the depreciated pnVarCleanFromInput, but this is less than ideal as for security issues you should not accept a variable in GET when it's expected to be delivered in POST.

Module changes

The Members_List module has been reviewed and updated. Module variables are set on initialisation and templates now use standard table classes.
In the RSS module, MagpieRSS has been transformed to a class. This is due to the fact that the function names "error" and "debug" are widely used in other projects as well and led to fatal errors.
Downloads 2.0 will replace the old please-do-not-look-at-the-code Downloads module of .7x. Lindbergh is working on full compatibility with the 0.8 codebase.
In the Theme module, there has been added interface options to page configurations, to allow user control over semantic blocks wrapper divs (modulewrapper, blockwrapper). A semantic block is nothing more then a div where the block-position, block-key and block-id are specified for further module and block output styling wih suitable css classes. See also Wiki-ThemeDesignGuidelines.

Design Team

In the past we've discussed the option of having an official 'design team' to work on the core templates and themes. The aim for this team is to enhance usability and aesthetics of the core PostNuke distribution, add further template improvements, write a dedicated admin theme and maybe write an official styleguide for module developers. This idea has been brought up again and the search for members for this team has been started.

Changing the Module names

A mechanism has been added to allow module developers to rename their modules while retaining the existing module id. Before, the modules db had to be handled manually and documentation covering how to rename the module had to be written. Or users had to backup data and then remove the old module and add the new one. In short: "Who wants to do this?"
So you can now add your old modulename to an oldnames-array in pnversion.php and the modules module will detect the relationship between the two modulenames, updating the database accordingly.
The rationale for looking at this now is that there exist a few modules that have misleading or confusing names. Also, the development team would like to encourage module developers to drop the pn prefix for modules. An exception for this are the modules that also exist as a stand alones, like pnWikka, pnMantis, PNphpBB2, ...
For renaming of tables, the a module author can raise the version number and write the appropriate "copy code" for his tables.

Icon sets

The aim of the pnicon plugin is to have multiple icon sets in the future without worrying about image filenames like when using the pnimg plugin. The pnicon loads the icon set config.php file, and selects the filename of the image by a 'type' parameter passed to the plugin.

Comment Spam

In the last couple of weeks, many posts have appeared on the community forums about spammers that login and post comments with their credentials obtained from the user registration mail. To prevent this, a check has been added for the useragent during registration at the User and NewUser module, which is an additional protection against spam-accounts by PERL agents like lwp and libwww. Of course, this is not a guarantee that these kind of registrations do not happen ever again, but it should at least help to prevent it.
Also (but still in test phase), optionally a question can be added to the registration process (comparable with the anti-spam option in formicula 1.0). This Q/A combination is freely configurable in the user administration.
For more information, discussion and Proof of Concept, please visit the forum.

System updates

The Profile module has now enhanced client-side (using prototype-driven validate.js) and server-side (to show messages on the same page) input validation.

The Extended Menu Block supports sorting via drag&drop (using scritaculous) and a utility link is also present in the menu to automatically add the current URL to the extended menu block. This is of course restricted to administrators only. It is also planned to make tree menus using this block.

The categorisation within the Admin area has been changed to a more logical sense. There now exist 7 categories:

1. 'System': Admin Panel, Mailer, Modules, Settings
2. 'Layout': Blocks, Themes, pnRender
3. 'Users': Permissions, Groups, Users, Profile
4. 'Content': Admin_Messages, Categories, legal, Search, blank
5. '3rd-party': Empty categorie for newly installed modules
6. 'Security': SecurityCenter, SysInfo
7. 'Hooks': Censor

ValueAddons updates

The Sections module has been renamed to the (more suitable and logical) Pages module. Intuitively, this module does what one might guess: serve static information on different pages.

The Top-List module is currently hardcoded to working with just the core modules, and planned is to move it to some sort of plugin architecture (using special plugin API files and call specific functions in them). This is in progress.

Miscellanious updates

We now have a html installation guide with a CSS based on http://community.postnuke.com, and an html upgrade guide is separated from it in its own document. Second, the legacy file config-old.php is removed from the repository. Furthermore, there were some problems when adding the pnTemp directory in config.php as an absolute path. This has been fixed in the current SubVersion repository, there shouldn't be any problems now. Finally, the sessions table is now smaller and session processing should be faster as one SQL query was removed per page-load. Users are now notified when their sessions have expired. This was previously done silently by the garbage collection (GC) routine which meant that a user could also remain logged in longer than necessary if this routine hadn't run. The named GC routines have been completely updated and work fine since MS1.