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.
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.
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.
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.
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:
- 'System': Admin Panel, Mailer, Modules, Settings
- 'Layout': Blocks, Themes, pnRender
- 'Users': Permissions, Groups, Users, Profile
- 'Content': Admin_Messages, Categories, legal, Search, blank
- '3rd-party': Empty categorie for newly installed modules
- 'Security': SecurityCenter, SysInfo
- 'Hooks': Censor
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.
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.