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.
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.
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!
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.
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.
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
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 add component (Renderer) caching and page (Theme) caching into the mix things become complex. This is another thing that needs reviewing.