PostNuke

Site search

Search results

Number of hits: 15

PNphpBB2 Vulnerability   (News)

Generated on July 29, 2007.

Development Update, September 2006-02   (News)

Design Team
In the past we've discussed the option of having an official 'design team' to work on the core templates and themes. The aim for this team is to enhance usability and aesthetics of the core PostNuke distribution, add further template improvements, write a dedicated admin theme and maybe write an official styleguide for module developers. This idea has been brought up again and the search for members for this team has been started.
Changing the Module names
A mechanism has been added to allow module developers to rename their modules while retaining the existing module id. Before, the modules db had to be handled manually and documentation covering how to rename the module had to be written. Or users had to backup data and then remove the old module and add the new one. In short: "Who wants to do this?"
So you can now add your old modulename to an oldnames-array in pnversion.php and the modules module will detect the relationship between the two modulenames, updating the database accordingly.
The rationale for looking at this now is that there exist a few modules that have misleading or confusing names. Also, the development team would like to encourage module developers to drop the pn prefix for modules. An exception for this are the modules that also exist as a stand alones, like pnWikka, pnMantis, PNphpBB2, ...
For renaming of tables, the a module author can raise the version number and write the appropriate "copy code" for his tables.
Icon sets
The aim of the pnicon plugin is to have multiple icon sets in the future without worrying about image filenames like when using the pnimg plugin. The pnicon loads the icon set config.php file, and selects the filename of the image by a 'type' parameter passed to the plugin.
Comment Spam
In the last couple of weeks, many posts have appeared on the community forums about spammers that login and post comments with their credentials obtained from the user registration mail. To prevent this, a check has been added for the useragent during registration at the User and NewUser module, which is an additional protection against spam-accounts by PERL agents like lwp and libwww. Of course, this is not a guarantee that these kind of registrations do not happen ever again, but it should at least help to prevent it.
Also (but still in test phase), optionally a question can be added to the registration process (comparable with the anti-spam option in formicula 1.0). This Q/A combination is freely configurable in the user administration.
For more information, discussion and Proof of Concept, please visit the forum.
System updates
The Profile module has now enhanced client-side (using prototype-driven validate.js) and server-side (to show messages on the same page) input validation.
The Extended Menu Block supports sorting via drag&drop (using scritaculous) and a utility link is also present in the menu to automatically add the current URL to the extended menu block. This is of course restricted to administrators only. It is also planned to make tree menus using this block.
The categorisation within the Admin area has been changed to a more logical sense. There now exist 7 categories:

'System': Admin Panel, Mailer, Modules, Settings
'Layout': Blocks, Themes, pnRender
'Users': Permissions, Groups, Users, Profile
'Content': Admin_Messages, Categories, legal, Search, blank
'3rd-party': Empty categorie for newly installed modules
'Security': SecurityCenter, SysInfo
'Hooks': Censor

ValueAddons updates
The Sections module has been renamed to the (more suitable and logical) Pages module. Intuitively, this module does what one might guess: serve static information on different pages.
The Top-List module is currently hardcoded to working with just the core modules, and planned is to move it to some sort of plugin architecture (using special plugin API files and call specific functions in them). This is in progress.
Miscellanious updates
We now have a html installation guide with a CSS based on http://community.postnuke.com, and an html upgrade guide is separated

Generated on September 4, 2006.

PostNuke Directory.com Goes Live   (News)

Can I add my modules/blocks/theme site there?
Sure, just be sure to check to see if it has already been added. If not, please only add your site once.

Do I have to register to use this incredible resource?
Heck no, I just plan to bombard you with google ads so do a fellow nuker a a favor. ;)

If you guys have suggestions for categories, please post them here.


The site also hosts Postnuke ESP: The Survey Module has been updated for 760

Thanks Enjoy!

Generated on January 26, 2006.

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

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

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

Generated on September 11, 2005.

A Time to Grow and Change: PostNuke Software Foundation Formed   (News)

German PostNuke Foundation, currently represented by Andreas Krapohl, Drak of HostNuke, and Vanessa Haakenson. (see short bios below)

The functions of the founding members serve a managerial and strategic function, ensuring the project goals and directions remain constant and true to the open source philosophy, quality coding, collaboration, and open standards. It's important to stress you are not required to be member of the foundation (there is currently no membership option) to contribute to the project.

As a result of our combined experiences over the last four years the founding members agree the best way to move the project forward is to have a PN Steering Committee* (see details below) consisting of members of the various teams chosen from well-known, long term active community members and developers.

The job of the steering committee will be to handle the day-to-day running of the project and will be chosen by the founding members. The announcement of the appointments will be made within the next 10 days.

In closing, in the coming days look for an announcement regarding the PN Steering Committee and over the coming weeks look for announcements about a new look/feel for main PN site, a formal site for the foundation (read current bylaws here: http://www.postnuke.com/foundation/) and an updated project road map.

We have set up a forum for further discussions regarding the foundation here.

Viva la PN!

Sincerely,

Board of Directors
PostNuke Software Foundation, Inc
Harry Zink through Fizbin, LLC
Mark West, Lead Developer
German Postnuke Foundation, currently represented by Andreas Krapohl
Drak through HostNuke
Vanessa Haakenson

_________________________________________________________
PNSF Facts & Information
PostNuke Software Foundation
Non-profit registered in the State of Delaware
PostNuke Steering Committee
Advisory body made up of members of the various teams and responsibilities include:

Community management & resourcing
Determine software project priorities
PostNuke software development and direction
Provide policy recommendations
Approval of development plans

Goals/Objectives:
The Corporation is a non-profit organization organized and operated exclusively for charitable and educational purposes. No part of the earnings of the Corporation shall ever inure to the benefit of or be distributed to any member or individual having a personal or private interest in the activities of the Corporation.

Board of Directors
The Board of Directors serve a managerial and strategic function, ensuring PostNuke remains constant and true to the open source philosophy, quality coding, collaboration, and open standards. The following people/organizations serve as initial members of the corporation:
Fizbin, LLC (Harry Zink)
One of the original founders of the project, Harry has been a constant, continued project supporter. He works as a systems administrator for a large entertainment corporation and lives in Los Angeles, California. He has a Ph.D. in psychology and loves to travel to Thailand for the food.
Vanessa Haakenson
Is co-founder of Distance-Educator.com and has been an active participant in PostNuke since July 2001 consulting on usability issues and acting as a PN evangelist to the educational community. In November of 2001 she started the site Designs4Nuke.com to consolidate and share all the information and resources regarding theme design for PostNuke. With a Master's Degree
in Educational Technology she brings a unique perspective to the project having developed web based products focusing on usability, standards, documentation, and community. Over the years she has presented at conferences about PostNuke and has authored articles on effective information design. She recently moved with her son from San Diego, California to Woodland Park, a small mountain town in Colorado.
HostNuke Ltd. (Drak)
Drak has been with the project since July 2001 and was the first to create hosting accounts with PostNuke preinstalled as a way of making it easy for new users to get started. He has 19 years experience in the computer industry and devotes most of his time working for a humanitarian charity. He donates equipment and colocation to the project and is responsive for all server level security and administration.

Mark West, Lead Developer
Works as the computing officer for Systems and Operations for Kingston University and lives
in
South
West
London,
UK.
He
specializes
in
directory
enabled
enterprise
computing,
he's
taught
programming;
techniques,
data
structures
and
algorithms
to
first
year
undergrads
at
Kingston
University
and
adheres
to
a strict
style
of
programming
- heavy
on
layout,
consistency
and
style.
Believing
the
benefits
of
this
strict,
consistent
and
academic
approach
to
coding
is
a stronger,
more
stable
and
bug
free
end
product.
He
has
been
using
PostNuke
from
the.70x.
series
and
is
the
lead
developer.

German
PostNuke
Foundation
(Represented
by Andreas
Krapohl)
Andreas
Krapohl
[aka
larsneo]
is
President
of
the
German
PostNuke
e.V.
foundation
and
is
the
head
of
IT
for
a local
newspaper
in
southern
Germany.
Has
been
with
PostNuke
since
almost
the
beginning
- at
first
with
some
translation
stuff,
then
as
module
author
(phpBB_14)
and
since
early
2002
as
a core
developer.
Main
focus
is
security,
usability
and
accessibility.
He
believes
a solution
should
be
simple
and
elegant.


Current
Jobs in PostNuke
Structure

Development & Quality
Assurance
Communications & News
Moderation
Forum
Moderation & Support
Documentation
Language

Project
Marketing

Generated on August 18, 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.

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.

Kevin Hatch, Author of PostNuke Book   (News)

Question
Vanessa Haakenson: Kevin first let me thank you for taking the time to answer my questions. Tell us about yourself and what attracted you to PostNuke. How long have you been using PostNuke? Why didyou choose PostNuke?
 
Answer
Kevin Hatch: Well for what it’s worth, I’m a professional web developer. I’ve worn a lot of hats over the years with different sometimes-fancy titles, but overall I’ve mainly been a front-end UI guy in most of the teams I’ve been with. Lately I’ve been doing more programming and database development than Photoshop graphics, but I also freelance as a designer to help balance out the creative side.

I was first introduced to PostNuke early in 2003. My workplacewas primarily Microsoft when it came to web development, and my background at the time was much more with VB/ASP and early .NET. But we were starting a change to Linux servers, and it seemed clear ASP was on the way out. It was a coworker friend of mine that originally suggested PHP as a more universal solution, and without any particular preference for ASP I was happy to give it a shot. My experience with C++, Java, and JSP allowed me to pick up PHP pretty easily, and I quickly feel in love with language.

My first PostNuke site was actually an intranet portal. I’d converted all our other sites’ ASP pages to PHP, but we started looking at different PHP content systems to make the intranet development a little easier. I tried early alternatives like PHP-Nuke and phpWebSite, but PostNuke impressed me as a more mature system that also possessed a strong community of users.


 
Question
Vanessa Haakenson: What is the easiest and/or most difficult thing you encountered building your site?
  
Answer
Kevin Hatch: Funny thing, the most difficult thing about my current site was the choice of methods for publishing the content. There were too many options. I struggled with a number of different combinations of stock and third-party modules like PageSetter. I went all out, creating complex layouts and forms for my pages, but ultimately my needs just didn’twarrant all the trouble. I came back to the basic Sections module for most of the content, and the simpler solution gave me more raw control.
The easiest thing had to be my solution for the column layout using AT-Lite. My original theme was done with Xanthia, but I later tried it in AutoTheme to see how the layout features would work for what I needed. I found AT’s AutoBlock objects to be anabsolute dream for easy block-to-page assignment, and that’s what I ended up using.

Question
Vanessa Haakenson: When did the idea of a PostNuke book happen? What's the back-story?
  
Answer
Kevin Hatch: Early on as I worked with PostNuke I knew it was a project under development. It didn’t solve all my development needs, and I quickly started hacking and extending the code to get the extra features and customization I needed. In order to reproduce those hacks later as needed for other installs or upgrades, I documented the steps I took. I quickly had a great deal of good content collected, and I decided it ought to be posted online in case anyone else wanted to make the same custom changes I had. I wrote up the hacks as walk-through articles, and added them to my website.
I did post links to the guides now and then when answering a forum post that could use them, but just having the articles online ultimately prompted the book. The publisher Pearson Ed was looking to do some books on Content Management Systems, and in searching online for PHP-Nuke and PostNuke resources the editor came across my site. They liked the style and content of the articles, and asked if I’d be interested in writing a full book along those lines. I also have a formal writing background, and said I’d be happy to do it. That was back in November 2003.
After the approval of the book proposal I'd put together, the book itself was written over the course of the next ten months. Things were going fine with it till the surprise release of version 0.75. Sweeping changes were made to the content to add in the 0.75 changes, and some of the existing sections were no longer relevant and had to be cut. In the end there was also an overall length issue, where some of the other third-party modules I wanted to cover were also dropped. There are a lot ofgreat modules out there, but there just wasn’t the room to do them all.

Question
Vanessa
Haakenson: How
is
the
book
selling?
Are
you
going
to
do
a
follow-up/update
when newer
versions
of PostNuke
are released?
  
Answer
Kevin
Hatch: I
know
that in
the first
month over
two thousand
copies
were
sold, but
I don’t
know the
overall
sales figures
yet. I
did secondary
edits earlier
this year
for the
second
printing,
so the
first runs
seems
to have
done better
than their
initial
expectations.
There was
also talk
of doing
a German
translation
of the
text, but
I’ve
not heard
back from
that department
to know
if it’s
gone through.
I've been
very swamped
with
work lately,
so I've
honestly
not been
following
it closely
the last
few
months.
Whether
there’s
a follow-up
will probably
depend
more on
the long-term
book sales.
I’m
up for
writing
it if it
works out.
I’ve
also considered
doing a
shorter
book that
picks up
where PostNuke
Content
Management
left
off. I
think it
would be
useful
to have
a step-by-step
walk through
on the
development
of an API-compliant
module.
In the
first drafts
of my book,
there had
been a
section
at the
end just
on module
development,
but all
that made
it into
the book
was the
short API
functions
appendix.
The book
was targeted
well to
reach a
large audience,
but I do
with I’d
done even
more on
the advanced
side. I
think PostNuke
is a great
core
product,
but I’ve
never built
a site
with it
that didn’t
have third-party
modules
and custom
hacks.
It’s
like how
Firefox
is a great
core product,
but having
the right
few extensions
can literally
change
the way
your
browse.
PN already
does that;
there is
of course
the NOC
and many
great
developers,
but I’d
definitely
like to
see even
more. You
shouldn’t
have
to be a
coder to
get it
to work.
PostNuke
can become
anything
you want
it
to be,
but it’d
be easier
to have
all those
options
possible
in simple
add-on
modules.

Question
Vanessa
Haakenson: You
have
a great
site,
KevinHatch.com.
Tell
us
a little
bit about
the site
and how
you customized
it. What
modules
are you
using
for the
site? What
modules
were customized
or built
from scratch?
  
Answer
Kevin
Hatch: Well
my main
site’s
running
on PostNuke
0.75. As
I said
earlier
I’d
used a
variety
of third-party
modules
during
the development,
but I’m
currently
only running
AT-Lite
for the
theme.
The pages
have two
main content
areas,
and while
I began
with both
areas in
the “body” area,
my desire
to reuse
the side
column
for navigation
elements
prompted
me to
set it
up as a
separate
block area.
I created
an AT AutoBlock
object
for
each area
I wanted
to isolate,
like "Links" or "Homepage" for
example.
The
AutoBlocks
are displayed
in the
same place
in the
theme code,
but I
control
the visibility
of those
blocks
from within
AutoTheme
on a page
by
page basis
using the
AT Custom Modules
feature.
The
site does
have some
custom
code hacks,
but for
the most
part they
have
been used
to simplify
the PostNuke
install.
I normally
don’t
need most
of
the core
PN features
for my
personal
site, so
I removed
what I
didn't
need. The
links page
is the
most obvious
example.
That is
just the
core
Web Links
module,
but I changed
the display
of the
content
and removed
all
the user
features
that were
not needed
anymore.
I’ve
considered
writing
a
new links
module
from scratch
as well,
but for
the moment
just editing
the
core’s
working
fine, and
I do have
enough
other projects
to keep
me busy.
The KevinHatch.com
site is
really
not finished.
I’ll
be adding
a PNphpBB2
forum for
the application
support
in the
next couple
months,
and I need
to
finally
set aside
a weekend
to edit
and upload
some of
my other
guides
and
tutorials.
I plan
on expanding
the old
programming
guide content
to
include
information
on UI design
and Photoshop.
The site
is also
currently
a hybrid
of PostNuke
and raw
PHP using
server-side
includes
to pull
in the
PN theme
elements.
It was
simply
faster
at the
time to
set it
up that
way,
but eventually
the site
will be
completely
PostNuke.  

Thank You
Vanessa
Haakenson: Thank
you
for
sharing
your
thoughts
with
the community
and readers.
  
Answer
Kevin
Hatch: I’d
just like
to say
thanks
again to
all the
developers
who’ve
put in
so much
time to
keep this
project
going.
The open
source
movement
for me
has really
re-energized
my love
of online
development.
I
know things
don’t
always
get released
as quickly
as users
might want,
but
the focus
on producing
a quality
product
is quite
admirable.

  
About
Kevin Hatch
Kevin
Hatch is a
professional
web developer
specializing
in user
interface
design.
He has
more than
a decade
of
experience
in Internet
development
and has
worked
in a variety
of roles,
ranging
from graphic
designer
and interface
systems
analyst
to webmaster
and network
architect.
These days
he mainly
programs
in PHP
as a webmaster
and application
developer,
and freelances
as a graphic
designer
for select
projects.
He
has a combined
degree
in Computer
Science
and English.
He's experienced
in technical
writing
and is
the author
of a book
on the
PostNuke
CMS. He
currently
lives in
eastern
Iowa with
his wife
and their
nine pets.  
Related Links: KevinHatch.com
Purchase the book: PostNuke: Content Management System  

About
Vanessa Haakenson
Vanessa
Haakenson
brings
several
years of
experience
in developing
web based
instructional
products.
She is
an Open
Source
advocate
and contributes
her free
time to
managing,
promoting,
and working
with the
PostNuke
content
management
system.
She has
used PHP
for three
years and
has conducted
workshops
on PHP
basics.
Related
Links:
Designs4Nuke.com
(http://www.designs4nuke.com)
   



This work is licensed under a Creative Commons License.

 

Generated on April 25, 2005.

howdark.com exploits in phpBB + PNphpBB2   (News)

Generated on November 19, 2004.

PhpNuke2PostNuke : Your bridge to the PN World   (News)

provided there. This script works ONLY for MySQL 3.x schema. For other dbms (PostgreSQL, MsSQL, MySQL 4.x) you need modify the script.

++ UPGRADE SUMMARY ++
PhpNuke 7.0, 7.1, 7.2, 7.3, 7.4 -> PostNuke 0.726
PhpNuke phpBB2 Forums port 2.0.5 -> PNphpBB2 1.2d
PhpNuke Encyclopedia -> pnEncyclopedia 0.2.0
PhpNuke Event Calendar -> PostCalendar 4.0.1

A new version for 0.750 is coming soon. I'm looking for make this a project at noc. Please help me on this topic.

Download link
Support forum

Generated on September 14, 2004.

Page 1 / 2 (1 - 10 of 15 Total)