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.
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.
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! :)
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.
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.
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.