PostNuke

Site search

Search results

Number of hits: 35

A Call For Volunteers   (News)

Layout and User Interface Team
Now PostNuke is nearing the final release of 0.8, we're beginning to look beyond towards the future development, both of .8 and .9. In that future, we'd like PostNuke to look better, be easier to use and to really stand out among all the competing systems out there. And all that while remaining standards compliant and accessible! We need a team of skilled people to take PostNuke to the next level. We're looking for those skilled in HTML, CSS, Photoshop and image design, Ajax (specifically prototype and PostNuke's Ajax framework), PostNuke's theme engine and those with a knowledge of standards and Section 508. Does any one of that list sound like you? If so, please contact us as soon as possible for more information!

ValueAddon Development
We're still looking for willing developers to take over development of all the old ValueAddons in SVN (see the PostNuke-devel/modules directory for a full list). The more modules from this selection that are adopted by third party developers the better - the core team can concentrate on faster and better releases of the core, moving us to .9 quicker. All the modules in SVN are .8 ready, they just need a little attention and new features adding. Please get in touch if you can adopt a ValueAddon.

Support
This is something every single PostNuke user can contribute to. We're always looking for help in the forums, answering questions and helping users both experienced and just getting started. The PostNuke community is a friendly place, so why not show that to those who join us by answering any questions they may have? Even better, if you could transfer whatever you write a detailed page in the PostNuke Wiki you'd benefit the whole community.

Marketing and Publicity
Following .8 we're planning a marketing campaign to show the world just how good PostNuke is. If you have contacts in the web development industry, are able to publicise PostNuke to clients, coworkers or write a series of articles for a magazine then you can contribute here! We're looking to form a team entirely focused on this goal, so please contact us if you can help out.


Of course, if there's nothing in the list above which appeals to you we can always find a use for a willing volunteer. If you

Generated on January 4, 2008.

News from "Behind the Scenes"   (News)

Rebranding
The new name and the logo have been chosen, now the lawyers have to do their work in claiming the necessary trademarks. This is more important for Europe as it is for the US. but we will get the trademark worldwide to avoid any future problems. But, as usual, the administrative mills are working slowly, so this needs some more time. As soon as this process has been finished we will decide about announcing the new name, either immediately or together with the final release of .8 (which will in this case be renamed to $newname 1.0).

EasyDist and the extension database
Axel and Simon have written a concept paper of how to connect the EasyDist module (see [url]http://modulestudio.de[/url]) to the extension database on this site. Necessary changes on both sides are identified and will be done in the next weeks. The plan is to have this working together with the release of $newname 1.0. Among other things EasyDist will be enabled to get the latest module or theme information from the database to create up-to-date packages whenever a new version of a module or theme has been released, an admin interaction will not be required.

Release Manager
Although the EasyDist module will become a very powerful tool we still have to supply the usual download packages. For this we need someone to create, validate, upload etc. those packages. In the future this task will be done by Patrick Cornelissen (patrick.c). He will also maintain the SVN module that is internally used on this site to create the daily snapshots for the core and selected modules. Thanks to Patrick for accepting this task.

New Subdomains on postnuke.com
Postnuke.com will get two new subdomains:
- devs.postnuke.com for devs and team members to post tips, news, information etc. This is the official replacement for the old pndevs.com site. Moving this site to a postnuke.com subdomain was planned from the very beginning.
- demo.postnuke.com will be a demo installation of .8 with working admin part, including some selected modules (not yet defined). This will be almost the same as http://pn8.pn-cms.de where the database is rebuilt from a backup every night via a cron job or manually throughout the day if needed.
Both sites will be installed and maintained by Philipp Niethammer (philipp.ni) and Gabriel Freinbichler (gf).

Documentation
We know that .8 is lacking a real documentation and we want to change this. Therefore a group of interested users will be built until beginning of November to take over this part. The Steering Committee will then decide about the project leader for this and ask him or her to work on a proposal for a manual, online help, and wiki structure which should all fit together (this also includes the tools needed to do the job) until mid of December latest (earlier if possible). When this has been accepted, we will talk about an exact time frame for finally writing the docs. Here everyones input is appreciated of course!
The project leader will have to submit a regular report about the proceedings to the SC.

Bug fixing weekend
As already announced in [url]http://community.postnuke.com/Article2862.htm[/url] the bug fixing weekend will start on Saturday, 6th. Mark and Robert also want to join us (virtually) to squish out some nasty bugs, Roberts main target will be the categories module.
Interested users can also join us using Skype. If you are interested, please send me your screen name via mail or private message so that we can invite you.


As you can see, the project is active although some might have thought the opposite. We delegated or will delegate some tasks to users who are able and ready to contribute to PostNuke. If you also want to participate, please contact us, there is always something YOU can do.

If you think you have something that is worth to be spoken about in the next chats, please tell us.

Generated on October 5, 2007.

Module Developers: Moving towards .8   (News)

Value_Addons is an example for all major new techniques being used. Most of all the use of the categories can be studied there.

And there are also the first 3rd party developers who started to work with .8 code:


Multihook - The SVN version of Frank Schummertz's Multihook will be 5.0 and is already .8 only. (NOC: Multihook)

pnUpper - Axel Guckelsberger made the upload hook-module far more flexible now and he completely rewrote it for .8 (NOC: pnUpper)

Publish! - Is one of the first modules solely written for .8. There is no release yet, but the SVN version basically works with MS3. Patrick Cornelissen plans to integrate a revision system before the first release. (NOC: Publish!)

If you are also already programming for .8 I would love to read something about it in the comments here or in your own articles.

Generated on March 3, 2007.

Development Update, October 2006-04   (News)

PostNuke and the aim regarding ValueAddons
There have been a lot of discussion about what release structure there will be in any future versions of PostNuke. Let us clarify this a bit.
As soon as the core codebase of PostNuke .8 is stable, it will be released as a core application framework, from which advanced users can create their own custom module set. Also available will be a package containing basic content modules, a simple page manager (Pages) and an News article manager.
Eventually, the aim is to build different distributions for different purposes. A good example of a (very very) extended .76x package is the current OpenStar distribution.
At this moment, there exist a few modules in the ValueAddons repository that have third party equivalents with improvements and better functionality than the historic ones. And even more important, these module developers have taken good thought about importing historic data from the original modules, so this does not mean you lose any when deciding to switch to an other module. Some examples are Downloads 2.0 to replace Downloads, MultiHook to replace AutoLinks, pnMessages to replace Messages and Advanced_Polls to replace Polls.
Maintenance of the 'old' ValueAddons modules is a lot of extra work for the core development team, which will not only delay any future releases of the core framework, but also increases the timeframe for functionality and feature improvements in these modules. So, the less there is to maintain for the core development team, the better they can work on security, stability and finetuning the core framework codebase.
We to make clear that adoption of old-style modules is encouraged! Please remember that there do not (and will not) exist 'official' ValueAddons modules. While we'd urge all third party developers to maintain high standards in their code (pnAPI compliancy, using hooks for better integration of existing functionality), this can't be enforced.

Secunia's vulnerability advisory on the core Downloads module
Secunia anounced a flaw which has status 'less critical'. The ability to exploit this flaw is limited, since it can only be exploited by administrative users: specifically, you need admin permissions to the downloads module . A new release for the 0.7x codebase is planned for next week, together with some other bug fixes. People who want to patch earlier can download modules/Downloads/admin.php from the SubVersion repository and replace their existing file.

Legal module
The German PostNuke community has hired a lawyer to update the German terms of use, because translations into foreign languages of the original legal module only work on a linguistic basis (and if at all they only apply to US-American laws). In some countries, maybe it is even better to not at all use the legals module, than to apply one that doesn't fit your country's laws. Every user should keep this in mind when using or activating this module for his / her site.

Sneak preview: Wendell's Admin theme
Wendell is currently working on a design for the PN Admin area. This is a first setup to make the administration interface much more user friendly and productive.

Code update for .8 Installation
Do you have a personal_config.php included in your installation of .8? That could be the reason for an MS2 installation problem. If you are having problems installing, try removing this file. Furthermore, lots of enhancements have been made to the installer routine. One can test it by pulling the latest nightly builds.

System Changes / Updates
In the Settings module, a link to the w3school page on each allowable HTML tag has been added to inform a user about the available tags.
The Modules module now shows a (more logical) indicator of a module's status: not initialised is red; installed but inactive is yellow; installed and good to go is green.
In the pnRender plugins, some additions and changes have been committed: The pnbutton plugin now utilises the button tag, and a suitable style for the button tag was added. On can add parameters like id, class, name and value. Furthermore, the date input validation was refactured, moving the parser into the DateUtil class. All pnForm* plugins have been reviewed and optimized by Jörn.
More information on the PostNuke Forms Framework can be found in the Wiki.

Miscellanious updates
Within the complete codebase, all occurences of extract($args) will be (or already have been) removed and replaced it with $args['myvar']. The reason for this change is that you should not use variables that are not expected within the function. We encourage module developers to not use extract also.
Error handling and Status reporting has been improved to also display module, file and line information depending on permission l

Generated on October 10, 2006.

Development Update, September 2006-03   (News)

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

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

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

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

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

Generated on September 28, 2006.

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.

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.

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

Generated on March 11, 2004.

phpMyadmin Version 2.6.2 Release Candidate 2: many enhancements and Bugfixes   (News)

Features of v2.5.6 RC 2: (here the Changelog):


-General code optimization by removing old PHP3-compatibility
-Make default functions configurable
-Visual scratchboard: show column names
-Show overhead in table list, allow to check all overheaded tables at once
-Export: can suppress dates information
-MySQL error messages improved formatting
-Printview: display linked values and other relational features
-Export: allow delayed INSERTs, and support for UPDATE and REPLACE statements
-Show result of last SHOW query when using multiple queries

a Online-Demo

Generated on February 22, 2004.

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