This is the first development update issue in 2008, after almost a year absence. In this update, I will show what has been going on in the development of PostNuke since the RC3 release here, and plan to pick up the updates again. Happy reading!
In this issue:- .8 Final: the next step after RC3
- MultiCategorization
- DOM extension
- PostNuke Upgrade Distribution
- Core changes and additions in the .9 tree
- GetText and Default DB Charset
- To cache or not to cache, that's the question
.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
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 add component (Renderer) caching and page (Theme) caching into the mix things become complex. This is another thing that needs reviewing.
|
11 Comments so far
(Latest comments
)
1. espaan wrote on Mar 02, 2008 at 04:20 PM
Nice overview, thanks.The javascript stuff is neat. Want to use the Lightbox scripts for a SmugMug plugin for Content, so it's great if that works somewhat easier.
Translating the Tour module is easy to do (just a lot of work
2. Landseer wrote on Mar 03, 2008 at 12:52 PM
Teb, thanks for working on the development updates again!
There is one information missing that might be important as well: We plan to release .8 as $newname 1.0.
3. Teb wrote on Mar 03, 2008 at 02:17 PM
I saw I also forgot to mention the people responsible for each subject (for the proper creditsGuess I missed that
4. uheweb wrote on Mar 03, 2008 at 07:18 PM
Thanks for the info.Two cents:
Caching should be done on the object level - ie, when an object changes significantly, it's cached again. Until another DB change, the cache is used. Perhaps a pnObj cache mechanism.
The difficulty comes in knowing which DB updates are necessary for a cache refresh - a counter increment should not, a title change should - and how to notify any objArray caches that a member of its cache is now updated.
Doesn't joomla use an object cache? Anyone poked into their implementation of it?
NCM
5. uheweb wrote on Mar 03, 2008 at 07:20 PM
More thoughts on caching - perhaps just a cache trigger in API calls - if the cache trigger is true, pnobj calls invalidate the cache of the obj and any objarray caches that obj is in.6. mumuri wrote on Mar 03, 2008 at 11:33 PM
excuse me, but why would you like to implement such a complex system with objects (and probably something we could call states like thisas you can only use something like the AdoDB Cache system,directly on the most used queries of the CMS (the queries that are called on each page and who load mostly configuration variables), which is perhaps a simplier way to handle this.
sample use
7. Landseer wrote on Mar 04, 2008 at 08:44 AM
Main problem in caching is our extended permission system which has to be taken into account when caching a page. This gets even where worse if you start to include another modules output in your templates, eg. showing a Formicula form in a Pagesetter publication: You might have the permission to see the page, but you may not be allowed to use the contact form.Joomla does not have this granular system IIRC so they don't have the problem at all. No go and choose your poison
8. mumuri wrote on Mar 04, 2008 at 09:22 AM
perhaps he just wants to cache the object and not the full page , in this case you don't have problems with permissions no ?
9. Simon wrote on Mar 04, 2008 at 11:33 AM
PostNuke supports/will support caching at all levels - whether very high (pages), granular (module/items) or low level (database queries/objects). Each level has its advantages and disadvantages, most of which have already been discussed at length.The challenge moving forward to .9/1.0 is to create a coherent caching strategy that can work at whatever level is suitable for an administrator's site. Right now, the caching is there, but not in an ideal state - and it's on the list to be more fully developed in the future.
10. slam wrote on Mar 04, 2008 at 03:36 PM
While we work on the better multilingual features for 0.9 we should also take into account it's relation with our caching strategies. So, it's not just objects and queries, but also the new language system which must play well with caching.
Greetings,
Chris
11. kaffeeringe.de wrote on Mar 04, 2008 at 11:28 PM
good point, Chris. Dynamic pages, in several languages with several overlapping permission groups and the need to avoid concurrency problems... quite a task. Volunteers?