PostNuke

Site search

Search results

Number of hits: 27

Pricing   (Content)

PostNuke is free to download and use for both commercial and non-commercial use. It is licensed under the GNU/GPL version 2 license. The GPL allows you to modify the code without restrictions ensuring you can customize it to fit your project requirements. You can also redistribute your work, with the understanding credit must be given to the original authors and that you must also license the new modified code as GPL. At no time are you permitted to change the license terms.

The GPL license ensures you have full access to the source code. This gives peace of mind about security since nothing is hidden

Generated on February 1, 2009.

OpenID for PostNuke   (News)

If you haven't read that yet and is interested in OpenID then please read it here - it will explain the whole OpenID background.

For those of you that haven't heard about OpenID yet, here is the very short explanation: OpenID is a relatively new web-technology for managing your online identity. It's primary purpose is to facilitate Single Sign On across independent websites. This means you can create yourself an OpenID identity and use that for login in to different websites without having to retype your password over and over again.

When I wrote the last article I promissed to deliver an OpenID implementation for PostNuke, and, well, here it is! You can now download OpenID from the NOC OpenID project page.

By installing this module you enable your users to:


Register an OpenID with their PostNuke account and login with this OpenID. The OpenID manager page can be found in the user account panel (Profile).

Create an account on your website using OpenID's registration process.


The OpenID module requires PostNuke version .8 from SVN (april 15th) - and probably also PHP 5.x since a required extension "domxml" is not delivered with PHP 4.x.

So don't hesitate - get your website OpenID enabled today and save yourself (and your customers) the hazzle of managing multiple user accounts.

Intra-web usage
You can use OpenID for Single Sign On between closed "intra-webs". For this
you must have a trusted OpenID Identity Provider (IP) - either your own or an
external one. Then you add a filter on the OpenID admin pages - this filter
should allow access from your trusted IP and deny access from any other
provider. In this way only users from your trusted IP will be allowed to access
your website.

Read more

You can find lots of information about OpenID around the web. The most obvious place to start is of course openid.net. But at openidbook.com you can get a free copy of the 200+ pages OpenID book from Rafeeq Ur Rehman. This should satisfy even the most curious people

Enjoy, Jørn Wildt

Generated on April 16, 2008.

PostNuke .8 RC1 Released   (News)

PostNuke 0.800 RC1 Core Only Download
Download (ZIP)
MD5: 17d7f2eb16bf4dd886695adefab0e1f5
SHA-1: 624dcb1b29c17150e341878c727ddac83fadeb54

Download (TAR.GZ)
MD5: 9807fe2f3e0ef9f7fa88a3bbb0426815
SHA-1: 354edfc9eff87f77713bc1750cdc77144fcf0bff


PostNuke 0.800 RC1 Full Package Download
Download (ZIP)
MD5: 15718c1d68223bf5fc69b144666741f8
SHA-1: e1901b3d06dce1b82f2dfcde4d2da74e7afb9cf8

Download (TAR.GZ)
MD5: 1d983e5fd18907022fbec598c4ae7111
SHA-1: afb25ef625ce6e1564c40faf1cb29b3c1ea0ee13


PostNuke 0.800 RC1 ValueAddons Download
Download (ZIP)
MD5: 38879b481640289b7b6a605af41638a1
SHA-1: aa10e8f79d038b667aa8638347d3d12a999d8e99

Download (TGZ)
MD5: 4adc34945ae0cf42b3f96408bd21d17c
SHA-1: d4f80e0478bef1721eb29484024a9ed7a1a2e025


Please feel free to use the article below to publicise PostNuke in any web development communities you belong to. It is also published here on community.postnuke.com.


Simon BirtwistleHammerHead

About PostNuke

The PostNuke Application Framework provides a high performance, secure and feature complete framework which both website administrators and web developers can use to great effect in creating unique and attractive websites. PostNuke can be used as a CMS, adapted to blogging, ecommerce or community websites, or for more abstract tasks. It is easily adaptible, extensible and can handle situations in which performance and security are paramount. In this way, PostNuke is a reliable and robust choice for any website administrator.

The most recent version of PostNuke is 0.8 RC1, which represents a feature complete 0.8 version. Once the release candidates have undergone full testing and any remaining bugs are fixed a full release will be made available. This release will be suitable for live websites, however in the meantime RC1 is suitable for testing and development work.

Highlights For Website Administrators
The 0.8 release is more polished and up to date than ever before. With the new libraries for developers, new features should be faster and simpler to develop, reducing deployment costs. PostNuke 0.8 can be adapted to almost any need, from blogs to community websites and new third party modules are being developed all the time, constantly improving what PostNuke has to offer.

Additionally PostNuke 0.8 has a focus on the latest standards: XHTML compliance, Section 508 and Accessibility, and further enahncements have been made to both security, performance and usability.

With all core modules now templated, PostNuke 0.8 is designed to be cached, providing a huge performance boost over dynamically generating every page. Furthermore, with the templating system applied to all core modules designers will find it easier than ever to create a unique look to their websites. Gone are the days of standard 3 column layouts - PostNuke 0.8 includes new themes which are CSS, and not table, based. The new Xanthia theme engine is easier to use and performs better than ever before, while including an upgrade feature making it easy to import Xanthia themes from previous PostNuke versions.

For website administrators, this is the best PostNuke release yet, combining compliance with the latest standards and constantly improving features.

Highlights For Web Developers
The 0.8 release provides an Application Framework to allow rapid development of web solutions using the now stable PostNuke core. This allows third party developers to use the wide range of included API and utility libraries to create their own modules and extend the feature set PostNuke already provides.

Of these libraries, one of the most substantial is DBUtil, providing a cross compatible interface to the database. Selecting, updating and deleting data can all be achieved in one line, and DBUtil, combined with ADOdb will automatically create a cross compatible query for whatever database system is in use. PostNuke .8 has been tested with PostGreSQL, and further databases will be supported in future versions.

Other key features are site wide categories, supported through integration with DBUtil, the PostNuke Forms Framework for HTML forms, and other object based APIs. All of these are new since the 0.7x series and ensure third party development is both quicker and easier, and that compatibility with future versions is maintained.

For web developers, PostNuke will provide an attractive option when searching for a framework upon which complex web solutions

Generated on July 17, 2007.

Development Update, December 2006-06   (News)

MileStone 3
The Dev Team is proud to conclude that MileStone 3 is quite near for release (check the .8 Development Cycle for details). With an enormous amount of commits from Robert, Oracle, PostGreSQL and MsSQL support are close (but not quite complete). The entire distribution should be tested for support to ensure the functionality. For this testing, there is an additional Theme plugin added for better / additional sql debug tracing output / options (function.sqldebug.php).
Patrick started finalizing the Search module, which involves every module that provides searchable data to have a pnsearchapi.php file and two templates, module_search_options.htm and module_search_results.htm. For better functionality, each searchplugin is given its own "namespace" via the array functionality of html forms. When each module is compliant to this standard, much gain can be achieved because (for example) inactive modules will not be called for a search query. Also, modules do not need to check for formdata themselves. See also Module Programming Part 4.
Drak has worked on an upgrader for 0.76x. This incomplete first version of upgrade76.php prepares the core so the usual upgrade script process can run.

Categories
The Topics module has been discussed within the theme. As most of you already know, the Categories module is much more powerfull for assigning categories (or topics) to various content on a PN site. The Topics module is an old style module, however lots of modules still rely on the presence of the module (or at least its tables), allthough the modules write directly to the code.
The Dev Team is currently looking for a way to import current Topics into the Categories so that, with an upgrade, on does not have to add these manually. It is up to module developers to support the new categories module, and not rely on the deprecated Topics module anymore. The import process of the Topics module will belong to the Categories module init.
We would like to urge all our test users (not necessarily has to be a developer) to take a look at categories, play around with it, test it, use it and come up with a list of bugs and suggestions for improvements. For feedback, one could use the 0.8-MS2 Feedback and (as always) bugs can be reported to the bug tracker.

System
Discussed in the team is the addition of config.php.dist files. In short, PostNuke is supplied with a dist file which will be read and modified by the installer, and then saved as config.php. The advantage is that config files can not be overwritten anymore when one upgrades it's PostNuke version. The disadvantage is that the webserver user (for example apache) will be the owner of the file. No decision about this issue has been taken yet, so for this time the historic way of config files is still active.
Jörg has worked on a basic check for module directory consistancy. This means, if there are duplicate module names (like system/foo and modules/foo, or even modules/FOO and modules/foo), the administrator will be noticed about this issue.
Another change is that module vars are now all serialized in the database and there is no longer any need for module developers to serialize or unserialize data before making the database calls.
The modules and system directories, and their purposes, were discussed. The system directory should only contain modules that are not allowed to be removed (the system wouldn't work without them), and the modules directory should include ValueAddons and 3rd party modules that are not a vital part to the core of the PostNuke framework. When you upgrade a module, it is left in an unactivated state, which isn't desirable to system modules. Therefore, System modules are now allowed to transition directly to active state after an upgrade.
The Error Logging functionality has been extended. If a pnRender template does not exist this will also be logged, which could be quite usefull for module developers.
The LogUtil::registerPermissionError() and LogUtil::registerAuthidError() methods are added. These method calls registerError and then logs the failed permission check and failed AuthID check respectively, so that they can be analyzed later. DB errors are now logged by DBUtil and Log Events can now be viewed in the Security Center.
Added by Frank is the option in the Users module to deactivate a user account untill the user re-accepts the terms of use. If he is logged in when deactivating the account he will be logged out during the next page load.
The returned header for a non existing user page now returns 404 in stead of 200, and the age check has been simplified and harder to get around.
Frank also enabled the addition of a generic object attribution (a very nice feature of the ObjectUtil) for the users table. Using this, one can add any datafield to the users table (as long as it is a string with max. 255 characters ;-) )
E.g. it is possible for pnForum now to store user related data this way, which makes its own user table obsolete. If you, as a module developer, need a new datafield, just add it and it is there.
Example: You have an attribute 'someattribute' with 'somevalue'. The array returned by pnUserGetVars() now contains an item '__ATTRIBUTES__' which is an associative array itself with key 'someattribute' and value 'somevalue'.
More information and code snippets can be found in the Wiki after the coding has completed.
Finally, the functions includeOnce and requireOnce were added to the Loader class, which speeds up require_once and include_once by a factor of up to 9 times.

New and updated pnRender Plugins
All pnRender plugins in the core will be renamed to lower case. The parameters used should also be lowercase. The Dev Team would recommend all module developers to do the same.
The following plugins were added or modified:

add_additional_header plugin is replaced with the pnpageaddvar plugin.
moduleadminlinks plugin is modified to add capability of separate title attribute, and allow links to be 'disabled'
pndebugenvironment and pndebug plugins are extended with more info and multilingual support
makelinks outputfilter (theme) plugin is a replacement for pn_bbclick, to create clickable links from urls

Finally, Jörn is planning to use the ExampleDB module as an example for the use of the pnForm plugins also.

ValueAddons
Some deletions have been applied to the ValueAddons directory, as follows:

TypeTool: This editor hasn't been updated since ages, the corresponding sourceforge project seems to be inactive for a while, and the html code created by typetool is not following current standards.
Replaced by Xinha (download)
Autolinks and Censor
Replaced by MultiHook (Minimum version needed is MultiHook 5.0 alpha)
Downloads: Maintained by cmods-dev.de
Weblinks: Maintained by cmods-dev.de
Messages
Replaced by pnMessages (download)
Polls
Replaced by AdvancedPolls (download)


Translations / Language defines
Another 'standard' that the Dev Team would like to recommend to module developers is the use of a naming scheme for translations, as it would help a lot to create more multilingual modules.
Each module should use module specific prefixes in their constant defines, e.g. _FOR_SOMETHINGISMISSING for Formicula or _PNMSG_INBOXFULL for pnMessages. This makes it easier for pnDefinemachine and can lead to more consistent translations.
This also enables us to implement an updated pnml plugin/function that offers the same kind of possibilities that the MultiHook has. All translated defines (or missing defines) get a little button that allows the admin to work on the translaton online while surfing his site. Changes will be stored directly in the pnDefinemachine tables to create the language files later on. Here the prefix enables us to attach the translation to the correct module.
Of course looking up translations in the database is a performance hog, but this should be used during development or if someone is not satisfied with an existing translation.
The current SVN packages can be more and more used as a basis for the .8 language packs: dutch and german translations have already been updated for use with .8, and can either be checked out through SVN or be downloaded as an alpha package.

.8 Stabilization: We need you!
To finalize and stabilize the last MileStone release (and to offer a first release candidate as soon as possible), we need you (the community) to test the current codebase. Install and uninstall all available modules, create users, play with hooks, create and use themes, develop modules, and so on.
Please download the latest Snapshot and install it on your test system (either a webserver, or your local Xampp installation). Wether you have IIS, Apache, MySQL, PostGreSQL or MSSql, it is interesting for all of us. Please also use the ValueAddons package and do the same. You may notice that no real new features are added to them, but this will come when the core is functional and as bug free as possible. If at all you find unreported bugs or errors, please report them in the bug tracker.
As already said: The Core Dev Team is at first interested in a working bug-free core framework and a functional upgrade path from historic distriutions. After that, new features can be added to several ValueAddons and other content modules. One could also use the current Theme module to generate Xanthia 3.0 themes. A useful help for this can be found on Drak's Theme Generator. Module Developers can find a Module Generator on the OpenStar site.
BTW, the .8 Developer Docs in the Wiki may already be very usefull, allthough the provided information is not as complete as one would wish for. Users may find lots of usefull information in the .8 User Docs.
Reminder: Please do not use .8 on any live production site! With MileStone releases or Release candidates, there is no guarantee whatsoever that the quality and security of your site and the product is assured!
Also (as read from the German Community Site) there are a few modules released in alpha status for users to test in a .8 environment:

Formicula 2.0 alpha: Download (Bug reports)
pnUpper 1.0 alpha: Download (Bug reports)
pnTopList 1.0 beta: Download (Bug reports)

Generated on December 18, 2006.

PostNuke and its future language system: a translator's viewpoint   (News)

1 What this article is about, and why I'm writing it
PostNuke has developed quite a lot since it forked from PHP-Nuke; many changes have already been implemented in 0.7.6.0, and many more will be reflected in 0.8. However, compared with other parts of the core code, the language system hasn't changed much. And what has changed recently might not always have been a good idea.
Most of the development work on PostNuke is done by speakers of European languages (predominantly English and German, but also Danish, French and Spanish, to name but some). Speakers of those languages might not be aware of the differences between their mother tongue and some of the more-exotic but widely-spoken languages in the world. Since I spend quite a bit of my time applying different languages, I'd like to show a few problems and make a few suggestions that perhaps could be further discussed.
I have looked through the PostNuke language files before, but it was only when I, together with two students, attempted to translate them into Chinese that we noticed how difficult a task that can be. Parts of PostNuke 0.7.6.0 actually cannot be translated meaningfully into Chinese or Japanese anymore.
When I was working on the translation, I happened to "complain" in the pnLanguages forum on PostNuke's NOC (Network Operations Center) about a few of the problems, and was answered by David Nelson of the pnLanguages team. He suggested I should put all my "frustration" (well, it isn't that serious, but some of the problems really are…) into an article, which is what I'm doing right here and now.
2 Current problems with PostNuke's language system
There is a thread [1] on the PostNuke forums, started by ColdRolledSteel, in which he raised a number of very important points. It was that thread that actually made me start thinking about the shortcomings of the current language system, and what the solutions might be.
If you read further on in that thread, you will find comments about 0.7.6.0. It's a long discussion, but if you're interested in PostNuke localization then I recommend you to read all of it, since many serious problems are mentioned. Good-quality localization into some languages may actually become very difficult unless the language system is overhauled.
Most PostNuke enthusiasts know that PostNuke forked from PHP-Nuke. With PHP-Nuke, not only do you have to pay to get access to the latest version of a GPLed software, but also many people would probably agree that there can be significant changes from version to version.
Not all of those changes may be approved-of by many, since the line of development of PHP-Nuke is decided by just one person: Francesco Burzi. You can read many posts in the PostNuke forums about the problems the PostNuke developers have had in fixing problems caused by PHP-Nuke code leftovers.
What seems to be forgotten is that, unfortunately, one of the legacies is the way PostNuke handles languages.
Here is a summary of problems raised in the above-mentioned thread and other threads, that I encountered:
too many files;
too many phrases used multiple times;
language files are hard to handle;
separation of grammatical particles can make it impossible to provide a good translation in some languages.
Again, please read the above-mentioned thread [1].
3 Suggestions
3.1 Files and folders
3.1.1 Simple structure instead of chaos
Instead of having one language folder for each language in every module folder, why not have just one central "language" folder with just one file for each language? The file could be an XML file, containing all the strings needed by the core system. If a new module is installed, the installation procedure could copy all needed variables and strings into that file. When a module is uninstalled, the de-installation procedure would then be responsible for removing those strings from the language file (in the same way that tables are created and deleted at present).
3.1.2 Why the current language system is chaotic
Does anyone know how many variables and strings are used in the core system alone? Maybe some of the developers will know (though I seriously doubt it); but, certainly, nobody who tries to produce a language pack knows. What they will soon learn, however, is that many strings show up more than once.
If I recall correctly, there are also a few different variables for the same purpose/string. All this is definitely not very motivating for those who want to translate PostNuke into another language. Plus, the translator may well not remember the exact phrase he/she used the last time this string was encountered a few modules ago. Just as there is often more than one way to express something, there is frequently also more than one way to translate a phrase. So, if you consider consistency in translation to be important, the present language system does not help achieve that.
It would also help if the above-proposed single language file could be processed by software. I mean, the year is 2005 and even translators are using computers these days. Every step that makes administering and translating strings easier will lead to better productivity, higher-quality output and availability in more languages. A translation tool (something like pnDefineMachine) should be included in the PostNuke core distribution, and should allow translation of core and third-party modules. To give translators more flexibility in working, it would be ideal if all identified strings could be exported to a file so that they can be worked on using other software and then re-imported.
3.2 Strings and variables
3.2.1 Simple, unique, short and distinct
All strings should be revised to check whether they are really necessary. They should also be as short and as clear as possible. If one single file were used, it would be easy to eliminate duplicate strings and variables.
Any variable output from the PostNuke code (a number, a user name, etc.) for incorporation within a natural language string should be included in the language file. It should also be possible to choose where in the string the variable is positioned.
In the past, developers often just created two language "defines" and the translator was left to guess what was missing between the two. Sometimes, due to the ordering of "defines" within the language file, the translator also had to realize that two "defines" were indeed used in conjunction, because they did not follow in succession. In such cases, some burrowing through software code files was needed for verification and understanding.
This problem is slowly being addressed. The age check string from the NewUser module's global.php language file is a good example. This "define" allows for free placement of $minage within the translated string:

define('_MUSTBE','You must be '.$minage.' or over, or have parental permission to register for an account on this site.');
All strings should compose a "meaningful phrase". The best would be a complete sentence, but in some cases single words or short phrases may be OK or are unavoidable. Just please, please don't separate any prepositions or similar grammatical particles.
3.2.2 Why translating current strings can be really frustrating
Imagine you tell someone, "Here, this is what you've got to translate. Some strings will show up twice; but some occur three, four or even five times. No, I can't tell you which strings. Just translate it. Oh, and you won't be getting any clues about what some of the cryptic, enigmatic phrases mean, nor where to find them on the site." How motivated do you think that person will be?
How happy will the translator or a webmaster be when he/she encounters something like the "define" below (from the Xanthia module's admin.php language file)?
define('_XA_CONFIGINFO','Simply enter the new value in the text area and click Commit, the changes will take effect immediately. Unfortunately, the ability to create and delete general configurations has been removed, as it was never fully implemented and now never will be.');
Translating a language pack should mean translating the user interface, not the story of PostNuke's life – that's something to include in documentation, no?
In addition, it would be helpful if developers do their best to make strings clear and understandable! This one that used to be in the Downloads module's global.php (now rectified) could phase a native English speaker, let alone someone else: "Let main vote summary decimal out to n places".
The general lack of informative and explanatory comments in the core code files and language files does not make a translator's work easy.
And dealing with problems is made harder when strings occur multiple times.
I know the code is advancing with every new version of PostNuke. But, unfortunately, this is not true from a linguistic point of view. 0.7.6.0 is a step backwards, although it was probably meant to take the language system forwards.
Let's look at some examples involving a number of languages: English, German, Chinese and Japanese, but some others are mentioned as well.
Many native speakers of a language may not be very familiar with all the theory behind their mother tongue's grammar. They may have had to learn it at school, but now they just use it naturally. For localization however, it may be necessary to dive into all that theory a bit.
The English language (along with many others) uses prepositions ("on", "in", "behind"...). But some languages don't have them. Hungarian, Finnish and Japanese use postpositions instead. That's right, they come after the object, not before it. In Chinese, there are prepositions, but many phrases use constructions similar to postpositions.
Let's look at the problems that this can cause. Let's take this sentence: "The book is on the table".
"The" is a definite article; "book" is a noun; "is" is a verb; "on" is a preposition; "the" is a definite article; and "table" is a noun.
"The book is on the table" is a simple sentence which, in German, translates to "Das Buch ist auf dem Tisch." It's hard to deny that German and English are somehow related.
But the same cannot be said of Japanese. "Book" in Japanese is "hon", and "table" is "tsukue". Since a book is not a living creature, the verb used will be "aru" or, in neutral politeness, "arimasu".
But how about "on"? The correct word here is "ue", but you can't just use it that way. "Ue" means "top", "above"; so, in Japanese, you have to say "on top of". "Of" would be "no"; "on top of" becomes "no ue ni" ("inside the top of something", so to speak). Did you notice the different order? Now here's the whole sentence: "Hon wa tsukue no ue ni arimasu." ("Wa" is just a particle marking a sentence's topic.)
While "book", as subject, is still at the beginning of the sentence, it is followed immediately after by the object, "table", then the postposition, and finally the predicate. Now imagine what incorrect or incomprehensible Japanese would be displayed if prepositions and other words for a given phrase or sentence are spread within separate "defines" in the language files. If you read through the forum thread mentioned at the beginning of this article, you will also find a few examples for Finnish. If you "turn the table" and try to make an English sentence translated word-for-word from the Japanese sentence structure, you would get something like "book table on is".
This is another reason why variables that will be processed by the PHP code, and rendered in an output form to be incorporated in the displayed string, should be included in the "define" for that string in the language files.
Let's take another simple example: in English (and many other languages), we say "A of B", as in the phrase "3 of 10 users". But in Japanese, it is "B no A" (and "B de A" in Chinese). So, simplification is a good thing but needs to be done the proper way, otherwise important parts of PostNuke could be practically unusable in a few languages in which the potential user base might be enormous [2]. Do you think a Chinese or Japanese would like a portal that tells him "10 of 3 users are currently on-line"?
By the way, did you notice that there are no articles in the Japanese example? English has one definite article (effectively one gender), French has two (for the masculine and feiminine genders) and German three (for the masculine, feminine and neuter genders) , so there are big differences between languages even for such an elementary point of grammar. But then consider the treatment of number and quantity in different languages: anyone who has examined the language files will know that there are different strings for "day" and "days", since singular and plural exist in English, German and many other languages. However, this isn't true for Chinese: "day" is "tian" in Chinese, and no matter whether you're talking about one, two or a million days, it's still "tian".
3.3 What we can do
3.3.1 Where we really can simplify and standardize
We could create standard "interfaces" for both code (variables) and strings. Since, in the system discussed herein, we would already have only one file, we could establish a list of standard actions like "delete", "create", "submit", etc. This list should be extendible, so that module authors can add any "special" actions for their module (although it would be nice if those "special" actions, too, could be managed by the core development team, otherwise duplication is likely to occur once again). But when already-available actions are used, the module developer would just use the existing variables in their code, and wouldn't have to worry about defining the corresponding strings, since they would already be available in the core "library". Obviously, that implies the existence of a good developer's guide that gives module and block developers proper information about the PostNuke programming API.
3.3.2 Separate what can be separated
So far, we have been advocating the use of language "defines" that contain complete phrases and sentences, incorporating any necessary variables (or, at least, place-holders for variables) for which literal values will be supplied by PHP. As from 0.7.6.0, the developers started to separate prepositions in the core language files. I just tried to show that this may not be a good move, but let's see what we actually can separate out.
It is not a good idea to strip grammatical particles, since grammar can be very different from language to language, and those particles are precisely that: particles. What we always need in order to properly construe a meaning is a semantic unit that conveys enough useful information to allow the receiver to understand the intended sense.
Let me explain this with the above book example: Someone tells you that the book is on the table. However, since a tram was passing by, or you were just distracted by a pretty woman or you were simply asleep, you didn't clearly understand all of it; so you ask that person to tell you the same thing again.
Now, that person may think you are a foreigner and don't understand much English, so he may think "let's make it simple for that poor fellow" and just tells you, "Book". Nice. Yes, I know what a book is. But does he want me to write a book, buy you a book or did I perhaps completely misunderstand and he wants me to book him on a flight to Alaska?
He repeats, "The book." Nice. Now at least I know that he doesn't want to go to Alaska. "Table," he adds. With much imagination, I might start to guess now that there is a table with a book on it. If I had heard the complete phrase just once more, there wouldn't have been any problem.
But how about single words then? In English, there is something called the "imperative mood" for its verbs. The verb itself does not change, since there is no flection. So, at least in English, you don't see a difference between the regular form of a verb and its imperative mood. However, you can shout "Shoot!" or "Fire!" and the receiver of that order will know what to do.
Not every language will use a verb to express this. German will use a noun, "Feuer". Japanese is closer to English this time, it also uses a verb: "Ute" is the imperative form of "utsu", which actually means "to beat". So, what we can strip are units that can stand alone semantically, and actions are one such thing.
It may happen that such an action is not always a single word in every language, but to organize them in a list and to standardize them system-wide would help to create a more consistent user interface. It would be a bit like function calls in a code library, but for strings.
3.4 Error messages
3.4.1 Error codes in one list
It is common in software design to assign codes to errors and to display a message corresponding to the code. As with the actions discussed above, we could create a list of error messages shared in common by any module and block throughout PostNuke.
3.4.2 It says "Xxx". What should I do?
I think everyone has seen "a few" posts in the PostNuke forums asking what this error or that error means. With the above method, a given error would produce the same message throughout the whole system. It would probably even be possible to provide a list of possible causes for each error, so that users can solve their problems more easily. But again, who would want to maintain a list of causes, if every module comes with its own error messages, each of which is phrased differently even though it pertains to what is effectively the same error?
Obviously, because a module often provides some special functionality that does not exist in other modules, there will probably be some module-specific errors. This problem could be solved by asking every module developer to apply for a block of error codes for that module. Again, the installation procedure of that module would have to take care of copying that block of "defines" and strings into the main language file.
3.5 Expand your horizon
PostNuke is GPL software, and so are many other content management systems [3] and portals that exist today. If they want to implement really-extensive internationalization [4] of their design, then they face the same problems as PostNuke. Some of their people may have come up with solutions nobody here thought of, so why not look around and see how they solved some of the problems PostNuke has to deal with?
One example could be Drupal [5], which has found a few solutions for language-related [6] problems [7] that could prove useful.
4 Conclusion
This document is far from being complete. It only takes a glance at a few languages: more input is needed from speakers of other languages. Also, the modifications I suggested may not always be the best and there are probably also other improvements that can be made. However, if PostNuke really intends to move towards broad internationalization, then it will be necessary to revise the language system and, possibly, other parts of its design. This article is intended to contribute to a thought process about that.
Obviously, nobody knows all the "features" and "traps" of all languages. That's why the pnLanguages team needs to have members from as many different nationalities and languages as possible, so that we can assemble guidelines that will allow the correct use of any language in which we have a user base.
Localization and translation are now recognized as key issues for the PostNuke project. When it comes to language and internationalization, more liaison between the pnLanguages team and the core development team will be very important.
Relevant links
1. http://forums.postnuke.com/index.php?name=PNphpBB2&file=viewtopic&t=24602
2. http://en.wikipedia.org/wiki/China#Demographics
3. http://www.opensourcecms.com/
4. http://www.debian.org/doc/manuals/intro-i18n/index.en.html#contents
5. http://drupal.org/
6. http://drupal.org/handbook/modules/locale
7. http://drupal.org/node/24593
8. pnLanguages project on PostNuke's NOC

Generated on September 11, 2005.

Moving on: Better PostNuke ShortURLs   (News)

PostNuke sites well, while making the URLs hard to post to people in email or in forums. For instance, a news link looks like this:
/index.php?name=News&file=article&sid=123&mode=thread&order=0&thold=0

For some time now, PostNuke users have cried out for better Search-Engine Friendly URLs, and for the past few years, the only thing available has been a theme hack first detailed by Karateka (possibly E. Soysal before that, the links in the article are dead) way back in 2002, since worked on by ColdRolledSteel (Craig Saunders), and consequently me.
The advent of the ShortURL hack has seen sites hosted on Apache servers with the URL Rewriting module (mod_rewrite) enabled get URLs like
/Article123.html

for the above link, where certain assumptions have been made about the default settings for mode, thread and threshhold. A big improvement, but not very descriptive, and it comes at the cost of heavy post-processing of the site's content for links. Also, Search Engines use link keyword relevance in their rankings, and Article123 doesn't say much about the link, except that it's an article with the id 123.
As Karateka pointed out at the time in his article, a problem in implementing friendlier URLs with virtual directories is that all paths in PostNuke are relative, ie relative to the site root folder where index.php is located, and fixing it then would have required extensive changes in the core. That is, a URL like /Example/view.html would result in the browser looking for all links relative to its present location, ie in the nonexistant subfolder called Example, and subsequently it would fail to find the linked stylesheets, images etc, and all links from the page would similarly fail.

Unfortunately this situation has not changed in the intervening years, but as PostNuke modules are becoming API-compliant, they reference the same system function to build their URLs, so fixing this function and other associated functions to use root-relative links(1) will fix all compliant module URLs. But that leaves all other links, like images, Javascript, and stylesheets. The move to templating with Xanthia (for themes) and pnRender (for modules) is also making it easier, since Xanthia templates use a Xanthia variable to reference the theme's image directory path. So fixing Xanthia and pnRender will fix most paths in Xanthia themes. The exception are stylesheet and Javascript link paths and any links in the theme header, for which new path variables need to be introduced, so some updating of Xanthia themes is required. This makes the transition period to PN 0.8 an ideal time to introduced these changes, since few Xanthia themes have been released so far, and core modules are only just being converted to pnRender.
I stopped work on ShortURLs some time ago (before pn0.75) on the advice that a core module was being developed; however I have seen no evidence of this to date, and there is no indication in the upcoming PN 0.76 or CVS that there is anything coming. I got curious a month or so ago, and was somewhat dismayed at what I found.

Since then no progress seems to have been made on PostNuke ShortURLs. In fact, the current Xanthia filter hack has regressed, becoming bloated with complex and wholly unnecessary Regular Expression rules, many badly written with duplication and a number of bugs, especially in the accompanying htaccess file, going from the 15 rules proposed by Karateka to a massive 89. So, I set out to try and fix it, but ended up revisiting the idea of a core implementation using virtual directories to more logically structure the URLs in a way that is not only Search-Engine Friendly, but more User-Friendly.

Along the way, I've also been sidetracked and made a direly-needed new themable tab system for the Administration area based on AlistApart.com's Sliding Doors technique and consequently overhauled most of the Admin templates and a few User templates too, partly out of necessity due to the new Adminpanel, partly because they badly needed it. Those of you who have tried the pn0.76 Release Candidates would know that the templated output in them leaves something to be desired, drab and somewhat unprofessional-looking due to all the styling and CSS-classes having been ripped out, leaving a basic grey and white look with overly large headings and no theme tables for backgrounds. Hardly what you would call of Release Candidate quality. So pnRender and its plugins have been fixed to allow the use of Xanthia-like theme-colour tags as well as a tag for root-relative paths needed for ShortURLs, and the opentable functions have been fixed so that proper themed borders can be used. In fact most of the changes are in fixed templates, plugins, and module files.

My proposed implementation still retain the Xanthia filter for backwards compatibility with older themes, modules and blocks, but has been wholly rewritten and pared down to 24 rules, including a rule to fix all links to be root-relative. As PostNuke is in transition to be fully pnAPI-compliant by PostNuke 0.8, the remaining ones can gradually be removed altogether as themes, modules and blocks are updated. There's also a version for AutoTheme.

This particular scheme is experimental and may be tweaked or improved upon. It seeks to reduce the reliance on the Regular Expression(2) post-processing for links and introduce more user-friendly URLs that have more relevance for people and search engines alike by using virtual directories to visually distinguish sections of the site by module and function, such as
/Example/View.html

and for the News articles introduce Category, Topic, and Title information in the link:
/Category/Topic/ArticleXXX-title-of-story.html

For instance for a news story in the category Computers and the topic Postnuke called "PostNuke Shorturls", you'd have the URL
/Computers/Postnuke/Article123-PostNuke-Shorturls.html

This is a clear, concise and informative link that tells the user and search engine alike something about the link before going there, while retaining backwards compatibility with links of the old ShortURL scheme. It more closely emulates the way we think and organise information, using the folder analogy where we have a clearly-labelled Computer category folder, under which we have the various sub-categories - Topics - with various articles. In this case, we're using a virtual file anchored by the word "Article", clearly identifying it as such, followed by the article number and title. There is backwards compatibility, so that older links for Article123.html will still work.

In this instance I've excluded the News keyword altogether for brevity in favour of the Category and Topic keywords which insinuate News anyway, though there is nothing against being consistent with all the other ShortURLs and having the Module appear first, as in
/News/Computers/Postnuke/Article123:-PostNuke-Shorturls.html

This is for the special case of the core News module though, a more generic method is needed overall for URLs with various unknown parameters passed in the query string. This implementation uses the scheme:
/Module/Function-Param1:Value1-Param2:Value2... -ParamN:ValueN.(p)htm(l)
where the Query string parameters are tagged onto the virtual filename grouped by colons and separated by hyphens, the idea being to use commonly-used characters we might normally use in a list to make it look as natural and readable as possible. It may be a less-commonly used character than the hyphen is needed, like the tilde ~ character, since some parameter values may use a hyphen, in particular usernames. This is not a problem if passed as the last parameter, where it may contain any character. So if the module developer kept this in mind, it might not be an issue. I'm not aware of it being one so far. The PostCalender ShortURL plugin deliberately places uname, if present, last.

The extension is not necessary, but used for convenience. The 3 types used are either one of html, htm, or phtml, the latter useful to distinguish when you want to link to real HTML files on the site. The extensions as well as the option to use ShortURLs or not is set in the Settings panel, though I've only offered the option of html and phtml, since frankly the MS DOS-holdover extension htm annoys me.
Older URLs are marked with a + before the Function name, as in
/PNphpBB2/+profile-mode:editprofile.html

so that the server can translate it correctly. If the directory doesn't actually exist, entering
/Example/

will redirect to the Example module main page (Apache only)
/Example/main.phtml

which in return gets rewritten invisibly to
/index.php?module=Example&func=main

Otherwise, if it does exist, the index file of the relevant directory will be opened.
Similarly, with
/HTML/filename.html

if the file exists, it will be opened, else PN will look for
/index.php?module=HTML&func=filename

It is still possible to tag on query strings like
/ModName/main.phtml?theme=seabreeze

or
/ModName/main-theme:seabreeze.phtml

will both be translated to
/index.php?module=ModName&func=main&theme=seabreeze

There are any number of possible ShortURL systems, the simplest being to simply chop the URL into virtual directories, like /News/123/ from the above News example as some do. Xaraya uses a variant of this for news, though it doesn't use mod_rewrite, so appears like
/index.php/news/123

Again, this is concise, but contains few meaningful keywords other than the module name News. You can combine the two methods for News and have
/News/Category/Topic/123/title-of-article

which works very well, but loses some of the elegance of the above philosophy, since the latter part breaks up the virtual file into 3 with no anchor words, which is not how we organise information.
For generic URLs, there are a number of methods; for instance Mambo, another CMS, use generic ShortURLs like
/component/option,com_newsfeeds/catid,5/Itemid,7/

for a News URL like
/index.php?option=com_newsfeeds&catid=5&Itemid=7

where the querystring values are grouped by commas and separated by forward slashes (virtual directories). It is a ShortURL, though in this case not shorter, and doesn't have any useful keywords, other than "newsfeed", and is not very human-readable. For a generic URL, this is somewhat unavoidable, but can be better than that.
This implementation also contain a way to customise ShortURLs on a per-module basis through a file called shorturls.php placed in the module folder (see the Example module), such as the News URLs, or 3rd party modules like PostCalendar, which instead of the full URL like
/index.php?module=PostCalendar&func=view&tplview=&viewtype=day&Date=20050405&pc_username=&pc_category=&pc_topic=&print=

with the above generic ShortURLs would be rendered as
/PostCalendar/view-viewtype:day-Date:20050405.html

but with customised URLs become
/Calendar/05-04-2005/day.html


The beauty is, though, once we've created the groundwork in the core of PostNuke, any implementation will be fairly easy.

1) Root-relative links: Links relative to the server site root (eg /nuke/filename.html), which stays static, as opposed to relative to the present file (eg filename.html).
2) Regular Expression (RegEx): A complex pattern-matching language that can look a bit like a mathematical formula, used in the Xanthia ShortURL filter at /modules/Xanthia/plugins/outputfilter.shorturls.php.


----------------------------------------------------------------
If this were Mambo, I'd charge you 80 Euros for all this (the price for SEF Advance), but because you're all such nice people (except that guy up the back, you know who you are :) ), I'll let you have it for free.

A PDF of the ReadMe included in the package, but with additional screenshots, is found here (570kb).

I've also written a more technical ReadMe on installing ShortURLs, included in the package under the docs folder, and also found here.

here's a test of the tab system using the Aqua theme. It also comes with an XP-styled theme and the default-CSS-based one. I hope you like it, because it took a lot of work to perfect.

OK, screenshots: Well, no point having screenshots of URLs, so here's some of the tab system and modified SeaBreeze and PostNukeBlue themes' Admin templates instead:

1. The main adminpanel in PostNukeBlue with the Aqua-themed tabs, hovering over the Settings panel.
2. Same as above, but with the Theme Override set under Modify Config and with a tabs.css stylesheets in the theme's style folder. The rounded corners are only visible in Mozilla/FireFox.
3. The Luna tab theme in SeaBreeze, hovering over the 3rd Party tab.
4. The Xanthia Admin tabs using Aqua tabs in PostNukeBlue, hovering on Theme Settings.


And finally, the downloads:
I started out fixing PN0.75, so there are 2 downloads: One for PN0.75, and one for PN0.76rc4. I'll update it once the PN0.76 final is released.
Please backup your site before installing these patches, since a lot of system files are replaced. The PostNuke 0.76rc4 ShortURL package is rather large, consisting of some 400 files in a 1Mb zip file. The PN0.75 package has some 170 files and is around 800kb. Most of the changes are drop-in changes that doesn't necessitate updating of modules, but there are some exceptions in the PN0.76 package, in particular the Settings and Polls modules, where you need to first go to the Module list, regenerate, and update. Specific patches for popular 3rd party templated modules like AutoTheme and PNphpBB2 are included, but only a limited number of 3rd party modules have been tested with this package. No changes are made to the database, but it is still a good idea to back that up as well. You have been warned.

PostNuke 0.75 ShortURL package (833kb)
PostNuke 0.76rc4 ShortURL package (1Mb)

Two of the updated core themes:
PostNukeBlue (249kb)
SeaBreeze (120kb)


Feel free to discuss this proposal in the forums.

Enjoy!


Martin Andersen 8/7/200

Generated on July 9, 2005.

Downloads on PostNuke.com Target of Hacker: Immediate Action Required if You've Downloaded PostNuke in the Past Three Days   (News)

a different server. Second, in one file there was code allowing a malicious user to execute any shell command on the web server.

As noted before, immediate action is required from everyone who downloaded the .zip package between Sunday (24.Oct) at 23:50 GMT until Tuesday (26.Oct) at 8:30 GMT.

Required Actions
1. Immediately remove the affected file /includes/pnAPI.php and replace it on your server with the original one (either from a fresh download or from http://cvs.postnuke.com/viewcvs.cgi/Historic_PostNuke_Library/postnuke-devel/html/includes/pnAPI.php?rev=1.86&content-type=text/vnd.viewcvs-markup)

2. Check the access-logs for any entry containing 'oops='. If you find any call please contact the PostNuke Security Team via http://forums.postnuke.com/index.php?module=vpContact providing the access log for further investigation.

3. Change your database details, username, password and if possible, database name.

Future Safety Precautions
In the future to avoid downloading tampered files please compare the MD5 checksums with an independent source to ensure legitimacy, such as http://www.post-nuke.net. For those unfamiliar with MD5 it is a check you can use to make sure the download has not been tampered with and can be trusted. In order to compute a checksum you need an MD5 utility and you can find a variety of tools (for windows) here: http://lists.gpick.com/pages/Checksum_Tools.htm and another favorite is the free and platform independent open source project jacksum (http://www.jonelo.de/java/jacksum/) You can also find more information about this topic on Wikipedia at http://en.wikipedia.org/wiki/Md5

Finally, be assured we are working to find the hacker and will take any and all legal action when they are found.

About PostNuke
PostNuke is a community, content, collaborative management system, a C3MS providing webmasters with a set of tools to build a dynamically generated web site within minutes of downloading the software. It's backed by a team of dedicated, talented developers, designers, and volunteers with years of experience.

General Info About PostNuke:
Modular Structure, Customized Functionality through Third-Party Modules, Advanced User Group Permissions System, Multi-language Support (Approximately 36 Language Packs Available), Embedded WYSIWYG HTML Editor Activated on Most Text Entry Areas, Site Search, Advanced API (Application Programming Interface), Focused on High Level of Security, Easy-to-Use Guided Browser Based Installation, Easily Change/Customize Your Site's Look/Feel Through Plug-in Themes, Provides advanced content management features while promoting collaboration, communication and community around the content.

A Short List of Available Modules
News Publishing, Content Management, RSS Feeds, Voting Booth/Polls, Banners Module, Comments Module- allows other modules, including

Generated on October 26, 2004.

Interview: Franky Chestnut, pnConcept.com   (News)

Hacks
dWl Mod Suite - This was for pn0.713, it was inspired from modifications that were done on the Downloads and Web Links modules at phpNuke. There is an All Page and that would be the only real important thing about this one. It was one of my first hacking I made. And to think of it, I still use the all page on my site [demo] but I think that is all that is left of the modifications. Also in this hack, I made it so there is a listbox with the title instead of just a field when you wanted to modify a link or a download. Little things like that. People should not use it today... all files comes from pn0.713.

pnMailUserHTMLHack - Another modification of the pn0.714 Mail User mod. All it did was to give the choice to send an email to a user in text or in html.

pncUserHack - None the least, this is my most popular work. It began with only the possibility to choose the password you want when registering and today, you can add dynamic fields, list, checkbox, define required fields, moderate registration and so on. Lots of options with the mail because for a time, the goal was to give admin the possibility to use PostNuke on hosting without mail function. But as users were asking more and more... it became what it is today.

pncUserHack was made with pn0.723 so I do not recommend it for newer version today. The future is unknown for this one, it depends on many things.

Blocks
Block Your_Avatar - My first block. It shows the avatar from your profile and a list box to change it directly on the block. Today, this one makes me laugh.

pncPaypalContribute - A pnAPI block that shows a Paypal button for donations. The email and currency can be choose in the administration for this block.

Mods
FeedBack- This was my first module and it still work although I think it was made for the pn0.6x or pn0.71x series. I took the Recommend_Us module and made it so it sends an email to the admin and it was my first experience. I saw later 2 or 3 modules that had the same name and we're doing the exact same thing. I thought it was funny but it was for everyone an easy way to start I guess.

pnUser_Points 0.22X - This one will disapear and I'll be glad because it never quite fully worked well. Not that it is a bad module but it doesn't work very well when your database becomes medium or large. The way it was written, it was using so much ressources that most of the time, the module couldn't update itself like it was supposed to do. What I did to put the 'x' after the 0.22 is that there was no administration in the original one. So you had to change the configuration directly in the files. And for me, I thought that it wasn't very..... actual. So I made the administration for the configuration and I added the possibility to clean the table where data was inserted. I also made the initialisation so people didn't had to insert the table by hands anymore.
I remember that I didn't want this one to go out with my name on it but since I didn't had any answer from the original authors when I finished it, I release it as it was. And people kept the association and came to me for the support and the future version.

Next version will make this one completly obsolete. 100% pnAPI, much less ressources, Groups points and Archives.

pncPopMessages - That one is a copy of the original Admin_Message but with a block include that would pop a message. I made a copy because I want to separate the original Admin messages from the messages that would pop.

pncGroups - I made this one because I didn't want to add manually users that would help us on PostNuke-France.org on various things. Documentation, support or even administrate a part of the site. So the module is giving the hability to the users to register for a group with all the permission fuss. You also can make a group open or close, define how many users can register for a particular group and so on. 2 blocks were included, one to show groups information and the other, the list of users in a particular group.

pncSimpleStats and pncSimpleStats Xantia - These are my last ones. While working on the pncUserPoints and discovering that ressources may not be a problem like the old User_Points was, I made this little Stats module with some some functions that were for the pncUP. For each category (news, comments, reviews and xforum), it shows a page with the list of users and the amount they proposed or wrote. No database, always getting the most recent count.
The Xantia version was my way of practicing with the new pnRender Engine and to give the result to the users. It is templated.

Upcoming
pncPaypalMod - Just my personal Paypal mod that won't do a zillion thing. The pncPaypalContribute will be moved to this mod. The goal is to make a simple mod that will show the list of contributors but won't have many functionality. I know there is probably 10 out there but I'm a programmer and I like to create my own. I just want something basic. I have a working version under a desk somewhere but never had the time to finish it. And.......... it will be free ;-) (No pun intended ha ha ha !)

All other upcoming mods are reactualisation, pnAPIsation and for some, templated of the existing ones : pncUserPoints, pncGroups, pncPopMessages, etc...

I also made the decision to concentrate on simple modules whatever they will be. I want them easy and fast to create and give them to the community so they can learn with various examples. And since we are near a new era (brrr) with the Xantia and pnRender engine coming, all will be templated for the occasion like the pncSimpleStats.

Voilà ! That is about what I've done and probably worth mentioning...


Where do you live?

I live in Paris - France, but was born in Canada.

What is your real-life job?

I work as a technicien and programmer on a professional software for music publishers. Mostly done in MS Access.

Tell me about your postnuke "career".

I'm not quite sure when I started but I'm a survivor of phpNuke. At first, I didn't like PostNuke (0.60 I think) and went back to phpNuke. But later, I felt that it wasn't serious. If I remember correctly, the only reason was the huge modules pool that was available for phpNuke then. But after a time, when you see that you will only use 1% of what is available, you take a peek behind other doors. And I came back to PostNuke (0.62) to make more tests. And got hooked.

As I wasn't very up-to-date about 'collaborative' programming, I was curious to discover how it was done. I made lots of tests with other CMS but was constantly driven back to PostNuke for various reasons or even to take a break. Then I got tired of testing and it was a natural decision to stick with PostNuke. The code under the hood had more common points with what I was exploring than the others.

With time, I was getting better at answering technical question and had a big presence in the french community. So David from Boomtchak ask me to co-administrate. When Boom went down for a time, another french support site went up and I was there again (Kaintech). I even been asked on Envolution-france but I didn't stayed long. Then the administrator of PostNuke-France ask me to take the lead because he couldn't stay, I took the opportunity and I'm there since then.

So I guess that for the french community, I'm known for the administrator hat, and for the rest of the world, for the lines I wrote.

When did you start working on your own module?

It was soon after deciding that PostNuke was the CMS I would stay with. Since I'm an self made programmer as that I didn't know much about php, I started by modifying already existing modules. That is how the UserHack was born. All it was doing at the time was giving the hability to users to choose their own password when registering. After that, I did various hack on the Downloads, the Web Links and when I gained confidence, I added an admin interface to the User Points mod and my first module was a FeedBack module. (Although many people made the same one, I didn't know at that time).

What is your development like?

I'm the "cliché" I guess, I work alone and like to be alone in the dark with a bottle of wine, my cigarette, and far away, the tv on. Yes, late at night when the bottle is empty, there are consequences on the coding. I won't say that it is the reason of course, but I try to make every line of code readable. Much needed at the end of the night. In fact, I think I put more time on how the code looks than how it looks when it is rendered. He he !

I like to consider myself the one that sometimes touches the soft spot of people. This is without being pretentious of course. I don't do very big things, I'm not the great programmer and my background may be slightly light, but the small things I do, people have been waiting for them. Like the first UserHack. When people were eager to have the possibility to choose their password at registration, I did it. When others or myself wanted an admin for the User Points, I did it also. And so on... I think that is mostly how I made my name.

I also rarely do something that I won't use myself. So many things I did were things that I wanted for myself in the first place. By chance, others were thinking the same.

The only tool that I consider worth mentioning is my code editor (if I can name it) : Crimson Editor (http://www.crimsoneditor.com), great syntax highlight, no crappy tabulations since the editor changes them in spaces and makes files readable the same way for everyone. I can't bare it anymore to read some code from others and taking half an hour only to make it clearer to read so I can understand it and fix or make modifications if needed. That is why I take my time to make my code so everyone on any computer sees the same thing.
You can also change code in files directly on your host with the ftp functionality. Perfect for newbies. Pros will probably move on to something that suits them more.

What is the biggest difficulty in your development?

I saw someone write "Time"... and that would be the same for me. It is not a PostNuke related problem since I am probably part of the rare ones to be happy that PostNuke is slow in development. I work hard in my professional job and I rarely sleep more than 3 or 4 hours a night so I'm very slow on creating any new things for PostNuke. People will say I never quite meet deadlines I propose and it's true (PostNuke related of course).

What features should the Postnuke .8 core have to simplify your work?

Good documentation and clear examples for newbies, intermediates and advanced users and developpers. I learned everytheverything from what others did and I'm still and will always be in a learning mode. The Example mod is a great start but when I have wanted to do something just a step more complicated, It has taken me awhile to find out how to do it. I have searched the smarty doc, and the Xantia code for a long time just to do something a little more complicated than what the Example mod was doing.

Which route will Postnuke/your module in your opinion go in the future?

I will follow its evolution and I have already started doing so. As I stated, I have already made a pnRender enabled module with the pncSimpleStats for practice and also to give another example for others and... I'm not sure but I think it may be the first non-official module done that way. And I intend to make more mods that are simple so people can have a look at them and say : "oooh, that I understand !".

What should users of your module regard?

I guess that one of my strong point is evolving with what the users want or doing the little thing that users were waiting for. When I look at my pncUserHack, between the first and the last ones, there are so much differences, it is freaky... but it is all what the users wanted at that time.

My weakest point would be the time I take to make something but that it is not something I have control over...

Anything else you always wanted to say about Postnuke/your module?

I know that there are developers like me hiding or keeping a low profile. I, myself, am often trying to keep a low profile because whenever I do something, it is always a great battle for me to support what I do because of time constraints. That is why I don't do much publicity. But I do my best to gain confidence about what I do and I hope to be able in the future to give more time to PostNuke, helping or coding. I hope that open minded developers that do have the time will get out of the dark and share their knowledge, skills and talent and contribute more to the development, documentation, support, etc.

Actual pnDevs are really, really great... but to give them a chance so they don't loose their mind, giving them a hand would be great.

Thank you very much for you time.

My pleasure ! And hoping my english wasn't too bad ! ;-)

Franky’s Homepage:

Generated on February 10, 2004.

Interview: Shawn McKenzie   (News)

What module(s) are you working on?

AutoTheme
AutoTheme is a revolutionary multi-platform HTML Theme System for eNvolution, PHP-Nuke, PostNuke and MD-Pro CMSs. The current theme systems requires you to be somewhat familiar with PHP and the CMS architecture. If you are not very familiar with PHP and/or the CMS inner-workings, AutoTheme removes this complexity. It is not only simple, it is powerful. Much more control and many more customization options are possible with AutoTheme than are possible with the current theme code.

AutoTheme's primary benefit is providing users the ability to create themes in HTML using their favorite editor, with no use of PHP. In addition, AutoTheme provides easy customization of every part of your site including: block display, custom templates for the Home Page, User Pages and Admin Pages and individual modules, as well as, templating of blocks and control over when and where each block is displayed. The addition of AutoBlocks provides unlimited locations for your blocks. All AutoTheme settings are easily configured from a graphical administration interface that is integrated into the supported CMSs.

AutoTheme is packaged as a module and comes in two flavors: the feature packed, fully administration driven, commercial version and the free GPL AT-Lite. The commercial version (currently AutoTheme 1.7) provides template compiling and caching, an Extras (plugins) and Extra commands architecture for easily extending AutoTheme, as well as other premium features.

AT-Lite
AT-Lite (currently .7) is the free GPL version of AutoTheme described above.

PostWrap
PostWrap is a PostNuke module (also works with eNvolution and MD-Pro) that enables virtually any web content such as html, scripts (home pages, galleries, shopping carts, PHP, Perl, ASP, etc...) to be easily incorporated into your PostNuke site. Just call the PostWrap module with any URL and it will display it in the PostNuke main content area. I call it a content wrapper (takes any existing content anywhere and wraps your PostNuke site around it. Uses an which must be supported by the browser and JavaScript to resize the (optional). PostWrap works well with static HTML pages, but the main benefit is the
ability to incorporate scripts and full-blown web applications into your
site.

PostJump
PostJump is a quick and dirty PostNuke module (also works with eNvolution and MD-Pro) used to redirect to a URL. Why in the hell do you need to do this in PostNuke? The main use is in setting a module as your start page and being able to pass it variables (example: PostWrap). Under PostNuke Administration, Settings, you can set your Start Page (The module, index.php is pointing to), but the modules are in a dropdown box and that doesn't allow variables to be passed to the module.

Why do you prefer Postnuke over other CMS?

PostNuke seems to be more solid and professional than comparable systems with a more professional API, and it does everything that I need for now. Community is very important as well, and the PN community is awesome!

When did you start working on your own module?

I started building the first version of PostWrap a little over one year ago. Sometime in August of 2002. When I first wanted to build a family website, I started with phpWebSite and moved to PostNuke after evaluating the major Open Source CMSs.

What is your development like? Do other people help you? How do you work together? How big is the impact of the community on your development?

The community is everything to my development! Other than the first version of PostWrap, everything that I have written has been in response to what I see in the forums. Posters need this, they need that, how can I do this, etc. As far as other people, after I first released PostWrap, Yassen Yotov (a.k.a CyberOto) offered to help and do the coding to add administration. He did a great job!

Are you asking for help with coding? Documentation?

No coding help is needed at this time, however, I would welcome anyone wishing to help with documentation or tutorials for any of the modules.

What is the biggest difficulty in your development?

Of course the age old complaint of documentation, but that doesn't slow me down much anymore as you can learn as you go. My biggest difficulty is my real job ;-) and myself. I tend to keep going and going and add this and that as it occurs to me.

What features should the Postnuke .8 core have to simplify your work?

I actually haven't given that much thought. I'm sure something will come to me next time I start off to write a new module :-) I really enjoy coding and working through issues and banging my head against the monitor. If it were too simple it wouldn't be much fun.

Which route will Postnuke/your module in your opinion go in the future?

Hmmm... I'm not quite sure how to answer that, but they will both definitely go the successful route. PostNuke is a strong platform and continues to get better. The modules that I write that are beneficial and are a compliment to or enhance the value of PostNuke will always be a priority for me, and I'll ensure that they are successful.

What is the strongest point in your module?

For AutoTheme, I feel that the strongest point is that it is a drastic improvement to theme design and provides all users with the power and simplicity to design their own beautifully unique themes.

What is the weakest point in your module?

I'm sure documentation would be the weak point.

Anything else you always wanted to say about Postnuke/your module?

Read about the modules, see demos, get support and downloads at: http://spidean.mckenzies.net

Generated on October 2, 2003.

Remembering Lest We Forget   (News)

Related Sites

September 11 Archive
Witness and Response: September 11 Acquisitions at the Library of Congress
September 11 Bearing Witness to History: National Museum of American History
Smithsonian American History Museum: Newspaper and Magazine Headlines
Library of Congress: Today in History
Columbia's Official Government Records
Virtual Reality Tour of World Trade Center
The WTC Memorial Site
The World Trade Center's Rescue Dogs

Global Sites - Something To Think About

Watch Fareed Zakaria discuss his latest book, The Future of Freedom: Illiberal Democracy at Home and Abroad
Global Issues
Global Terrorism
Veterans for Peace

You can also download a free PostNuke theme dedicated to the Memory of the Victims of September 11th - Download Here

Generated on September 11, 2003.

Page 1 / 3 (1 - 10 of 27 Total)