PostNuke

Site search

Search results

Number of hits: 25

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.

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.

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.

Introducing: Scribite!   (News)

the project. Sven Schomaker (hilope) was already working on an module that made the Xinha editor available for PostNuke modules.

"Scribite!" now includes Xinha and TinyMCE and can relatively easy be expanded with more Editors so you can test them all and choose the one that best fits your editors needs.

But can not only use the WYSIWYG-editor in most common modules there is also a nice administration that makes it easy to use all the available plugins, to change the editor's language and most of all choose between several functional layouts. Most editor donot need to be able to change the color or the font of their texts. In this case you can use the reduced feature layout and offer only the basic functions.

Sven Schomaker received the 500€ last year before Christmas right in time for the birth of his first child. And yet it still is one of the most active projects in the NOC.

Links:

Download
Hilope's Paramedics Portal (It's UTF-8!!)

Generated on March 2, 2007.

0.8 Development Continuted...   (News)

New Blocks Module
The new blocks module designed to work with the recoded Themes engine has been committed to CVS. This new module, while fully working will probably undergo some enhancement before the release of .8 MS1 with use of the new Ajax library a priority. All block management is now fully integrated with the Blocks module, from block position tags to assigning blocks to block positions. Despite these new additions, the block management interface remains fairly simple and intuitive, improving usability over the .7x block control system.

PostNuke Ajax Framework
Also newly committed in the past few days is the PostNuke Ajax framework. This framework is already in use within the Permissions module as a demonstration of what can be achieved. PostNuke's Ajax implementation is based around the prototype.js script and script.aculo.us libraries, which as well as providing nice visual effects are fairly easy to implement for the module developer. This framework was made possible in .8 through core changes to the pnInit() function, which can now be passed a parameter determining what parts of the core should be loaded. In the case of an Ajax framework it is important to limit the initialisation process to an absolute minimum of components for performance reasons. Again, with this in mind each module that wishes to use Ajax functionality should use a new Ajax entry point 'pnajax.php' in their modules. This reduces the number and size of files that are loaded with each Ajax call, but does not prevent you from calling other functions in your module should you require them.

Full documentation on how to use the Ajax Framework should be available with the final .8 release, however in the meantime developers are invited to update their CVS copies and look at what has been achieved so far.

Permissions Module Ajax Enhancements
For some time now, the Permissions module interface has been far from ideal, especially on sites where you have large numbers of permissions. In this situation, the PostNuke Ajax library can be put to very good use, as demonstrated by the demonstration currently in CVS. It is now possible to order permissions through a 'drag and drop' interface, create new permission rules, and also test any permission you have written through an easy to use interface all without reloading the page. Furthermore, you can filter permissions by group for an easy review of a single group's access rights on your website.

We anticipate that the Ajax libary can have many more uses across the codebase for .8, and over time these will be implemented. PostNuke now has a solid Ajax framework upon which third party developers can begin to develop their own Ajax-based modules for use with .8.

Use of pn-clearfix Class in Module Templates
For the new Ajax tableless module administration layouts to work correctly in tableless themes (such as the andreas08 theme in CVS) use has been made of a pn-clearfix class. This has been adapted from positioniseverything. While these changes were prompted by the introduction of Ajax sorting to lists in CVS, the class can be applied in any relevant situation.

Module Dependencies System
With the increasing use of hooks modules across the codebase with the advent of complete API compliance, it was necessary to introduce a dependencies system to PostNuke .8. This system allows modules that support or require particular hooks a way of informing the user of this requirement. In PostNuke .8, the core system will inform site administrators if they are lacking a module which can add functionality to their site. Additionally, the system prevents conflicting modules being installed together. It is up to module authors to set module dependencies in their pnversion.php file, stating a minimum and/or a maximum version required. An example of this is in CVS, in the form of the pnCategories pnversion.php file. When the .8 MS1 release is available, module authors are encouraged to look at this system and use it to their advantage when creating modules in the future.

New Password Hash Methods
Through the .8 PostNuke User's module it is now possible to choose the hash method in use on your site. The addition of both SHA-1 and SHA-256 encryption can add security in sensitive environments, and additionally the ability to change hash method can help when integrating PostNuke with other applications. The hash method changes have been implemented in such a way as to ensure you can change hash method at any point, you are not tied to a particular hash method at installation time.

Session Security Enhancements
More security options for sessions in PostNuke .8 are now available. You can now choose whether to sign cookies sent by your website, decide how long forms on your website should be valid for (through the authkey timeout) and finally enable IP checks to ensure session IP addresses do not change mid-session, which can occur if multiple people use the same account. PostNuke also now supports the setting of a secure host name for HTTPS, if your site does not support HTTPS through its normal domain name.

Site Disable Functionality
When disabling your site in .7x it was important to remember to stay logged in, or you would be locked out of your site with the PostNuke Swiss Army Knife as your only way back in. In .8 this changes, now an admin logon form is available on the site disabled screen to allow you to get back in to a disabled site.

In Closing...
At this stage, many of the key features of .8 are nearing completion, and we remain on track for our target Milestone 1 release window of the third week of April. Third party developers are especially encouraged to use this release to test their code for compatibility with .8, as due to the core changes some modules will need updating. Meanwhile, if you are interested in seeing the latest state of the .8 codebase before the Milestone release you are welcome to download the latest CVS snapshot.

Generated on April 5, 2006.

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

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

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

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

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


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

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

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

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

Generated on November 3, 2005.

PostNuke 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.

Case Study - www.eurojamlive.org   (News)

So, how does eurojamLIVE! fit in?
eurojamLIVE! has been designed to allow participants and event organisers to communicate before, during and after the event.
There will be 10,000 people at the event, so the website has the potential to receive a great deal of traffic over the coming months.
eurojamlive.org as a PostNuke website
PostNuke was chosen for the eurojamLIVE! website. We needed a solution that could be deployed quickly, with only a limited amount of
modifications. The websites for Scouting 2007 are run on an entirely volunteer basis, and PostNuke's ease of use and open source code
was ideal for this.
Constructing the website
The website initially began as a standard PostNuke install. All the extra core modules that were not needed were removed, and the
tables for each of these modules manually removed from the database. The decision was made to use pagesetter
for most of the content, including the news functionality. We needed the workflow and template functionality provided by pagesetter
but not available in the core News module. Additionally, PNphpBB2 was used for the forums, due to its extended feature set.
In the end, the site's configuration looked like this:
PostNuke Version: 0.760
Although at the time 0.760 was still in the RC stage, it was considered important to use the latest version to take advantage of
sessionless anonymous users (for a performance increase) and also recent improvements in Xanthia's full page caching, which in the end
proved important for the website.
Module List

pagesetter
photoshare
EZComments
PNphpBB2
Downloads
pnFlashGames
Weather

Blocks

dp-StaffStatus

Theme

pnfr-vx - courtesy of Chestnut, pnFrance

Custom Developments
Although nothing revolutionary was needed, a few custom developments were used.
Block Management
A fairly simple module making it easier to change the news stories appearing on the homepage. Instead of the default pagesetter block,
which requires the story ID, this module allows the user to choose the story title to show, rather than having to know the ID.
Profile integration - PNphpBB and PostNuke
Better integration between PostNuke's profiles and PNphpBB profiles were needed. As a result, all the forum profile settings were
moved to a link in the 'Your Account' section, the profile link in the forums now redirecting to user.php. One further change was
needed for everything to work as expected - the profile information had to be updated each time the user visited the forum index,
incase they had changed any part of their profile.
The First Day
Although the site was launched on the 3rd of June, it's existance was not advertised until the 5th June
at 2pm. Between this point, and 9pm, the site received 55,000 hits and served almost 1GB of traffic. This level of initial
support was not initially anticipated, and there was a slowdown for a few minutes until Xanthia's full page caching was enabled.
This had the effect of reducing server load by more than 50%, and the site consequently confortably rode through the initial spike in traffic.
The server itself already ran the Scouting 2007 network of sites, before the eurojamLIVE! launch. In an ideal world the eurojamLIVE!
website would be on its own seperate server, however this is not the case, and therefore performance in paramount. In the end,
I would say the server and the PostNuke website stood up to the demands quite well.

Visit eurojamLIVE!

Generated on June 14, 2005.

The pnCommunity Code of Conduct - A reminder   (News)

POSTNUKE COMMUNITY CODE OF CONDUCT


PREAMBLE
Your commitment to this Code of Conduct in all Community areas, which shall apply to all forums, chat areas, comments, mailing lists and/or other message or communication facilities designed to enable you to communicate with the Postnuke community (collectively, "the Community"), ensures a positive experience for all our users.

Postnuke, postnuke.com, The Postnuke Project and the Postnuke staff (hereafter referred to collectively or singularly as "Postnuke" or "PN") are not responsible for the content or activities of users in any such Community area.

RESPECTING OTHER USERS
Members of the PN Community shall be obliged to treat each other with mutual respect. Using the Community to threaten, harass, stalk, or abuse other members or PN developers or staff participating in any Community area will not be tolerated.

PN will not tolerate disruptive activity, such as persistent off-topic comments and postings or statements that incite others to violate this Code of Conduct or participate in activities that are not conducive to the well being of the Community as a whole. Registered users must certify that they are over the age of 13, and are expected to act accordingly. This Community is a vibrant and positive place. We'd like to keep it that way.

The PN Community is a place where developers and users can collaborate, integrate and participate in the design and progress of Postnuke and support each other in furtherance of same. PN is not a forum to air your political views. Comments that derogate another member or group with regard to race, gender, religion, age, national origin, sexual orientation, disability or socio-economic background shall be considered a de facto violation of this Code of Conduct and will be dealt with accordingly.

The PN staff will delete posts and comments that do not comply with this Code of Conduct. Repeated violations may result in further action, up to and including banning users from the Community.

NO SPAM
Please don't spam the Community. Spamming includes sending identical and/or irrelevant submissions to many different forums or mailing lists. Usually such postings have nothing to do with the particular topic of the group or are of no real interest to those on the mailing list or forum.

PN reserves the right to take such action as PN sees fit up to and including removing offensive messages and/or banning a user at any time, with or without notice, from any or all Community areas for spamming.

The Community areas may be used to provide supplemental information regarding your own business (provided that you do not use spam to provide this information); however, the Community areas are not designed to be used as the primary mechanism for operating your business or providing core information about your business. Any use of the Community areas for commercial purposes is solely at your own risk and PN has no liability for such use.
The preceding shall not be construed to prohibit or discourage members from posting links to their own websites where commercial services may or may not be offered. Building web sites is, after all, what PN is about.

ENCOURAGE, DON'T ABUSE
PN's core developers spend countless hours to provide you with a robust content management system. They are not paid for their work. Many of our module, block and theme developers also offer their hard work to the Postnuke Community with no expectation of any compensation other than the satisfaction of creating something that will be enjoyed and utilized by PN users worldwide. Likewise, many of them are not paid for their work. They do not owe you anything, however when you choose to use Postnuke or the modules, blocks and themes that are offered for free to you, you do owe the developers, at a bare minimum, respect for the time and effort that they have spent. Abuse or harassment of developers regarding their efforts or their release timelines will not be tolerated.

YOU ARE RESPONSIBLE
You are responsible and liable for all of your activities while participating in the Community areas.

PN reserves the right to remove at any time, with or without notice, any posting that violates this Code of Conduct.

You are responsible for any actions you may take based on advice or information you receive online. Use your own good judgment when evaluating information provided through any Community area; remember that the information provided could be from people of any age and experience level. The decision to conduct transactions with anyone is your own and you should conduct your own research prior to making any decisions.

UPHOLD THE CODE
In helping to make the Community a great place to meet, collaborate, support and share, you must do your part to uphold this Code of Conduct.

PN reserves the right to immediately terminate or suspend access to any Community area for violations of our Code of Conduct, or at the staff's discretion to deal with situations or behaviors that do not comply with the spirit of this Code of Conduct, although such situations or behavior may not be addressed specifically herein.

PN also reserves the right to amend or change the Code of Conduct at any time with or without notice. You agree to periodically review this document to ensure you are doing your part.

Generated on March 11, 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.

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