PostNuke

Site search

Search results

Number of hits: 35

Development Update, 2008-01   (News)

.8 Final: the next step after RC3
Since the release of RC3, already a lot of bugfixes have been committed to the repository. The developers have agreed to address all new features to the .9 tree, where the two major changes (UTF-8 and gettext, see below) are already in active development. This should result in much shorter release cycles (and earlier release dates) also, and give module developers much more clarification on what to change in order to make their module work under the new major release. If needed, an final bugfizing weekend may still be organised for .8 final.
The upgrade from .764 installations on certain systems has been improved, by increasing the memory_limit to 64M. However, this only works for php version 5.2.1 and above.
Upgrading to .8 together with some 3rd party modules may raise problems when the modules upgrade process is not failsafe for .8 or if the upgrade function uses core functions of modules that are not available yet. Therefore the upgrade of 3rd party modules in general is avoided by following a white list of core modules.
Most site-specific data can already be easily overridden using the /config and /themes directories. The Multisites module however still needs some futher thought on the best way of running multiple sites from a single install. One method having multiple unrelated (i.e. non table sharing) sites of a single install would be to have config/site1, config/site2 etc., this will be postponed to a next release.
The Tour module is now in a state where it can be translated to other languages as well. Just translate the templates and put them in a subdir with the appropriate language abbrevation, all within the pntemplates directory.

MultiCategorization introduction and issues since
As earlier announced, a last fix for supporting MultiCategorization has been added to the core just before the release of RC3. Since those changes, another small fix was then required to be fully backwards compatible. On the module-devs list, the devs have discussed a lot on how to solve these issues. Chances are great that if the new (already committed) patches do not solve the problems, MultiCategorization might be postponed to later versions in order to fully test the new features.
For more information on MultiCategorization, visit this thread in the forum.

DOM extension to use correct paths in JavaScript
Some javascripts, eg. the lightbox, need to know the path to the system and the entrypoint as well (which can be configured in the settings), otherwise they may fail in case of short urls being enabled. Since dynamic javascript creation might be a performance problem, some inline javascript is added to the pagevars to extend the DOM:
- document.location.entrypoint: will be set to what is configured to be the entrypoint
- document.location.pnbaseURL: will point to the result of pnGetBaseURL();
Any ideas on how to make his more unobtrusive are very welcome!

PostNuke Upgrade Distribution
In previous articles and posts, the term '.8 upgrade pack' was used to represent a full .8 package, including 3rd party modules, to upgrade to .8 from an existing .764 installation. However, the term 'upgrade pack' is not quite correct and misleading, because it implies to be an upgrade package with changed files only, while the main parts remain as-is. The transition between .764 and .8 requires a complete exchange of all files, so the so called upgrade package is a complete distribution.
Now it remains what modules should be in an upgrade distribution, to be able to fully upgrade an existing .764 installation, including new versions of 3rd party modules. These include Downloads 2.2, pnMessages, Polls 2.0, bbcode / bbsmile, Weblinks, EZComments and MultiHook at least. This might need some additional testing with certain versions also.

Core changes and additions in the .9 tree
Mark has already overhauled some core API methods and calls. All systems modules are now using the Renderer Class instead of pnRender. Also, a first pass has been committed in changing all pn* function calls to new object method calls. For example, pnModGetInfo is replaced with ModuleUtil::getInfo and pnSecGenAuthKey is replaced with SecurityUtil::generateAuthKey.
For those who did not know: A class pnCompat.php still includes most oldstyle API calls for backwards compatibility.

GetText and Default DB Charset
Bernd is progressing rapidly on integrating gettext in de development tree, and has added po-files for all core modules. The required PHP version for .9 has already been set to a minimum of 5.1.6, and since version 5.0, MySql supports different character sets and corresponding collating orders. To run an application in UTF-8 (unicode) it is not sufficient to change the character set for PN; we needed to set the database encoding (actually server and client) to UTF-8 as well.
A user who wishes to run his site in multiple languages, needs to decide the database encoding at installation time. The default is UTF-8, because the current iso-8859-1 is restricted to too few language combinations. UTF-8 is a 'no-worry' setting because it will work with any language (as long as it is UTF-8 encoded.
This change is $PNConfig['DBInfo']['default']['dbcharset'] = 'utf-8';

To cache or not to cache, that's the question
Also discussed on the devs-list is the current (and future) state of output caching within PostNuke. Why should any application repeat the same processing tasks on a item that hasn't changed?
Not caching anything is fine if one has got infinite resources to throw at a site (and even then there are limits). But in reality there are finite resources and you need to take steps to ensure that those resources are effectively used. One method for that is not wasting precious resources repeating the same tasks time after time.
The key is effective cache management. Currently we put too much load onto the module to handle it's own caching. Once you then

Generated on March 2, 2008.

What's going on?   (News)

know the Core team released RC2 of Postnuke .8 - the Steering Committee's report we are just working on will deal with the details.

2. Jørn Wildt released a first version of his "Content" module:
"Finaly I have finished the first version of my new Content module. With this little goodie you get HTML editing, YouTube video, Google maps and more features out of the box. This module was inspired by Typo3 and the never-finished PostNuke module Publish!" -- elfisk.dk

Content is a module that you can use to create static pages. It supports several predefined layouts (1 column, 2colums + header aso) and you can also add your own templates. In the editor you then can drag and drop content items like texts, images, youTube videos or Google Maps around and place them anywhere you like within the layout.

3. Together with "Content 1.0.0" a new version of Jørn's Mediashare gallery is available. Yet it still needs an installed Topics module to run under .8.

4. pnForum 2.7(.1) is finally released. A test version served the German Postnuke community for months and now he fixed the last bugs and made a public release.

5. Sven Schomaker is about to release Scribite 2.0 - It includes openWYSIWYG v1.4.6c as new editor and new versions of Xinha (v0.94), TinyMCE (v2.1.2), FCKeditor (v2.4.3), a lot of new module plugins and languages.

6. Axel Guckelsberger finished his diploma thesis that discussed the use of model-driven software development (MDSD) for Postnuke and resulted in his "ModuleStudio". Although ModuleStudio is far from complete it is way ahead in terms of modern software development. And if it turns out right MDSD is one of the next big things after object orientation (OO).

7. User ftree started work on a new gallery (pnAlbum) some months back and now published an article about his work. In preparation of the gallery he programmed some basic functions which turned out to be suitable for everyone who wants to program a module. If you want to you can take a look at his work.

8. There's a new pnCommerce team in formation: Rüdiger Hahn, Jim Hatfield, Chris Candreva, Bernd Plagge and some others are long time pnCommerce users and all maintained their own fork of the module. Now they are trying to put all their code together and a new version out for public use.

9. Marco Kundert is still working on his .8 follow-up for Pagesetter called Pagemaster. His first release will be 100% compatible to the latest version of Pagesetter so that you can simply import all you Pagesetter content into Pagemaster. Pagesetter introduced many ideas into Postnuke that have now become part of the core: Postnuke .8 has Workflows system and the idea of Pagesetter's form framework (Guppy) can now be found as Forms API in .8 and the WYSIWYG-Editor is now in Scribite generally available - Pagemaster uses all these features and thus can be much leaner.

10. Robert Gasch is working on a commercial shop module. He allowed me to take a look at it and it looks really great. Robert made his living for the last few years by setting up shop solutions for customers and now uses this experience for his new module.

11. Mateo Tibaquirá released a first version of his port of the standalone Relay AJAX directory management application. Includes drag-n-drop files and folders, a dynamic loading file structure, thumbnail views, multiple users & accounts, batch uploads, shopping-cart/batch downloads.

I am sure I forgot some people and I know there's a lot more going on in Postnuke land. But I'd like to leave some news for further articles.

If you are working on a news-worthy Postnuke project please contact me via personal message

Generated on December 22, 2007.

3 Bugs to go: Postnuke .8 close to Release Candidate   (News)

nother. Until yesterday there was only one remaining, which Robert Gasch promised to close. But now Jørn found 2 new ones: Bugtracker

Performance
While waiting for Robert to finalize the debugging of the categories module, Jørn and Mark checked .8 for its performance and found only few major flaws which have been removed in the meantime. As far as I understood Jørn's tests a blank Postnuke .8 doesn't contain more SQL-statements as inevitably needed and though calling a load of PHP functions performs quite well.

If you are able to test Postnuke on different environments - please do so and report your findings.

Language Files
David Nelson had to take a break from overhauling the English language files. But AFAIK he picked up work again and will be done soon.

After finishing the language files and closing all remaining major bugs the team will release a first release candidate.

The Wiki needs input!
If you want to help and you are neither a coder nor a templater you can help us with the documentation! Not everything in .8 is all new - install the current nightly build of .8 and the Val

Generated on June 6, 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.

Did you know: Module Templates in the Themes Folder   (News)

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.

Generated on February 27, 2007.

Development Update, February 2007-02   (News)

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:

system/pnRender/plugins
system/Theme/plugins
config/plugins
current theme-directory/templates/modules/$module/plugins
current theme-directory/plugins
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,

Generated on February 20, 2007.

Microformats in PostNuke   (News)

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

Generated on February 3, 2007.

Development Update, December 2006-06   (News)

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)

Generated on December 18, 2006.

Development Update, November 2006-05   (News)

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

Generated on November 20, 2006.

Development Update, September 2006-03   (News)

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 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

Generated on September 28, 2006.

Page 1 / 4 (1 - 10 of 35 Total)