PostNuke: A Flexible Open Source Content Management System
home | forum | international support | contact us

News

development This is the the fourth update issue, with the aim to communicate the development of PostNuke to the community. Not too technical, not too detailed, but to show what the recent discussions and repository commits are about. In this issue:

PostNuke and the aim regarding ValueAddons

There have been a lot of discussion about what release structure there will be in any future versions of PostNuke. Let us clarify this a bit.
As soon as the core codebase of PostNuke .8 is stable, it will be released as a core application framework, from which advanced users can create their own custom module set. Also available will be a package containing basic content modules, a simple page manager (Pages) and an News article manager.
Eventually, the aim is to build different distributions for different purposes. A good example of a (very very) extended .76x package is the current Openstar distribution.

At this moment, there exist a few modules in the ValueAddons repository that have third party equivalents with improvements and better functionality than the historic ones. And even more important, these module developers have taken good thought about importing historic data from the original modules, so this does not mean you lose any when deciding to switch to an other module. Some examples are Downloads 2.0 to replace Downloads, MultiHook to replace AutoLinks, pnMessages to replace Messages and Advanced_Polls to replace Polls.
Maintenance of the 'old' ValueAddons modules is a lot of extra work for the core development team, which will not only delay any future releases of the core framework, but also increases the timeframe for functionality and feature improvements in these modules. So, the less there is to maintain for the core development team, the better they can work on security, stability and finetuning the core framework codebase.
We to make clear that adoption of old-style modules is encouraged! Please remember that there do not (and will not) exist 'official' ValueAddons modules. While we'd urge all third party developers to maintain high standards in their code (pnAPI compliancy, using hooks for better integration of existing functionality), this can't be enforced.

Secunia's vulnerability advisory on the core Downloads module

Secunia anounced a flaw which has status 'less critical'. The ability to exploit this flaw is limited, since it can only be exploited by administrative users: specifically, you need admin permissions to the downloads module . A new release for the 0.7x codebase is planned for next week, together with some other bug fixes. People who want to patch earlier can download modules/Downloads/admin.php from the SubVersion repository and replace their existing file.

Legal module

The German PostNuke community has hired a lawyer to update the German terms of use, because translations into foreign languages of the original legal module only work on a linguistic basis (and if at all they only apply to US-American laws). In some countries, maybe it is even better to not at all use the legals module, than to apply one that doesn't fit your country's laws. Every user should keep this in mind when using or activating this module for his / her site.

Sneak preview: Wendell's Admin theme

Admin theme by Wendell (DynaWerx)

Wendell is currently working on a design for the PN Admin area. This is a first setup to make the administration interface much more user friendly and productive.

Code update for .8 Installation

Do you have a personal_config.php included in your installation of .8? That could be the reason for an MS2 installation problem. If you are having problems installing, try removing this file. Furthermore, lots of enhancements have been made to the installer routine. One can test it by pulling the latest nightly builds.

System Changes / Updates

In the Settings module, a link to the w3school page on each allowable HTML tag has been added to inform a user about the available tags.
The Modules module now shows a (more logical) indicator of a module's status: not initialised is red; installed but inactive is yellow; installed and good to go is green.
In the pnRender plugins, some additions and changes have been committed: The pnbutton plugin now utilises the button tag, and a suitable style for the button tag was added. On can add parameters like id, class, name and value. Furthermore, the date input validation was refactured, moving the parser into the DateUtil class. All pnForm* plugins have been reviewed and optimized by Jörn.
More information on the PostNuke Forms Framework can be found in the Wiki.

Miscellanious updates

Within the complete codebase, all occurences of extract($args) will be (or already have been) removed and replaced it with $args['myvar']. The reason for this change is that you should not use variables that are not expected within the function. We encourage module developers to not use extract also.
Error handling and Status reporting has been improved to also display module, file and line information depending on permission level. LogUtil has been updated and all occurences of statusmsg or errormsg in the codebase now use the LogUtil class (LogUtil::registerStatus() and LogUtil::registerError() respectively).

 
Posted by Teb  on Monday, October 09, 2006 Comments (10) · 2790 Reads

10 Comments so far

(Latest comments )

MACscr's Avatar

1. MACscr wrote on Oct 09, 2006 at 08:41 PM

thanks for the great article. Alot of good information and insights.

I do want to comment on the ability for PN to enforce pnapi compliancy and pnrendered modules included as ValueAddons. You said you cant enforce this, but cant you do this by not officially distributing these "distro" packs with modules that are not pnAPI compliant and pnRendered? Im not saying people cant download these modules/blocks/plugins. They just wont be officially ditrubuted as a package with PN from postnuke.com. I guess its not really a big deal as i can of course just use what i want, but just hoping it would put a little added pressure on a dev to code to standards if he/she wants PN to help destribute his/her scripts.

Also, ditto's to Wendell on his admin theme. Very nice. Glad its finally getting done. Im actually working on one of my own as well to mimic the admin style of Wordpress. We will see where it goes though. =P
patrick.c's Avatar

2. patrick.c wrote on Oct 09, 2006 at 11:14 PM

I am pretty sure that we will talk a lot about every module that we use in these distro packs and I don't think that non-API compliant modules have a good chance to be included.
Simon's Avatar

3. Simon wrote on Oct 10, 2006 at 10:20 AM

Any package distributed from postnuke.com will attempt to showcase PN in its best light. As a result, we generally won't be including modules that aren't API compliant or pnRendered, though there may be exceptions. As time goes on, there are less and less modules that are not at least API compliant and those that aren't are not generally mainstream.
Landseer's Avatar

4. Landseer wrote on Oct 10, 2006 at 12:51 PM

The only possible exception I can think about is Pagesetter, which is not fully pnrendered.

All valueaddons modules are uptodate or, as mentioned in the article, will be replaced by other modules which are also API-compliant + pnrendered.
PeteKennedy's Avatar

5. PeteKennedy wrote on Oct 10, 2006 at 08:57 PM

I agree with Landseer.

new_to_this's Avatar

6. new_to_this wrote on Oct 11, 2006 at 02:13 AM

Oh, .8 please..... icon_smile

mikelawson's Avatar

7. mikelawson wrote on Oct 11, 2006 at 03:36 AM

Wendall, nice admin page! Who da man? YOU DA MAN!

tycho's Avatar

8. tycho wrote on Oct 11, 2006 at 08:44 AM

Nice article icon_smile

QuotePlease remember that there do not (and will not) exist 'official' ValueAddons modules.


Are you sure? From the new downloads module : $modversion['official'] = 1;
icon_lol icon_lol icon_lol
Teb's Avatar

9. Teb wrote on Oct 11, 2006 at 10:45 AM

Let me rephrase that:
QuotePlease remember that the Core Development Team will never mark a 3rd party module as an official ValueAddon for the PostNuke Framework. Reccomendations for use of a module are solely based on personal preferences.

Of course, if a module developer marks his own module as official, then what can other people do about that?
alarconcepts's Avatar

10. alarconcepts wrote on Oct 15, 2006 at 04:21 PM

Nice work guys...

QuoteOf course, if a module developer marks his own module as official, then what can other people do about that?
The variable could probably be deprecated and removed.

Main Menu

Extensions Database

Documentation

Development

Login





 


 Log in Problems?
 New User? Sign Up!

Donate to PostNuke