Development Update, March 2007

This is the the third development update issue in 2007, 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:

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 <ZIP> - modules - MyModule - pnuser.php etc so that an unpacked archive could be copied inside the pnroot. More information is in the Guidelines for module developers (not finished as yet).

Posted by Teb on Tuesday, March 20, 2007 Comments (15) · 2679 Reads

15 Comments so far

(Latest comments )

1. mhalbrook wrote on Mar 20, 2007 at 09:22 PM

Finally, Module packaging guidelines. icon_smile

2. davidnelson wrote on Mar 21, 2007 at 12:16 AM

Yes, my lang file review is planned to start on March 25, and should take about a week. At the same time, I'll be submitting patches where needed to clean-up the language output.

Clean language files plus a little cosmetic work on visual presentation (Jørn's pnForm framework is the perfect tool for that) are important prerequisites for a push on documentation.

Once those revised language files are ready, my plan is to work on some documentation, mainly concerning how to work on language packs and end user documentation to help more-inexperienced users get up and running quickly on adapting their webs and on producing themes.

But, as the core devs focus on building a powerful, secure core, we would really welcome more documentation contributors. If you can help document ANY aspect of PostNuke, please review the material already in the documentation Wiki and see what you could add or improve.

And please don't hesitate to contact me or any team member with questions, ideas and contributions.

3. JørnWildt wrote on Mar 21, 2007 at 08:11 AM

QuoteClean language files plus a little cosmetic work on visual presentation (Jørn's pnForm framework is the perfect tool for that)

pnForm may be perfect for that (at least it forces a consisten uses of CSS classes and form elements), but it requires a complete rewrite of the modules that intends to use it, so don't expect to see it in PN .8.

4. Lobos wrote on Mar 22, 2007 at 02:19 PM

QuoteFunctionality: The lock is maintained by an Ajax plugin that keeps pinging the server as long as user A keeps the editing page open.

What happens if the user editing doesn't have javascript enabled?

5. JørnWildt wrote on Mar 22, 2007 at 07:06 PM

QuoteWhat happens if the user editing doesn't have javascript enabled?

Then it does not work. But I believe it's fair to assume that editors have JavaScript enabled - it's already difficult, if possible at all, to use PostNuke's admin part without JavaScript.

PageLock is nota guarantee - it's a help. There's probably lots of other ways to bypass the system.

6. kaffeeringe.de wrote on Mar 23, 2007 at 10:21 AM

AFAIK the JavaScript in .8`s backend is unobstrusive - all JavaScript is optional. But also IMHO it's okay to have JS in the backend - else a lot of very good functions (WYSIWYG-Editor, Image Selection Popup ASO) won't work.

7. Landseer wrote on Mar 23, 2007 at 06:32 PM

Quoteall JavaScript is optional

Not yet

8. Lobos wrote on Mar 25, 2007 at 03:40 PM

I think it's time to take the step of making JS a requirement to use the admin portions of PostNuke. JS is just to damn handy and there is lots of mucking around in making it degrade gracefully - Virtually Everyone has access to JS so there is not real excuse not to have it enabled on a site that you are running.

JS should never be requirement for the public portion of a website though.

-Lobos

9. Simon wrote on Mar 26, 2007 at 11:25 PM

QuoteVirtually Everyone has access to JS so there is not real excuse not to have it enabled on a site that you are running.

We discussed this on the list - however you forget that disabled users with screen readers can't use fancy javascript controls. There are also other examples of environments in which javascript isn't available, unfortunately it's not always a matter of simply switching it on. In these cases you would be unable to administrate a PostNuke website, which is no use at all. As a result, any javascript functionality used in PostNuke will have a working fallback at release time.

10. czardogs wrote on Mar 29, 2007 at 02:33 AM

So many great things coming with .8 but what I haven't read too much about is PostNuke's current biggest failing - seo.

Is some of the simple stuff going to be addressed like meta descriptions unique to each article without needing to hack the core or through the use of an add-on that might not be forwards compatible? Nothing worse than doing an upgrade than having to fool around for an per website to get it as it was before - doubly so for those of us running dozens of PN websites...

Same thing with URL rewrite - what are the urls going to be like and do we have to fumble around to get them to work as they should for maximum seo benefit? Something like wordpress where we can select the type of URL output would be great.

Would love to see the news module with some extra fields where we can add the meta description and keywords and title at the point of creation.

If these things are coming and i missed reading about them I apologize in advance. Even if it doesn't come with this release I'll still use PN over its contemporaries.

11. kaffeeringe.de wrote on Mar 29, 2007 at 11:33 AM

The focus of .8 was to create a solid basis for future developments. That is why SEO was not so much of a topic. But anyway with larsneo we don't only have a major paranoid (security man) on board but also a SEO specialist (http://www.krapohl.info/).

The Short URLs in .8 are selectable. You can either have them file based - like they are in .764 or you can have them directory based - like they are in Wordpress.

The PageVar Lib enables every module developer to add content to the site's header. So you could add a field for example in Pagesetter for the meta description and then add its content to the header.

I read some think about the news module in the forum which suggested that there are several features that address your requests, but I have to admit that I haven't looked at the news module yet.

Please also keep in mind that there won't be too many new features within the content modules (Value Addons) as the focus was the core. .8 is a big step and it was easier to make the core step first and then push the modules.

12. Lobos wrote on Apr 05, 2007 at 12:59 PM

QuoteWe discussed this on the list - however you forget that disabled users with screen readers can't use fancy javascript controls.

Blind people can't drive cars either.

13. Rastus wrote on Apr 05, 2007 at 07:48 PM

QuoteBlind people can't drive cars either.

I'm not aware of any particularly credible arguments or discrimination laws that suggest blind people should be allowed to drive cars.

By comparison, we have things like this to consider.

14. Simon wrote on Apr 15, 2007 at 02:30 AM

QuoteBlind people can't drive cars either.

However people with impaired vision can use the web, and I see no reason why PostNuke should prevent them from doing so when it's perfectly possible to provide adequate fallbacks.

15. videokid wrote on Apr 15, 2007 at 04:43 PM

Blind people do surf the web! I even got an E-Mail to change a site if possible because accessing it was nearly impossible, I'll translate as good as I can

Code

The Most import is trying to avoid the graphical aspect, HTML text is the best, and please avoid the image at the start of the page, I know, it's a trend now, and for the non-blind people it's nice to see, but we have a problem with that. We don't work with mouse clicks, but with keyboard and arrows and using a tab-interface. The space-bar is our click-function.

That's why XHTML compliant pages are importatn, also using the div-header you can include a nice picture in the background, without actually using in page itself, so everyone is happy.
About the XHTML pages, I think that's a good start for SEO pages, experience learned me by making a semantic good XHTML page does more then all that other SEO crap, which is in my opinion totally overated nowadays.

-Igor

News