PostNuke

Site search

Search results

Number of hits: 73

The End   (Content)

2001.  After several years of development the PostNuke came to an official end in 2008.  The software was always meant to be the stepping stone to better things, namely the "Adam Baum" project which was originally based on a PostNuke version but soon forked in a totally different direction under development for a few years.  
The fruits of the Adam Baum prokect were released as a new product called Zikula. Efforts have been made to make a migration path to the new product although not all modules and extension are compatible and the migration process can be rather difficult.  For details about the migration package, please see the migration release.
Zikula should not be confused with PostNuke since they are spearate products and the underlying code is vastly different. A decision was made to provide security updates for PostNuke until 1st July 2009 and there will be no more releases of PostNuke beyond version 0.764.  If security issues are found it is suggested you discontinue use of PostNuke and migrate.  If you require professional support doing this you may contact us.
The End.

Generated on February 1, 2009.

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.

Rebranding of PostNuke... thoughts and considerations!   (News)

place) will be to explain people outside the active community what is happening, why and what consequences the rebranding will have.
Thats not just a task for PostNuke.com (sorry I don't know the new name ;)
The whole community, from main community site to the most "insignificant" PostNuke support site has to take part in this massive campaign to promote the new name and to explain.
Thats a big coordination task but thats not all... the PostNuke users you don't necessarily reach with this work is our customers!
Those of us that has made PostNuke not just a way of life but also a way of living has to explain to paying customers why the CMS they have been told was the worlds best and most steady product suddenly has to be renamed.
You could shrug off this and assert that "you have earned the money... you do the work and keep on smiling"... thats partly right... personaly I have never been payed for the system or any public available modules or such only the time I invested in the projects.
Last but not least we have to reach the people that are not aware of "renamedpostnuke".
Today you have to be creative when searching for a CMS on google and NOT hitting a PostNuke site within the first 2 resulting pages.

What the above lines boil down to is... have you got a plan for this?

I certainly understand why there is so much secrecy about the new name because it's a worldwide rebranding but again I ask you to consider the fact that there are a lot of community- and support sites out there that might feel slighted or disregarded.
We (the local community sites) have put a considerable amount of work and effort into promoting and supporting PostNuke and would ofcourse want to be able to do the same for "renamedpostnuke".

If we are not able to aquire "renamedpostnuke"-dot-"countrycode" for the major community sites in the various countries then please give us the opportunity to claim a variety of the name (maybe in advance) or "certify" us or whatever.
Maybe you schould have a little more faith in us and see us as "partners" in stead of "competitors"... well maybe I'm out of line here but that's how I sometimes feel ;)

You could claim that you have considered this and will make subdomain's for the various contries but that might not be the best way to do things. Although I would like to see a closer relationship between the main community site and the local community sites we still have to be just that... "local".

As stated above this is not criticism just some personal thoughts I have had for some time now and thought schould get out in the open.
If you will take them into consideration or not is up to you... maybe they already have been and I just didn't grasp it ;)

Anyhow I think there has been too little "public" info regarding the rebranding and your thoughts and considerations.
Right now I even don't care about the new name (...who am I kidding...OFCOURSE I DO...can hardly wait ;) and maybe I'm the only person who questions the steps involved...?

With the best of intentions the deepest respect for your work and 100% loyal PostNuke community- supporter and admin
Kim Enemark
Administrator at PostNuke.dk

PS: Try to google "postnuke" ;)
Danish search (top of page 1)
English search (top of page 3)

Generated on November 19, 2007.

pnMeeting 2007: Axel Guckelsberger on EasyDist, EasyInstaller & the ModuleStudio   (News)

modules, theme and languages. Just as you need it. EasyDist will then give you a download archive with all parts in the right folders.

EasyInstaller is a window program that helps the newbie to install the previously acquired package. You simply have to type in FTP and Database credentials and if will upload and install Postnuke automatically. EasyInstall is written in C# and Axel is looking for someone to take over the job of finalizing the work on EasyInstaller.

The major project is the ModuleStudio. I can't really summarize the whereabouts of this system. But Axel assured me that it helps module developers to point & click a new module within few hours and it won't be possible anymore to write incompliant functions anymore. Every module generated with his system must be as secure as the rest of Postnuke and can only contain errors that are errors of the generator and if you correct that error in the ModuleStudio you can update every module in the same step. The programmer himself can't introduce coding errors.

During the presentation Axel showed a live demo of the visual editor which turned out to be pretty impressing. The ModuleStudio will be released open source but maybe there will be restrictions and different licenses for commerical or non open source projects.

Further information about these projects can be found at modulestudio.de

Generated on September 8, 2007.

pnMeeting 2007: Albert Perez Monfort introduces the "Intraweb" project   (News)

their school websites. The Department of Education offers a Postnuke sites to every school in Catalonia and some 500 of them use it.

Besides Postnuke Moodle and MyScrapBook are in use for the project. MyScrapBook is an easy content solution that the schools use to produce book-style web sites.

As a first step the projects main site has been migrated from Joomla to Postnuke - a point that was criticized last year ;-) But more importantly during the last year 450 teacher were trained in the use of PostNuke. Theses courses are repeated this year with another 400 teachers.

Albert Monfort and his collegues for their project integrated Postnuke with the eLearning system Moodle very comfortably. Moreover they imporved some of the old core modules so that they can handle massive numbers of users. For their special requirements Albert Monfort and his collegues programmed several modules. For example "Agendas" handles Agendas for single users or groups of users. Teachers can even handle presence lists with Postnuke. All modules are available via their homepage only most of they are currently Catalan only.

They even build up an internal FAQ system for common problems with Postnuke. It's in Catalan - so if you are able to speak Catalan feel free to translate it for the wiki. ;-)

For the future the Catalanian Deparment of Educations plans to at once move to .8 and run it only with one installation. That will reduce the maintainance work and the risk of problems with hundereds of installations.

The project "Intraweb" can be found at http://phobos.xtec.cat/intraweb/web/

Generated on September 8, 2007.

pnMeeting 2007: Mark West: Porting an Open Source Template to Postnuke .8   (News)

There are several sites that offer open source web-templates - you can take them and build your own site on them.

You choose one of their templates and turn them into a theme in 20-30 minutes with some experience. So if you watch the recorded presentation you will be able to follow Mark explanations step by step. We will put them online within the next few days.

Additionally there is already a lot of information in the development wiki.

In Mark's presentation you will also learn about the need to still provide table style sheets and how to correctly implement them.

Also a theme isn't only the template for the general layout - with for example the RSS theme you can generate RSS from every templated module. Of course it is also possible to generate other kinds of XML or other ways of displaying content.

One major advantage of the new theme engine is the possibility to completely port a theme with all settings from a sandbox site to the live site as all variables are stored in Smarty compatible .ini files.

We hope that this presentation sparks a new wave of themes and inspires new people to design their own layouts as these steps do not only apply to open Source web templates but also for your own designs created in Dreamweaver, NVU and so on. Mark already converted more than 100 free web templates that are available for .8 in the NOC or on Mark West's homepage.

BTW: Some more photos

Generated on September 8, 2007.

Did you know: The Power of Workflows   (News)

relative order is, how they are synchronized, how information flows to support the tasks and how tasks are being tracked." -- Wikipedia

So workflows offer the possiblity to make the usage of modules more flexible. For example you could apply the submit/approve scheme to every module. Or you could add another step: User submits, lector corrects, editor approves

But workflows don't only organize the cooperation of user groups in a publishing process. They can also start automatic functions like sending a mail when a new user submits an article. Or it could also add the new article as a new thread into a forum.

Axel Guckelsberger experimented with the workflow system that is already included in Pagesetter. In his tutorial "Managing pnCommerce with Pagesetter" he describes how a item in Pagesetter is paralelly added/edited/deleted in pnCommerce. This makes it possible to manage the products with pagesetter and only use pnCommerce cart and order functions.

Another nice example of how to add a brand new feature to a module by only putting some XML into a workflow file is Markus Gossmer's "save as feature for Pagesetter. With this you can edit an existing item, edit it and save it as a new publication. Which is very useful if you e.g. have to add several similar events to a calendar.

There is already some documentation on the .8 workflow system in the Wiki whereas the according API Docs are still a bit rough.

Links:
Managing pnCommerce with Pagesetter
"save as" for Pagesetter
Workflow System
Workflow API doc

Generated on March 17, 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.

What will Postnuke .8 be?   (News)

On the way from Postnuke 0.1 to Postnuke 1.0 the step between 0.7 and 0.8 will account to roughly 80%.
PostNuke .8 is the big step to get rid off the old PHPNuke code.
PostNuke .8 will get rid off the old content modules and make them community projects so that the core development does not have to take care of them anymore. Modules are better developed by module developers.
Postnuke .8 will contain a lot of stuff that will make module development much easier and save a lot of code. But as always in PostNuke: The APIs are an offer. You can use them, but you don't have to. And if you want to start using for example DBUtil for easier database access you don't have to use pnForms for your forms-validation.
With .8 all modules that were at least semi-compliant to .7 code guidelines should work or should work with little adjustments.
The idea is to make PostNuke a full-fledged web-application framework that can flexibly be used in various scenarios from simple static pages to complex communities.
Nevertheless there will be "distributions" of PostNuke to match the basic needs of communities, blogs, static pages aso.
So Postnuke .8 will not be .764 with more features. It's a different but compatible system.


Even though you might not really hear much from "the inside" of core development - besides the bi-weekly reports - You can be

Generated on February 23, 2007.

New web forms framework (PN .8)   (News)

have fields for the title, the content, and an expiration date, and the title is mandatory, so the user *must* write something.

To do this you must go through the following steps:

1. Read the posted values one by one.
2. Verify that the title contains text (validation).
3. Verify that the date is really a date (validation).
4. Generate an error message if validation fails (error handling).
5. Regenerate the input form, but this time include the previous user input (state management)
6. Possibly convert the date to a format readable by the database (database access).
7. Transfer posted values to database.

All of these things must be done for each web form you create. This is very tedious and error prone work, which is why pnForms was introduced to PostNuke: pnForms address all of the 1-6 issues above, and with the use of PostNuke's DBUtil API you can start creating web applications with much much less programming than ever before in PostNuke.

Features
(excerpt from wiki docs):

First of all - pnForms is a clean extension to pnRender! You can do all the stuff you are used to, but you can also make life easier with the extensions.

pnForms is event driven - you supply an object (the page event handler) to the pnForms framework which will in turn call different methods on this object when interesting things happen, like for instance the click on a button.

pnForms builds on Smarty's plugin system and allows you to extend the framework with new plugins (like for instance a GPS input field for your next project). Plugins are heavy on object oriented programming which means you can reuse and extend existing plugins by simple OO-inheritance.

Plugins are also event driven like the page event handler, so your plugin will get notified when certain reactions are required such as rendering the plugin or reading data posted from the web form.

pnForms manages state for you - all variables in your page handler object is persisted accross different calls to the browser. So if you save an article ID in the event object during the first page rendering, well, then it's still available after the next postback of data from the form.

pnForms handles input validation - you just insert a plugin in your template and pnForms takes care of the rest. You will just have to ask the render whether the page is valid or not.

pnForms simplifies database driven data: you supply the database field name to the plugins (defaults to their ID), assigns data to the render's template variables, and then pnForms take care of the rest. If you also use PostNuke's database utilities (DBUtill) then there's very little work left to do for you.

Please read the rest of the article for a complete example.

Current state
All of the above is working now and mostly documented in both code and in the Wiki. So grab the current SVN snapshot of PostNuke .8 and start playing around with pnForms. Look in the Wiki docs for an introduction and pointers to complete code examples.

If you want to try out the user side then look at turmappen.dk which is 100% PostNuke .8 and pnForms based. You can also look into Frank's Multihook module (SVN version only) for ideas - it should already be converted to pnForms (so I was told at least).

If you have questions then please post them in the forums, but since I don't read these regularily I suggest you send a short notice to me at jw-at-fjeldgruppen-dot-dk.

Happy hacking to all of you guys and girls :-)

/Jørn (www.elfisk.dk

Generated on January 21, 2007.

Page 1 / 8 (1 - 10 of 73 Total)