PostNuke

Site search

Search results

Number of hits: 40

Community News   (News)

Calendars! Calendars! Calendars!
A long time we all lived with PostCalendar - a complex and powerful modules that included Smarty before it was included as templating engine into the core. But the complexity was also the reason why the original maintainers gave up their work and nobody really picked it up again. Robert Gasch attempted to dissolve the code jungle and turned to other projects. Other modules like Zerocal, cal-zone or the pgCalendar addon for Pagesetter never really took off in the shadow of the huge PostCalendar. For a long time nothing much happened until recently several new calendar modules started to grow:

1. Daniele Conca's crpCalendar started off as a simple list of events but it is slowly turning into a full fletched Calendar with day-, week- and month-views. Moreover it supports hCalendar microformats and Content via plugin so you can integrate calendar events into your Content articles.
Download: http://noc.postnuke.com/projects/crpcalendar/

2. TimeIt is attempt to clone PostCalendar with .8 technology. In the meantime version 1.1 RC1 is released which not only offers all the features postCalendar has but also event registration and user events.
Download: http://www.assembla.com/spaces/files/cxTPX-9PKr3lxaabIlDkbG

3. Eventliner is a new Calendar which also imports PostCalendar data and offers day-, week- and month-views.
Download: http://noc.postnuke.com/projects/eventliner/

Good News for Communities
Florian Schliessl released a new, cool community module called ContacList which handles lists of friends. Your user will be able to ask other others for friendship and see their friends birthdays. The module can also be used in other modules to make user profiles aso only visible for friends. TimeIt already supports ContactList so your users can add their events or register and make this information visible to their friends.
Download: http://noc.postnuke.com/projects/contactlist/

Totally Web 2.0
Mark West released a little plugin that allows you to include these little buttons for all kinds of link services like del.icio.us, mr. wong aso. into your modules.
Download: http://noc.postnuke.com/projects/pnwebservices/

Pagesetter Successor
Marco Kundert is still working on his Pagesetter clone. The module will have all the features that Pagesetter has but replace all the stuff that Jørn first implemented in Pagesetter which now has been included into the core by the core features. Guppy will be repleaced by pnForm, the workflows will be replaces by the core workflows aso. Moreover he aims at making Pagemaster easier to use for beginners. Gabriel Freinbichler is already running a test version on one of his sites and he seems to be quite satisfied with it.

Shops
There are at least 3 forks of pnCommerce out there, maintained by Rüdiger Hahn, Jim Hatfield and others the problem now is that they all are very busy with their system and that they need to integrate all forks again to have a common code base again. There were several attempts to reunite the code but AFAIK the project lacks somebody who is really willing and able to put some time into it - who works self-motivated and needs the shop for his own sites.

Robert Gasch is working on a commercial shop. I had the priviliedge to take a look at it and it seems to offer a lot of very advanced features. If you need a shop and you are willing to invest some money into it, you should contact Robert.

Media
Axel Guckelsberger seems to have 50 hour days. His latest project is MediaAttach - finally a real solution for a central media repository. It still has some legacy from it's predecessor pnUpper but it already offers a lot of great features for the handling of media and it is included in Scribite and Content.
Download: http://noc.postnuke.com/projects/mediaattach/

Certainly there is a lot more going on - so if you are working on a project, please leave a comment.

Generated on April 21, 2008.

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.

Jørn Wildt Proposes New Content Module   (News)

For the discussion see: http://community.postnuke.com/module-Forum-viewtopic-topic-53152-start-0.htm

Here is what Jørn has in mind:

[quote=Jørn Wildt]Dear PostNuke community

One of the things that always comes up when comparing PostNuke to other Content Management Systems is its lack of real content management. All we have is some old News, Pages and FAQ (and some more) management modules - nothing really fancy. You can add fancy modules like PagEd, Pagesetter, pnWiki and others but somehow they all lack, well, something - something which I find rather difficult to pinpoint. They are either too complex, too simple, impossible to extend and do not integrate well with each other.

I have been doing some thinking about this issue and would like to present some ideas for a new Content system in PostNuke. A framework that newbies can work with right out of the box, an extensible framework, and a framework with well integrated components that are aware of each other. My ideas are by no means rocket science and most, if not all, have been implemented else where - just not in PostNuke.

If you ask me then PostNuke is going to dwindle away unless something serious is done to add a good content framework. Here is my suggestion.

[b]Content Types[/b]
The core component is the "Content Type". For those of you that knows Pagesetter this is exactly the same as Pagesetter's Publication Type. This will be a separate module that takes care of defining content types, editing and displaying content items - but without user navigation! Think of an Article, with it's title, lead-in text, main text and image, as a content item of the type "Article". The type specifies the fields that are available for a single instance of the type - a single content item - a single Article.

Content Types are management by the site administrator (but can also be created by other modules). The admin can choose from an extensible (through plugins) list of field types. Here are some examples (mostly copied from Pagesetter):

- String (one line text), Text (non-HTML), HTML (using Scribite!)
- Number, checkbox, date
- Media files (using Mediashare)
- File uploads
- URL, email
- Computer code (text displayed with line numbers in mono spaced font)
- Category (using PN .8 categories), both single and multiple select.

Now you can create an article as a title (string), lead-in (text), main text (html) - and many other types of content. But there is still no navigation - neither on the admin side nor the user side. All you have is a Content module that allows you to create content types, content items and then display these - assuming you now the URLs. Navigation is delegated to other modules - more on that later on.

The core framework does also handle input form generation: it will auto-generate input forms (using pnForms in PN .8). These can then be copied to another location and re-designed using the standard Smarty templating system.

The core content module handles a few other things: for instance revision history (who changed what and when).

[b]Content Management[/b]
So far there's nothing new compared to Pagesetter. So lets take a look at the admin side of navigation - how to store and locate your content items. I suggest that all content items are stored in a folder structure identically to your standard disk drive. On the harddisk you manage folders and store files in them. In the CMS you also manage folders - but now you store content items in them - indifferently of the content type.

The first challenge is how to handle user contributed content since normal users don't have access to the administrative folder system. Now remember that the core Content system allows anyone (with the right permissions) to add content, but where should it be stored? I suggest a standard "incoming" folder is created for this purpose (much like your mail system). The editors can then keep an eye on this folder and move new content to the right folders.

Actually there should be one "incoming" folder for each content type and it should be possible to specify which it is. In addition to this the system should have a flexible workflow system a'la Pagesetter (now already in the .8 core). So that different editors and authors and admins can be notified when new submissions arrive.

[b]Content Structure[/b]
But there's still not much difference from Pagesetter. So what's the point? Well, enter CoType - this little module, which I'm rather proud of, has some nice layout features that I would like to copy. First of all you have Boxes - elements that can be floated left/right/top/bottom relative to the current content. In CoType you have boxes for media items, program examples, and general text. I would like to extend this so that you can put any content item inside a box. So you can display and Article and put one or more Media type items in boxes as illustrations.

Another thing to copy from CoType is the use of nested content - sections in sections. This concept should be extended, just like the boxes, with the ability nest any content item inside another item. The only problem here is how nested content should be displayed? In CoType you always have sections in sections (in a document) - and there's a well defined standard way to display this. But what happens if you sudden nest a Music album inside a FAQ inside a Media item ... and then box it? Well, that will have to be solved as we go.

I suggest the Content Type configuration lets the admin specify which types of content you can nest inside another.

The system could also enable boxing of other modules contents - assuming some kind of API/interface the external modules have to implement (just like PostNuke's search API).

[b]Content Layout[/b]
The proposed layout scheme is so far rather fixed - something like this:

- Top content item title is displayed inside ... tags.
- Nested content title is displayed in ... (and so on for further nesting).
- All nested content is displayed on one page.
- A small table-of-content is displayed at the top (linking to sub-content anchors).
- Each (nested) content item is displayed with a standard auto-generated template.
- Boxes floated to the left/right are displayed in 50% width (like CoType)
- Top/bottom boxes are displayed in 100% width (like CoType)

This will allow newbies to quick and easy created new content without having to also design their own templates. Assuming of course that the system comes with a suitable default set of content items.

Experienced users can edit and change the auto-generated templates. But these will be recreated everytime the administrator changes the Content Type configuration. So experienced users must copy the templates to another location and then edit them to fit their own needs.

[b]Navigation[/b]
So far I have ignored the concept of navigation between different content items completely. This is because it can be done in so many different ways - and this is mostly where the different types of PostNuke modules distinguish themselves. A media gallery has a completely different navigation paradigme than a News list, a Wiki and a Weblink collection.

So I propose to delegate navigation to other modules. This has already been done with success with a calendar (pgcalendar) and a news archive (pgarchive) for Pagesetter. These two modules takes a specific Content Type and displays it's items a calendar view and a monthly listing view. This combination is extremely strong - you can add all the fields you want on a Calendar item - and still display it using the standard calendar view. Throw in the nested content and the boxing ability and you get an extremely flexible and yet simple Content Management System.

[b]List Navigation[/b]
The basic navigation is simple a pageable list of items ordered by some criteria. You create different lists and then refer these in the URL. For each list you configure which content type(s) to include, the default sorting order, the display template to use for each item - probably more. Including more than one content type gives some problem with respect to sorting.

This implements the typical News list on the frontpage.

[b]Catalog Navigation (collections)[/b]
This is the typical Weblink and File Up/Download navigation through a collection. The hierarchy is mirrored directly from the content folders.

[b]Calendar Navigation[/b]
Displays content items by date in a calendar (see for instance [url=http://www.fgc.dk/index.php?module=pgcalendar&tid=40]http://www.fgc.dk/index.php?module=pgcalendar&tid=40[/url]). You need to specify which date fields to use as start/end date of the entries.

[b]Archive Navigation[/b]
Displays content in lists organized by month (see for instance [url=http://www.fjeldgruppen.dk/arkiv.html]http://www.fjeldgruppen.dk/arkiv.html[/url]).

[b]Menu Navigation[/b]
On thing that frustrates me with PostNuke is the horrible way you edit menus through the Block interface. No - lets allocate a complete module for menu editing and then just select which menu to display in which box (I believe Content Express does this). With the integrated content framework you can now let the editor select content items from dropdown lists or similar - and avoid having to copy/paste raw URLs into the menu editor (this has always been a intellectual bottleneck for the people I have created websites for).

I would also like to see editing of the menu directly in the front-end. The editor should always have an "add current page to menu" icon in the menu. He should also be able to drag and drop menu items without having to jump to the admin interface.

[b]Frontpage Setup[/b]
This is just another idea of what you can do - not necessarily something to actually implement. But the frontpage need not necessarily be a list of latest items as on most portal websites. It might also be a fixed setup based on a grid where you can assign different content items to different locations. For instance Articles to the left, Banners to the right, and a few images at the bottom.


[b]Where to go now?[/b]
Now who's going to implement all this? Good question considering the speed of the core development. I would love to be on the team (and will be) but my time is restricted (especially now that I got my first kid) so I work rather slowly.

Any volunteers?

There's also the question of organizing the code - we cannot have much more than one or maybe two developers on the core Content module. But as soon as that is ready we can take more people in - one for each kind of navigational scheme. Other people can then work on the default content types.

We also need to consider how a system like this fits into the PostNuke distribution. Does it have it's own release cycle? Is it integrated with the core?

Enjoy 8-)

/Jørn[/quote]

Generated on September 4, 2007.

pnRender cheatsheet   (News)

Working with pnRender was espacially complicated: Some stuff you best read at http://smarty.php.net and you also always have to have an open pnRender plugins directory so you can open the plugins you need and look up the exact syntax.

I tried to put the basic smarty stuff and the most frequently used pnRender stuff on just one page. And the great thing is: I am willing to share it with the community.

Personally I already love the cheatsheet - It contains the syntax with the backticks! And the date specifiers!! And the parameters for pnmodurl, pnmodfunc, pnmodapifunc aso!!! And I always forget in which order truncates parameters are. That's all on that on sheet!

I hope you like it too.

Download: pnRender cheatsheet 1.0

Generated on May 28, 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.

Development Update, September 2006-03   (News)

From the team
Mark West has been moving house recently. Since Mark usually takes holidays just after each new release, some of the devs thought this was just a new kind of "holiday" he was taking before new releases. This is now confirmed :) but this type of holidays comes with far more debt than the other type and isn't anywhere near as much fun. However, the joy of a new home came with consequences: no proper internet connection at home... But, Mark is not the only one moving. Also Wendell, Frank and Vanessa have moved or will move in 2006.
Another milestone has been reached: On September 7, 2006 (10:25:52), Mark committed revision 20000 to the repository. A celebration and big party still needs to be organised.

PostNuke.eu
For about a month, the domain name postnuke.eu is in hands of the German PostNuke foundation. This domain and the accompanied website aims to be an informative portal with information in several languages, and links to the various communities. This a call for translations and links, you can send them to pnteam (at) pn-cms (dot) de.

Status on release(s)
Read this article now, as this one is probably moving a bit downwards on the portal page quite soon. MS2 is scheduled for release by the end of the week, and if this is announced, nobody will be interested anymore in this article... So read on now, while you can! :)

Date Format change
Discussed in the team, and committed to the repository, is a better structured way of date formatting and display. First, the date formatting in the DateUtil class was changed. Default formatting is the same as before, but it is now generated using strftime() instead of date(). Furthermore, the behaviour of the smarty modifier has been changed: Instead of defaulting to Y-M-D format, it now defaults to the language constant _DATEBRIEF which is like "Sep 29, 2006" in english. Finally, both smarty plugins "pndate_format" (modifier) and "dateformat" (function) are now using DateUtil::formatDatetime. This makes both plugins consistent.
Module authors are encouraged to use the DateUtil functions in their modules, and the smarty plugins in their templates.

Categories, plugins and core system changes
On the categories system, the mainCat parameter has been renamed to a more common rootCat parameter. To summarize all the commits last weeks by Robert Gash and some team members, the categories integration code has been finalized for testing and the Quotes module serves as the categories example (and has been configured to allow multi-categorization). One item can belong to more than 1 category.
The footer meassage (see

Generated on September 28, 2006.

.8 Development Summary   (News)

New Theme Module
Recently, the new theme module, which acts as a replacement for Xanthia in the .8 series was committed to CVS. This module corrects many of the established flaws in the .7x Xanthia codebase and also provides new enhancements. New in this module is the ability to assign a custom template to any page on your website, the use of .ini configuration files in themes, the removal of block control in favour of a new Blocks module and the ability for theme authors to provide a 'version.php' file in their theme to provide relevant information to site administrators.

Using .ini configuration files in the new Themes module brings two advantages over the current setup of Xanthia. Firstly, theme generation and display are much faster as no database queries are required to build the layout. This should provide a marked performance increase in .8 websites. Additionally, it is much easier for theme authors to export their themes, as in the new Theme module the details previously contained in xaninit.php in PHP code are now automatically generated by the Theme module.

Due to the sweeping changes in this new module, the user interface has been completely redesigned. While we realise this will take some getting used to, the new interface is more intuitive than previous versions and logically follows the layout of the Modules module when displaying the available themes. Additionally, all theme related settings have been moved from the Settings module to the Theme module, and the user theme switcher is now part of the Theme module display.

Themes used under the .7x Xanthia module will need upgrading to use the new .8 Themes module. This is a relatively simple process which is mostly handled by the Themes module itself, as both systems are based on Smarty the template logic is the same and there are few changes to the tags themselves. These by and large stay the same with one notable expection, block tags are replaced with the plugin call where name is the name of the block zone to display.

The recoded Blocks module has yet to be checked into CVS, however we anticipate this within the next week. Until that time, the Theme module in CVS is nearing completion and is fully functional.

New Themes / Removal of Old Themes
Two new themes designed for the new Theme engine have been added to CVS. These are free templates from Open Source Web Design, and serve as an example of what can be achieved with the new module. The new themes are tableless and HTML compliant, which along with the improvements in compliance in the rest of the codebase serve to ensure PostNuke remains one of the few content management systems to take HTML standards seriously. All output in .8 will be XHTML valid.

To this end, the old themes that have been present throughout the .7x series are no longer in CVS. While they can be easily converted to work with the new Themes module, they use table based layouts which do not conform to the standards PostNuke has set for output. A appearence overhaul is well overdue for the PostNuke codebase and so a set of new themes will be available with the .8 release.

Workflow Engine
The release of .8 will also bring a new statebased XML Workflow engine to PostNuke with simple API implementation. Additional enhancements are planned to include a workflow schedular to process workflows at timed intervals in batches.

Use of the module is simply a case of adding a directory 'pnworkflows' to your module containing a set of workflows with operations, states and actions. The workflow engine also fully supports the PostNuke permissions system. Documentation for the module will be released with the first .8 Milestone.


XML Event Based Forms
GuppyForm allows a developer to describe a form content and layout in XML with an event handler bringing automatic validation. This can drastically reduce the time taken to develop user input forms. Can be combined with pnRender templates or used standalone. For those that like OO, and descriptive coding, this is an interesting option in the framework.


Completion of Users Module and Profile Enhancements
Another recent change to CVS are updates to the Users and Profile modules. These now almost fully functional, with huge improvements to the dynamic data system now in CVS. New field types avaiable for user input are date fields, calendar 'select date' fields and combination fields where a number of seperate input types can be combined. The new users module also allows for the use of SHA-1 or MD5 password encryption, you can store the user's last login date in the database and finally the registration process has been improved to include the option to vaidate user's email addresses through an activation link. All these improvements are optional and can be enabled and disabled through the Users module administration interface.

Template Updates
As part of an overview of usability and update to the 'look and feel' of PostNuke many of the module templates have been enhanced. These range from subtle changes to much more obvious improvements in the location of links and reporting of status messages. As previously mentioned all templates validate to XHTML standards and further improvements will be made before the final release of .8.

Languages Changes and config Directory
pnDefineMachine is now the recommended tool to use for translating PostNuke into other languages. This third party module scans the whole codebase for language defines and provides an easy to use administration form for translators to write new language files. A new version of pnDefineMachine was released recently, and to facilitate its future development a number of internal define changes have been made. These should not, however affect translators themselves.

Another addition which does affect translators and site administrators is a global language file which can be edited by users and is safe from being overwritten on an upgrade. PostNuke now contains a 'config' directory where all PostNuke's configuration details are stored. The files config.php and config-old.php have been moved to this directory, and furthermore the directory can contain both global template overrides (in addition to theme-specific overrides in use in .7x) and also global language defines. While it is not currently possible to override core language defines through this change without generating a PHP Notice, you can store your own language defines for use in, for example, themes. Any changes you make here will then remain intact throughout any upgrades you may carry out.

.8 Milestone Release Date
After the Steering Committee Meeting held this Tuesday, a tentative release period for .8 Milestone 1 has been set. We currently aim to release .8 MS1 in the third or fourth weeks of April, however this may change if the codebase requires further work for the release to be of the required quality. A milestone release is an opportunity for third party module developers to test their modules with the upcoming release. It is not intended for a production environment and user support is not available for this release, however support for developers will be provided through the forums. The milestone will not be feature complete, and may not be stable.

The milestone can be taken as an indication that the codebase is beginning to get to a usable stage from which we can work towards

Generated on March 31, 2006.

The Road to .8 - Where are we, and where are we going?   (News)

The modules included in .760 which are templated, and taken direct from the .8 CVS are as follows:

Admin
Admin Messages
Autolinks
AvantGo
Blocks
Censor
Credits
Ephemerids
Groups
Header_Footer
Legal
Mailer
Members List
Messages
Modules
Permissions
pn_bbcode
pn_bbsmile
pnRender
Quotes
Ratings
RSS
Sniffer
Typetool
Xanthia

This represents a significant percentage of the .8 code, but there is still more to do. The aim of this article is to try and outline some of what remains to be done before we can consider a release of .8.

Six Main Projects for PostNuke Development
We have identified six main sub projects vital for a release of .8. These projects cover wide areas, and each are at different stages of completion. The six projects, in no particular order, are:


Integration of Open Star object library and Database Utility
Integration of Open Star category management
Installer
Xanthia
User management
Finishing of content modules

This article also includes a little information on some of the other new code to be introduced with .8 this is at the end, where we look at EZComments and the Error Handler.
Integration of Open Star Object Library and Database Utility
The new Database layer reuses the existing pntables information to provide an
object representation of database rows. The advantage of this approach is that
it allows you to basically remove manually coded SQL statements and replace
with what's typically a 1-line statement. Some sample invocations of such code
are shown below:

[code]
$myObj =& DBUtil::selectObjectByID (, $id);
$myObj =& DBUtil::selectObject (, $where);
$myObjArray =& DBUtil::selectObjectArray (, $where, $sort);
DBUtil::insertObject ($myObj, );
DBUtil::updateObject ($myObj, );
[/code]
These functions all return an associative PHP array, or in the case of array
functions, an array of arrays. The fields in this array are cleaned up in
the sense that any field prefixes have been removed. This DB API also
gives you the ability to have generate associative (object) arrays, expanded
arrays with other table fields joined in (which means that you can save SQL
lookup calls) as well as store/retrieve dynamic attributes without altering
the underlying table structure. Together this provides a highly flexible API
which can take care of all storage & retrieval operations.

On top of the DB layer sits the Object Layer. Objects provide a component model
which features transparent persistence facilities. Objects/Classees are loaded
though the Loader API though
[code]
Loader::loadClassFromModule (, 'foo') //

Generated on November 3, 2005.

PostNuke 0.760 released   (News)

Summary of Main Changes
Further cleaning of HTML

pn-normal custom class removed in favor of styling of block level element using CSS
pn-pagetitle class replaced by use of h1 tag
pn-title class replaced by use of h2 tag
all fake lists created using middot's replaced with proper lists

Simplication of non API compliant links
op=modload & file=index are the defaults so these are removed from all links
New printer (Xanthia) theme - enables printable view of any page
A printable view of any page is available using the printer theme. Append the url theme=Printer to the url or build a 'print me' button into your theme.
Removal of NS- prefix on all modules
All modules that contained the NS- prefix in the directory name have had this removed. This prefix is a result of our origins in php-nuke.
Baseline security analyzer
This new feature adds a check for some of the more basic configuration settings that can enhance the security of a PostNuke installation.
New features in core

Modules can now be referenced using an 'alias' via the module display name setting.
Default start function type, function name & parameters to the function can be defined. Note: API compliant modules only.
Standard database connection error moved to a 'template' in includes/templates.
Ability to turn the site off for maintainence (access to provided via permissions setting).
Smarty updated to v2.6.10.
ADODB updated to v4.6.5.

Modules
Admin_Messages, Modules, Blocks, Permissions, Groups, legal, Censor, Messages, Ephemerids, Quotes, Autolinks, AvantGo, Credits, Members_List, Ratings & Admin have been updated for full API compliance and templated output.
New modules

Sniffer; Detects browser and browser capabilities using phpSniff (by Roger Raymond).
RSS; Replaces dated feed handling with an xml based parser (magpie rss).

Bug fixes

Xanthia - many fixes since original release.
Mailer (added support for additional headers, bcc's & cc's), fixed sending to multiple addresses.
New features in modules (in addition to API compliance and templated output)
Modules module

filter by letter, state
graphical indicatator of state
detection of change of type, admin & user capability
ability to recover from missing files state


Blocks

graphical indicatator of state
ability to define each block as collaspable (credit to Mark Heldstab)
ability to define each blocks' default collapseable state (credit to Mark Heldstab)

Others

Groups - ability to add multiple users to a group in one go
legal - added template accessibility report (thanks to http://diveintoaccessibility.org)
Censor - added transfrom hook for censor module (supercedes pnVarCensor API - maintained for backwards compatability)
Admin - added ability to split modules into categories, the categories view are skinable via a single stylesheet
Credits - support for multiple module contacts via comma seperated values in pnversion.php

Generated on August 22, 2005.

REMINDER: Remove XMLRPC from your site!   (News)

The following was posted on June 29th in PNSA 2005-3:

DESCRIPTION
PostNuke CMS is an open source, open development content management system (CMS). PostNuke CMS started as a fork from PHPNuke and provides many enhancements and improvements over the PHP-Nuke system.
PostNuke CMS is still undergoing development but a large number of core functions are now stabilising and a complete API for third-party developers (including ADODB database abstraction and SMARTY templating) is in place.
The PostNuke CMS Development Team was notified about a security issue within the current .750 stable package and the .760 development tree.

VULNERABILTIES
- remote code injection via xml rpc library

SOLUTION
It is recommended that all admins deactivate and remove the 'xmlrpc' module within administration-modules and additionaly remove /xmlrpc.php and and the /modules/xmlrpc folder completly from the filesystem.

Andreas Krapohl [larsneo]
PostNuke CMS Development Team

Generated on August 16, 2005.

Page 1 / 4 (1 - 10 of 40 Total)