PostNuke
Flexible Content Management System
News
Meeting 2008 - Announcement and invitation
This year, the event happens on the 23th and 24th of August, in the picturesque city, Bingen[1, 2] at the gate of UNESCO world cultural heritage "Upper Middle Rhine Valley" [3]. At meeting place, I rented two conjoining rooms in my former university of applied sciences [4] n the district of Buedesheim. These are solely separated by a dividing wall, so that particular topics can also be dealt with simultaneously. For example, it is possible to allow several lectures and discussions for users and developers to take place at the same time. A workshop is in consideration as well, to diversify the agenda.
At this time we are still at the beginning of planning, but will delve into it during the next weeks and give an account of it in regular intervals. We have several ideas, especially due to the large feedback from last year. For instance, we are up to start a shuttle service as designated by multiple people. There will certainly be a supporting programme again - how this will look like and if proportionate costs, in form of a fixed amount, which has to be carried by the participants themselves, will incur thereby is still open though. But we will make an effort to keep this amount as low as possible (less than 25 Euro). It is also not certain yet where and in which form the traditional prelude event on Friday will be.
Since there were already three companions last year, we want to organize a secondary agenda which is going to happen parallel with the primary conference and is being overseen by my girlfriend. However, during the complete supporting programme, for example the dinner on Saturday, both groups will be together.
Many other details like possibilities for arrival as well as accommodations and the program itinerary will be recorded in the Wiki [5] (German only). Also preliminary suggestions for lectures, workshops and discussions can be handled there. In coincidence of The Rhineland Palatinate's State Garden Show [6] happening simultaneously, a shortage at close hotels may arise. We will put several addresses and alternatives into the Wiki this very day. Please take care as soon as possible for corresponding reservations. If there should occur any problems, I am within reach and of help at axel@zikula.org.
We are looking forward to a large attendance [7].Registrations are without commitment, but exceedingly helpful for our organization, particularly as we must roughly estimate the total amount of persons. Also the information how many people are going to bring along their partners, is very important for the planning. The first meeting which is all about $newname is hopefully going to become an exciting and innovative performance with active participation.
Links:
pHACCP RC1 released
PostNuke to Participate in Google Summer of Code 2008
If you're currently a student, please consider enrolling in the GSoC this year and contributing to PostNuke. We look forward to receiving your project proposals and mentoring as many students as possible.
Simon Birtwistle
[HammerHead]
PostNuke Steering Committee
P.S. For those interested, our mentors for this year are Mark West, Robert Gasch, Frank Schummertz, Axel Guckelsberger, Simon Birtwistle and Steffen Voss.
MediaAttach RC 1 released
Functional features
- With the display and delete hooks file uploads become possible in all hook-capable modules.
- Many different file types are supported (images, music, videos, archives, documents, ...)
- The most formats can be displayed embedded.
- Enhanced file information like for example ID3 tags are read and cached with pnRender.
- Also emedding external videos (e.g. YouTube, Google or Dailymotion) is possible.
- Users can send files to themselves in mails.
Security
- Files can be stored outside the web root, which is advisable absolutely.
- If this is not possible, a .htaccess file can be created automatically for protecting direct access.
- Therefore all access is handled by module functions and permissions.
- A quota support cares for bounded storage limits.
Integration
- Users can manage their own files in the profile.
- With a Scribite plugin for Xinha media can be inserted in the editor easily.
- A support for needles in the MultiHook also provides possibilities to include files in other content.
- A Guppy plugin for Pagesetter is enclosed as well to be able to define MediaAttach fields.
- Also the Content module is being supported by a flexible plugin.
- More profound integration possibilities for special modules exist with create and update hooks.
Migration
- An import from the file system is possible.
- Moreover import options for Downloads 2, Mediashare, PhotoGallery and pnUpper are ready.
Comfort
- Direct support for Categories.
- Images can be scaled down.
- Space-saving multi uploader if JavaScript is available.
- Thumbnails can be cut out individually if desired.
- The new search functionality is being supported.
- The creation of bit torrents for files is possible.
- Comprehensive PDF manual.
MediaAttach can be used as easy as every other display hook module (for example EZComments). But if one engages in it, he quickly perceives that the strengths of this module are it's flexibility and it's adaptability. It not only unifies file management and media integration, but can also be used as a gallery for example. Different annexed template sets illustrate several possible applications.
Also interesting is that one can activate MediaAttach also for MediaAttach itself which leads amongst others to the possibility to attach media to other media items.
The module offers concluding dozens possibilities which can all be used, but may not. For this reason it is excellently suited for being employed in project-specific areas and is furthermore in line with our framework idea why it is going to constitute an enrichment certainly.
Links
Have fun with testing and giving feedback :)
Development Update, 2008-01
.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.
Test PostNuke 0.8 and Intraweb 2.0
There is no excuse not to test the new PostNuke 0.8 or $newname 1.0, you need only to create a new account and begin with your tests.
Going OpenID
(if you already know OpenID then jump directly to the last section about OpenID in PostNuke)
OpenID - a Free, Decentralized Online Identity
OpenID is a relatively new web-technology for managing your online identity. It's primary purpose is to facilitate Single Sign On across independent websites. This means you can create yourself an OpenID identity and use that for login in to different websites without having to retype your password over and over again.
Your OpenID consists of a URL, e.g., http://jornwildt.myopenid.com, and the OpenID technology makes it possible for you to prove that you own this URL. So, when you want to log in to a website supporting OpenID, you type this URL and then the website takes care of the rest (almost). EnThinnai Blog compares OpenIDs to credit cards: credit cards are issued by someone, it proves your identity at the issuer, you can have as many cards as you want, and in OpenID's case you can even use them to get access to places.
You can also use your OpenID to sign a weblog comment without the need to register as a user on that website. No one else can do that with your URL so your comments cannot be spoofed by anyone.
Take a look at these demos of how it works in some applications:
On Simon Willison's website you can also see some good examples of what OpenID can be used for.
One very interesting thing is that OpenID has just been adopted by Yahoo! So now each and every one of the 250 million Yahoo! users have their own OpenID identity. Even Google, IBM, Microsoft, and VeriSign have signed up to support the new technology. With that kind of backing OpenID is no more a kids toy.
OpenID is of course not the perfect solution for everything (see for instance idcorner.org) but I would say it is close to perfect for Single Sign On and signing comments in the web/PostNuke world I live in.
If you want to start using your own OpenID then get one at myopenid.com - it's free and it's all you need.
OpenID in a PostNuke world
PostNuke should of course also have such a thing as OpenID for Single Sign On, user registration, signing comments and so on. So a new OpenID module for Single Sign On and user registration is on it's way (expected release in March or April). Have fun with it.
An OpenID implementation with PostNuke should also enable you to use your PostNuke installation as an Identity Provider, meaning that your OpenID could be YourName.YourSite.com. Hopefully the OpenID module will support this.
Other uses for OpenID in PostNuke could be to sign comments using the ezComments module or pre-allow access to certain Mediashare photo albums through your friends OpenIDs. Only the sky is the limit and OpenID is free for you to use and invent with.
Regards, Jørn Wildt
Url rewriting on Postnuke 0.8
Main principles of the mod rewrite
For information, the URL rewriting is a module that you can activated in your apache to rewrite the links of a site in order to simplify their reading. The idea is that the Pn Team also thought that the mod rewrite was not necessarily available / activated on all types of servers (particularly on Windows servers). Indeed, the Postnuke team offers rewritings based on tips already heavily used in management systems like blogs. Before you begin, here is the format of a link without rewriting.
<fieldset> <legend>without rewriting</legend> index.php?module=Users&func=logout Index.php? Users & module = func = logout </fieldset>URL rewriting without mod rewrite
This rewriting reproduced a "virtual" Folders system on your site, links look like this <fieldset> <legend>URL rewriting without mod rewrite</legend> index.php/Users/logout </fieldset>In terms of mechanism, it is very simple, when your Web server receives a request for a link, it loads instinctively page "index.php". In this index.php, the parameters of the request are recovered via the header (you can look in "phpInfo" there is a field $ _SERVER [ 'REQUEST_URI'] which corresponds to this information).Then these parameters are interpreted , between the first two "/" is the name of the module, between the two others, the function name. Now Postnuke know the name of the module and function to launch.
You can pass parameters too, for instance, if you want to load a forum with id=2, the links will look like this
<fieldset> <legend>URL rewriting without mod rewrite</legend> index.php/Forum/viewforum/forum:2 </fieldset>Note that the url rewriting uses ":" to represent the parameters in a url. So you can't pass variables like this "index.php?variable=filter:3". (be carefull if you are using Pagesetter and his filters system).
URL rewriting with mod rewrite
Optimizing the previous version
In the previous example, all links contained index.php ... but it's ugly, and functionally this file contains no information useful to load the asked module.This trick is useful when you have no mod rewrite, but if one has an "mod rewrite enabled" server,you can use a "lighter" version of the previous rewriting without an "index.php"
Here is an example
<fieldset> <legend>URL rewriting with mod rewrite :Optimizing the previous version</legend> /Users/logout </fieldset>Be careful, if one of your pictures is written this way <img src="test.png"> and you load the page /MyModule/main/. "/MyModule/main/test.png" which will be searched. Note that you can make a rewriting that redirect all links of the form "/*/*/*.(jpg | png | gif)" to "$ 3. (Jpg | png | gif)." (but it's ugly).
Mode file
This url rewriting is the classical version already used in previous versions of the cms, The rewrited links are lists of words (module name, the name of function) separated by dashes. Note that this version uses a large number of regular expressions rules to do the rewriting compared to the other one, which may increase the load of your server Web.
One example here ...
<fieldset><legend>URL rewriting with mod rewrite : Mode file</legend> module-Forum-viewtopic-topic-2903-start-0.html </fieldset>Note that the "module" which one would have thought there's no point in it, is made for the support of the "old style" loading of modules.
URL rewriting customized
So here is the coolest feature, which allows you to customize the URL rewriting depending on the module you want to load. Just create a "encodeurl" function in your API module (pnuserapi) that takes as parameters, the information needed to create for output a fully customized rewrited link.
After, the loading of each page of the CMS, a "decodeurl" function in the API part of the module takes care to reformat the encoded url in a form understandable by the CMS.
You can find an example of the use of this method in the module "Pages" of values addons
<fieldset><legend>Format of a encode and decode url</legend> function pages_userapi_encodeurl($args) function pages_userapi_decodeurl($args) </fieldset>This feature is interesting because it allows us to have the hands on your url, not only before loading the page, but after loading this page, allowing you post-processing actions rather interessant.
This method allow you to
- - put keywords in the url: (see Pages module)
- - have a single version of your rewrited url : Indeed, through the post treatment you can recalculate the url and it does not conform to your requirements, you can redirect to the good link via a redirect 301 "Moved Permanently headers.
Use case of a url rewriting "no duplicate"
Page 2 / 277 (11 - 20 of 2763 Total)
