PostNuke

Site search

Search results

Number of hits: 117

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.

Url rewriting on Postnuke 0.8   (News)

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.


without rewriting
index.php?module=Users&func=logout Index.php? Users & module = func = logout


URL rewriting without mod rewrite

This rewriting reproduced a "virtual" Folders system on your site, links look like this


URL rewriting without mod rewrite
index.php/Users/logout



In terms of mechanism, it is very simple, when your Web server receives a request for a link, it loads instinctively page "index.html". 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

URL rewriting without mod rewrite
index.php/Forum/viewforum/forum:2




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.html"



Here is an example



URL rewriting with mod rewrite :Optimizing the previous version
/Users/logout




Be careful, if one of your pictures is written this way 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 ...
URL rewriting with mod rewrite : Mode file
module-Forum-viewtopic-topic-2903-start-0.html





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


Format of a encode and decode url
function pages_userapi_encodeurl($args)
function pages_userapi_decodeurl($args)



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"



Notes: A small problem nevertheless for the use of this rewriting, which is limited to the type url "user". (more details here)

This article is a translation from this "how to" released on Postnuke-France

Generated on February 25, 2008.

SEO for postnuke   (News)

Customize title
You can customize the general title of your postnuke, by filling in the correspondant fields in the module "settings". The problem is that, you will have only one title for the whole website ... and that's ugly (and bad for SEO).
A solution was offered by Markwest, in order to personnalize this title, on every pages.the title tag plugin

This plugin allow you to format titles like this
Classic titles
HTML for Module Developers - A Discussion :: pnCommunity :: Support at your fingertips


if you want to have shorter titles like this, you can use the other unofficial version in the comments.

Improved titles
HTML for Module Developers


If you're using pnForum, it will give you title like this

PnForum title



Customize meta "descriptions" and "keywords"
You can customize the meta "descriptions" and "Keywords" of you CMS, by filling in the correspondant field in the "settings" module, but with this customisation, you will have only one "description" and "keywords" fields for all the site.
In order to improve this, there are two plugin on the community repository, one for fixing the descriptions and the other one for the keywords tags.


Notes : As the Search engine were spammed by overloaded keywords tags, for most of them , they don't consider this tags anymore.
If you're using pnForum, it will give you this :

PnForum metas



Activate url rewriting
You can activate the url rewriting in Xanthia, go to the Xanthia module, then check the options "use short urls", and copy paste the .htaccess file from the "doc" folder to the root of you CMS.

/!\ Be careful, live search doesn't url with more than two dashes

Notes : an improved version of the current url rewriting is available in postnuke 0.8.

Duplicate content

Don't duplicate links in your portal, two differents links must not point to the same content. Indeed, some search engine don't like to see multiples versions of the same page on a website (that's called "duplicate content")

To avoid this, you can use a robots.txt at the root of the CMS
Robots.txt
User-agent: *
Disallow: admin.php
Disallow: config/*
Disallow: header/*
Disallow: footer/*
Disallow: pntables/*
Disallow: /images/*
Disallow: /includes/*
Disallow: /adlogger/*
Disallow: /themes/*
Disallow: /pnTemp/*
Disallow: /docs/*
Disallow: /javascript/*
Disallow: *.php
Disallow:module-Forum-viewtopic-topic-*-start-0.html



An other tip, "/index.php", "/index.html" and "/" redirect to the same page so you can add this rule in you .htaccess
.htaccess
RewriteRule ^index\.html$ http://postnuke.com [NC,R=301]
RewriteRule ^index\.php$ http://postnuke.com [NC,R=301]


Text formating

In your articles or templates, try to have a structured layout with H1, H2, H3 tags.


Autolink and intern link
The module "autolink" is interesting, because he allows you to create a large amount of intern links with the same source anchor, this will help to increase your rank on the given word

404 error

When you've got an important portal with a large number of pages , it may be possible some of you ranked pages doesn't exist anymore. When search engine bots come to look for this "ghost" pages, you can redirect them to the home of your website, with an "Error 404" header.

.htaccess
ErrorDocument 404 /index.html


Take off unused metas tags

For most of them, search engine bots don't read some meta like "revist-after", so you can take them of your head tags. It will not help you, but you will have a cleaner header.
xxx.html




This article is a translation from this "how to" released on Postnuke-France

Generated on January 31, 2008.

A Warm Welcome to Our Newest Member, Mateo Tibaquirá Palacios   (News)

Welcome Mateo, tell us a little about yourself. Who are you,
where are you from, and what do you do?
My complete name is Néstor Mateo Tibaquirá Palacios, but I prefer to be called Mateo. I'm from Colombia, a very beautiful country with some horrible problems; balanced, eh? I live in Popayán, where I'm finishing Electronic & Telecommunications Engineer Studies with an emphasis in Telematics (Information and Communications Technology). I chose Telematics because I like to program. Growing up, I did not have a computer, and from the distance I hated the idea of using a command line console. Now, it's different; I love my Ubuntu with the Yakuake console; and Eclipse PDT rocks!
At the University, I discovered that I had sufficient skills to write software. I began programming in C++ and Java some time ag

Generated on January 26, 2008.

HTML for Module Developers - A Discussion   (News)

ideas about good HTML. I haven't seen any layout tables for months. Many module devs even try to put semantics into their work.

No matter there are some things, I'd like to point out and discuss with you.


"Divitis" is the name of a HTML coding style that puts every possible Tag into div-Tags. I personally only use divs for the general positioning of my layout: header, content, left block, right blocks, footer. Anything else doesn't need divs around it. You can position every other tag in any way you can position and style divs.

Some of you use a separate class or ID for every single piece of content. This makes the code seems bloated and hard to maintain. Please use only as few classes as possible.

Some modules have a very great design but it doesn't really adjust to my own themes. Please don't define the style of h-tags, p, ul, ol aso. in terms of color, line-height or font-size and style. I think most webmasters already have a site wide definition for these tags and want all h2-tags look the same all over the site.

Use the CSS inheritence system for a slim style sheet: In .8 everything your module produces is put into a div:

[code][/code]

So if you want to style you module use e.g.:

[code]#pn-maincontent.pn-module-YOUMODULE * h2 {}[/code]

to make every h2 look the same in your module.

Please don't use h1 - h1 is the site's name.

These are no official guidelines - only my personal opinion which I wanted to discuss, in order to develop a list of tips for module developers. Please discuss here

Generated on November 21, 2007.

What's going on?   (News)

holidays there was not much acitivty in the SVN but now that both Mark and SVN are back we are fixing the remaining bugs for the RC2.

2. A name for the rebranding has been chosen. The Postnuke Foundation is currently in the process of trademark- and domain registration. The legal stuff seems to take some time. It won't contain a P or a N - so if you plan any new modules you shouldn't call them pnThisAndThat.

3. Speaking of module development:

a) Axel Guckelsberger of the Steering Committee just presented his diploma thesis: Modulestudio will not only revolutionize the way of programming Postnuke modules. It is way ahead of other similar systems. There will be a free version available but this will be a limited version.

Modulestudio, Google Video

b) Jørn Wildt started the work on the content module we discussed some months ago here and at the pnMeeting. This module is simply called "Content" and it uses all the new stuff in .8. The principle behind "Content" is that you first choose the layout of the article you want to write (1 column, 2 colums, whatever you like) and then you place blocks of content inside this layout with a smooth javascript interface. These blocks can contain text, images, videos, Google Maps aso. More blocks can be included as plugins.
http://noc.postnuke.com/projects/content/

c) As Jørn Wildt ceased work on Pagesetter ("I does all I need and it runs with .8") German programmer "Kundi" has picked up this work. He completely rewrites Pagesetter in order to remove Jørn's Guppy form framework and to include .8's Form framework, workflows aso. His first release will do everything that Pagesetter 6.3 does and it will be able to import from Pagesetter. Kundi is currently looking for a nice new module name. Any suggestions?

d) Robert Gasch works on a shopping module which won't be GPL - I was able to take a preview and it looks very adult and I think it will be worth it's money.

e) The last time I looked at pnUpper it was kind of a niche module that I never really had any use for. Axel Guckelsberger is currently turning it into a full fletched media library for the central storage of any kind of media to be used in other modules. Thus he renamed it to MediaAttach.

MediaAttach

4. Now that the NOC seems to be kind of stable again we hope to have time to replace it with a less complicated software. We ar

Generated on November 20, 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)

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.

Generated on May 28, 2007.

Development Update, March 2007   (News)

Dot 8 evolving: language files progression and legacy functionality
Thanks to the testing of the community users (yes, YOU!), some legacy functions (residing in /includes/legacy/ have been updated by Simon to solve some bugs. This is another proof that we do need everyone to test the releases and help not only yourself to make this release a success! The following files have also been marked 'deprecated', with an accompanying comment in the DocBlock: admin.php, backend.php, banners.php, error.php, modules.php, print.php and user.php. These files shall be removed in the next (post-dot8) major release.
The overhaul of language files has also applied to the Groups, Theme, Users and Profile modules. These modules now have better multilingual options and (by using the pnML function), making it a lot easier to translate the package and showing better logic in grammar for localisations. Furthermore, lots of open bugs have been solved and the templates have been revised also. For example, the emails sent by the Users module can now be adjusted by just editing a template!
David Nelson has offered to completely review the language files for dot8, and we all have to thank Olaf Fichtner for helping revamp the current language constants. The PostNuke Languages Project is actively following the development!
Important change in the language strings is the use of the _CREATEDBY / _CREATEDON and the _UPDATEDBY / _UPDATEDON constants. For better support in other languages, these are replaced by the following:

'_CREATEDBY', 'Created by %username%'
'_CREATEDON', 'Created on %date%'
'_CREATEDBYON', 'Created by %username% on %date%'
'_UPDATEDBY', 'Last updated by %username%'
'_UPDATEDON', 'Updated on %date%'
'_UPDATEDBYON', 'Last updated by %username% on %date%'

and can now be accessed through the normal pnml plugin in the templates.

System modules: pnForm and PageLock
Jørn has moved the pnForm framework to it's own module location within the system directory. Major reason for this is to properly save some pnForm specific javascript and style files. Usage of the module should be quite the same. In addition, some new context menu plugins have been added. These plugins create a popup menu to be used as a right-click context menu. More information can be found in the added files in the pnForm plugin directory, and at the pnForm Wiki Pages.
Also introduced by Jørn is a new system module. The PageLock module is a module that helps enforcing single user access to a specific page, by blocking access to other users when one has it open.
Example: User A opens article X for editing. This is registered on the server. User B tries to open article X for editing too. But as soon as the article editing window is opened, it is overlayed with a transparent dark film and a box in the middle tells the user "Sorry this page has been locked by user A - please wait or come back later".
Functionality: The lock is maintained by an Ajax plugin that keeps pinging the server as long as user A keeps the editing page open. When user A closes the window then the pinging stops and the lock times out. If user B chooses to wait then his page keeps pinging the server for the release of the lock (also Ajax) - and when that happens he gains access to the page. The module can be used on all pages that edites a single item - articles, user data, news items, book pages, permissions settings - you name it.
To use this system, a module author has to use API calls in their own code for adding or releasing a block: pnModAPIFunc('PageLock', 'user', 'pageLock', ...) and pnModAPIFunc('PageLock', 'user', 'releaseLock', ...). To see al this in action, grab the latest nightly snapshot and play around with the HowtoPnForm module: edit a recipe in one browser, and try to edit the same in another browser.

ValueAddons modules: Members_List and EZComments
The Members_List module has been revised by Mark West, with some added configuration options. It is now possible to set the number of (allowed) registered users, and some new blocks (featured user last seen and last x users) have been added. Check out the latest nightly build to see the functionality and options.
Mark has now finished the integration of categories into the user side of the Reviews, Pages, FAQ and News modules. This way, migration of .7x categories into the new Categories module is now supported and can be tested by our users who want to upgrade their .7 site to .8.
Finally, there have been added configuration options for categorization and category titles in the permalinks with these modules.
One hot issue at the moment is the increasing amount of spam that is on lots of websites at this moment. More and more features are to be found on the internet to prevent spam showing on your site. Akismet / Bad Behaviour are one of these. As some already know, Akismet has been applied in EZCommnents for a while. For testing purposes, Mark has implemented a bad behaviour (http://www.bad-behavior.ioerror.us/) function also for testing purposes (as Steffen has found that this could also be a good application). It does need some code hacking to pnApi.php at this moment, so only advanmced users willing to help integreating this feature are invited to test this and report any iussues to the EZComments tracker at the EZComments NOC project page.

Core and API: ThemeUtil and Categories
The pnTheme system has now been converted to the ThemeUtil class. With this conversion, all occurences in the core were updated too. Both the old and the new file are loaded in pnInit for backwards compatibility, but the old file (onTheme) and its functions are now marked as 'deprecated' and will be removed in the next major release.
Also added to the new ThemeUtil is a getModuleStylesheet method which contains the logic from the modulestylesheet plugin. You can do PageUtil::addVar('stylesheet', ThemeUtil::getModuleStylesheet('modulename')) to include the value of pnModGetVar('modulename', 'modulestylesheet') or style.css (in this order) or PageUtil::addVar('stylesheet', ThemeUtil::getModuleStylesheet('modulename', 'special.css)) to include the special.css file in your rendered page.
While unnecessary for correct functioning of the website, one is now allowed to turn off session regeneration completely. This is added because it may be helpful with a couple of undecided bugs in the tracker at the moment.

Module Development: information for 3rd party Devs!
Axel introduced a very nice application called EasyDist. This allows you to create your own PostNuke package easily. You can find it at modulestudio.de. It is still in a very early stage, but you should get the idea. This is all still in development fase and is just for testing purposes at this moment.
A preliminary for the (automatic) creation of packages using EasyDist is that module authors package their modules in a standard way. Right now, there are different file structures in the ZIPs or TGZs the authors distribute. We came to the conclusion that the preferred file structure inside the archive should be - modules - MyModule - pnuser.php etc so that an unpacked archive could be copied inside the pnroot. More information is in t

Generated on March 21, 2007.

Module Developer Mailing List Started   (News)

In order to not turn the list into a normal support list, it will at least start as an invite only list. But archive is public.

We will also use this new developer network to coordinate our efforts regarding the organization of the developers community. For example first ideas about a better NOC are being discussed.

Links:

Mailing List Archive

Generated on March 20, 2007.

Page 1 / 12 (1 - 10 of 117 Total)