PostNuke

Site search

Search results

Number of hits: 25

Jørn Wildt Proposes New Content Module   (News)

For the discussion see: http://community.postnuke.com/module-Forum-viewtopic-topic-53152-start-0.htm

Here is what Jørn has in mind:

[quote=Jørn Wildt]Dear PostNuke community

One of the things that always comes up when comparing PostNuke to other Content Management Systems is its lack of real content management. All we have is some old News, Pages and FAQ (and some more) management modules - nothing really fancy. You can add fancy modules like PagEd, Pagesetter, pnWiki and others but somehow they all lack, well, something - something which I find rather difficult to pinpoint. They are either too complex, too simple, impossible to extend and do not integrate well with each other.

I have been doing some thinking about this issue and would like to present some ideas for a new Content system in PostNuke. A framework that newbies can work with right out of the box, an extensible framework, and a framework with well integrated components that are aware of each other. My ideas are by no means rocket science and most, if not all, have been implemented else where - just not in PostNuke.

If you ask me then PostNuke is going to dwindle away unless something serious is done to add a good content framework. Here is my suggestion.

[b]Content Types[/b]
The core component is the "Content Type". For those of you that knows Pagesetter this is exactly the same as Pagesetter's Publication Type. This will be a separate module that takes care of defining content types, editing and displaying content items - but without user navigation! Think of an Article, with it's title, lead-in text, main text and image, as a content item of the type "Article". The type specifies the fields that are available for a single instance of the type - a single content item - a single Article.

Content Types are management by the site administrator (but can also be created by other modules). The admin can choose from an extensible (through plugins) list of field types. Here are some examples (mostly copied from Pagesetter):

- String (one line text), Text (non-HTML), HTML (using Scribite!)
- Number, checkbox, date
- Media files (using Mediashare)
- File uploads
- URL, email
- Computer code (text displayed with line numbers in mono spaced font)
- Category (using PN .8 categories), both single and multiple select.

Now you can create an article as a title (string), lead-in (text), main text (html) - and many other types of content. But there is still no navigation - neither on the admin side nor the user side. All you have is a Content module that allows you to create content types, content items and then display these - assuming you now the URLs. Navigation is delegated to other modules - more on that later on.

The core framework does also handle input form generation: it will auto-generate input forms (using pnForms in PN .8). These can then be copied to another location and re-designed using the standard Smarty templating system.

The core content module handles a few other things: for instance revision history (who changed what and when).

[b]Content Management[/b]
So far there's nothing new compared to Pagesetter. So lets take a look at the admin side of navigation - how to store and locate your content items. I suggest that all content items are stored in a folder structure identically to your standard disk drive. On the harddisk you manage folders and store files in them. In the CMS you also manage folders - but now you store content items in them - indifferently of the content type.

The first challenge is how to handle user contributed content since normal users don't have access to the administrative folder system. Now remember that the core Content system allows anyone (with the right permissions) to add content, but where should it be stored? I suggest a standard "incoming" folder is created for this purpose (much like your mail system). The editors can then keep an eye on this folder and move new content to the right folders.

Actually there should be one "incoming" folder for each content type and it should be possible to specify which it is. In addition to this the system should have a flexible workflow system a'la Pagesetter (now already in the .8 core). So that different editors and authors and admins can be notified when new submissions arrive.

[b]Content Structure[/b]
But there's still not much difference from Pagesetter. So what's the point? Well, enter CoType - this little module, which I'm rather proud of, has some nice layout features that I would like to copy. First of all you have Boxes - elements that can be floated left/right/top/bottom relative to the current content. In CoType you have boxes for media items, program examples, and general text. I would like to extend this so that you can put any content item inside a box. So you can display and Article and put one or more Media type items in boxes as illustrations.

Another thing to copy from CoType is the use of nested content - sections in sections. This concept should be extended, just like the boxes, with the ability nest any content item inside another item. The only problem here is how nested content should be displayed? In CoType you always have sections in sections (in a document) - and there's a well defined standard way to display this. But what happens if you sudden nest a Music album inside a FAQ inside a Media item ... and then box it? Well, that will have to be solved as we go.

I suggest the Content Type configuration lets the admin specify which types of content you can nest inside another.

The system could also enable boxing of other modules contents - assuming some kind of API/interface the external modules have to implement (just like PostNuke's search API).

[b]Content Layout[/b]
The proposed layout scheme is so far rather fixed - something like this:

- Top content item title is displayed inside ... tags.
- Nested content title is displayed in ... (and so on for further nesting).
- All nested content is displayed on one page.
- A small table-of-content is displayed at the top (linking to sub-content anchors).
- Each (nested) content item is displayed with a standard auto-generated template.
- Boxes floated to the left/right are displayed in 50% width (like CoType)
- Top/bottom boxes are displayed in 100% width (like CoType)

This will allow newbies to quick and easy created new content without having to also design their own templates. Assuming of course that the system comes with a suitable default set of content items.

Experienced users can edit and change the auto-generated templates. But these will be recreated everytime the administrator changes the Content Type configuration. So experienced users must copy the templates to another location and then edit them to fit their own needs.

[b]Navigation[/b]
So far I have ignored the concept of navigation between different content items completely. This is because it can be done in so many different ways - and this is mostly where the different types of PostNuke modules distinguish themselves. A media gallery has a completely different navigation paradigme than a News list, a Wiki and a Weblink collection.

So I propose to delegate navigation to other modules. This has already been done with success with a calendar (pgcalendar) and a news archive (pgarchive) for Pagesetter. These two modules takes a specific Content Type and displays it's items a calendar view and a monthly listing view. This combination is extremely strong - you can add all the fields you want on a Calendar item - and still display it using the standard calendar view. Throw in the nested content and the boxing ability and you get an extremely flexible and yet simple Content Management System.

[b]List Navigation[/b]
The basic navigation is simple a pageable list of items ordered by some criteria. You create different lists and then refer these in the URL. For each list you configure which content type(s) to include, the default sorting order, the display template to use for each item - probably more. Including more than one content type gives some problem with respect to sorting.

This implements the typical News list on the frontpage.

[b]Catalog Navigation (collections)[/b]
This is the typical Weblink and File Up/Download navigation through a collection. The hierarchy is mirrored directly from the content folders.

[b]Calendar Navigation[/b]
Displays content items by date in a calendar (see for instance [url=http://www.fgc.dk/index.php?module=pgcalendar&tid=40]http://www.fgc.dk/index.php?module=pgcalendar&tid=40[/url]). You need to specify which date fields to use as start/end date of the entries.

[b]Archive Navigation[/b]
Displays content in lists organized by month (see for instance [url=http://www.fjeldgruppen.dk/arkiv.html]http://www.fjeldgruppen.dk/arkiv.html[/url]).

[b]Menu Navigation[/b]
On thing that frustrates me with PostNuke is the horrible way you edit menus through the Block interface. No - lets allocate a complete module for menu editing and then just select which menu to display in which box (I believe Content Express does this). With the integrated content framework you can now let the editor select content items from dropdown lists or similar - and avoid having to copy/paste raw URLs into the menu editor (this has always been a intellectual bottleneck for the people I have created websites for).

I would also like to see editing of the menu directly in the front-end. The editor should always have an "add current page to menu" icon in the menu. He should also be able to drag and drop menu items without having to jump to the admin interface.

[b]Frontpage Setup[/b]
This is just another idea of what you can do - not necessarily something to actually implement. But the frontpage need not necessarily be a list of latest items as on most portal websites. It might also be a fixed setup based on a grid where you can assign different content items to different locations. For instance Articles to the left, Banners to the right, and a few images at the bottom.


[b]Where to go now?[/b]
Now who's going to implement all this? Good question considering the speed of the core development. I would love to be on the team (and will be) but my time is restricted (especially now that I got my first kid) so I work rather slowly.

Any volunteers?

There's also the question of organizing the code - we cannot have much more than one or maybe two developers on the core Content module. But as soon as that is ready we can take more people in - one for each kind of navigational scheme. Other people can then work on the default content types.

We also need to consider how a system like this fits into the PostNuke distribution. Does it have it's own release cycle? Is it integrated with the core?

Enjoy 8-)

/Jørn[/quote]

Generated on September 4, 2007.

Call for articles for pnLanguages   (News)

thoughts about the PostNuke language system, the organization of pnLanguages and just about any other PostNuke-related topic you like.
If English is not your mother tongue and if your English isn't perfect, it's not necessarily a problem. That can be corrected. If an article is in another language but is of particular merit, it may also be possible to have it translated into English. All submissions must be your own work.
After some appropriate editing, if they make useful food for debate, they can be published in the pnLanguages news section. And maybe on pnNews, too, although your article will then be examined and considered by PostNuke's other team members with editor permissions. At pnLanguages, you chiefly only have to deal with me. :) And I'm a nice guy, I promise you. :)
When I talk about "editing", I mean I'll correct grammar and spelling, but I'll also read your articles, and -- where I see a need -- feed back thoughts and questions for you to further polish your content. My main criterion is whether there is some logical validity or standpoint for what's being said.
You'll get full credit for your articles, and the editing process will be a two-way interaction. The final draft will only be submitted for publication with your complete approval.
Don't worry, I'm a free-thinking, cooperative, open-minded person, and I believe that putting contrasting opinions face to face is a great way of opening-up constructive debate. I'm not talking about trying to direct your thoughts, just possibly inviting you to express them and form them more fully, if such seems to be needed. Even if those ideas don't match my own. You can trust me to be objective and detached. My main criterion is whether there is some logical validity or standpoint for what's being said.
Most important, though, is to be courteous and measured in what you say. No "personal attacks". :) And if you talk about a "problem or issue", then try suggesting some "solutions and answers". Constructive criticism is a healthy thing.
Got something to say? OK, organize your thoughts and put it down in writing! Let's all read it!
For a good model of what I feel is a well-constructed article, take a look at Olaf Fichtner's contribution about the PostNuke language system on pnNews (Olaf's article can be seen here). I'm firmly hoping that Olaf is going to be following-up on that paper. But we need to see others from other people, too.
Really hoping to hear back from you. :)
David at PostNuke dot com :

Generated on September 22, 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.

pnEuropeMeeting 1.0 -- PostNuke Summer Meeting, Stuttgart, Germany   (News)

The following PostNuke people already promised to attend: Mark West (GB, PostNuke),
larsneo(D, PostNuke, pnForum), Landseer (D, PostNuke, pnCommerce), Jørn Lind-Nielsen (DK, Pagesetter, Photoshare), Jörg Napp (D, PostNuke, EZComments), Brave Cobra (B, Content Express), Sebastian Schürmann (D, PostNuke, pnCommerce) and Drak (GB, HostNuke). Thus, we expect interesting and exciting talks.

Depending on the weather, we will visit a beer garden on Saturday evening.

We expect a fee of approx. 10 to 20 EUR (excluding food and drinks) to cover the costs. A special arrangement with a hotel for accommodation has been made.

Whoever wants to attend might contact us via mail at pnMeeting@postnuke.com.

Generated on June 18, 2004.

Brazilian Portuguese for 0.726 with over 60 modules!   (News)

supposed to "hit and run", because there might be some files which are heavily hacked -- yes, you can do that to translations, too :-)

That's because I used for quite some time pncUserHack (affecting NS-User, NS-NewUser and NS-Your_Account) and some News hacks. Also, Extended Topics and AT Lite Blocks might have different defines. But, anyway, that won't stop your site from working, of course. And bear with me, as this is a one man job.

But, please, send me your patches, so I can clean it up and release a FULL CORE COMPATIBLE TUpInUKIM, ok?

Here's the listing of modules included:
******************
* Módulos (63) *
******************
advanced_polls
All_Stories
Archive
Autolinks
Blocks
Censor
ChangePassword
ContentExpress
Credits
Downloads
dq_helpdesk
Encyclopedia
FeedBack
feproc
fetax
FormExpress
legal
MailBag
Members_List
Messages
Modules
News
NS-AddStory
NS-Admin
NS-Admin_Messages
NS-Banners
NS-Comments
NS-Ephemerids
NS-Groups
NS-Languages
NS-LostPassword
NS-MailUsers
NS-NewUser
NS-NewUser*
NS-Past_Nuke
NS-Referers
NS-Settings
NS-User*
NS-Your_Account*
pagesetter
Permissions
photoshare
phpBB_14
pn_bbclick
pn_bbcode
pn_bbsmile
pnTresMailer
PostCalendar
Quotes
Ratings
Recommend_Us
Search
seminars
shortnews
Stats
Topics*
UpDownload
Web_Links
xuser
* => modules duplicated in the pack due to hacks:
pncUserHack
ExtendedTopics

******************
* Blocks  (28) *
******************
admin.php
banners.php
big.php
category.php
emldaonline.php
ephem.php
error.php
finclude.php
fxp.php
i-featured_article.php
linklist.php
login.php
menu.php
online.php
past.php
phpBB_14.php
phplive.php
poll.php
progress.php
radio.php
recent_and_top_news.php
rss.php
rss2.php
stories.php
thelang.php
topic.php
user.php
whatsnews.php


Download link: http://prdownloads.sf.net/pnlanguages/pnlanguages-x_brazilian_portuguese-0726-tupinukim-A-beta.zip?download
Release notes (in Portuguese, pretty much the above info): https://sf.net/project/shownotes.php?release_id=239437
Project page: https://sf.net/projects/pnlanguages

Generated on May 20, 2004.

An Expert's Opinion: Furthering Our Understanding   (News)

Dear Vanessa and All Other Members of The Fabulous PostNuke Community:

I am an attorney-at-law, licensed by the State of Florida, and the United States District Court for the Southern District of Florida to engage in a multi-jurisdictional copyright and trademark practice. My practice focuses on cyberlaw (see http://cyberlaw.info). Nothing contained herein is legal advice, nor should it be relied upon without independent research and consultation with a licensed attorney. The following discussion is limited to the laws of the U.S.

I have been asked to comment upon the following hypothetical. If a person or entity (jointly and severally referred to hereafter as "Party A") creates a theme utilizing, or adds an original image or code to a GNU GPL program that was copyrighted subject to the GNU GPL ( see http://www.gnu.org/licenses/gpl.txt ), may another person or entity (Party "B") distribute Party A's distribution containing the new material without the permission of Party A because the entire work (including the new material added by Party A) has now become subject to the GNU GPL?

Also, you have asked me to assume the following notice appears on Party A's
work:

// ----------------------------------------------------------------------
// Copyright (c) 2002-2003 Party A
// http://partya.com
// ----------------------------------------------------------------------
// LICENSE
//
// This program is free software; you can redistribute it and/or
// modify it under the terms of the GNU General Public License (GPL)
// as published by the Free Software Foundation; either version 2
// of the License, or (at your option) any later version.
//
// This program is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
// See the GNU General Public License for more details.
// To read the license please visit http://www.gnu.org/copyleft/gpl.html
// ----------------------------------------------------------------------

The pertinent portions of the GNU GPL are as follows:

"0. ... the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does."

"2. ... mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.

Pertinent Sections of United States Copyright Law:

Copyright protection extends to an "original work of authorship fixed in any tangible medium of expression. 17 U.S.C. 102 (a) at ( http://www4.law.cornell.edu/uscode/17/102.html ).

Copyrights are divisible (i.e. you can retain certain exclusive rights, but transfer others). See Section 17 U.S.C. 106 ( http://www4.law.cornell.edu/uscode/17/106.html).

Discussion:

The above license purports to convey via the GNU GPL rights to the "program."

Since copyright is divisible, we must first determine the meaning of the word "computer program." A definition for the term "computer program" is actually a question of fact that would need to be determined by a Court or jury. Dictionary.com defines computer program as follows: "computer program n : (computer science) a sequence of instructions that a computer can interpret and execute; "the program required several hundred lines of code" [syn: program, programme, computer programme]".

It can be argued that an image (which has been stored on digital media) is not a "program." It is data which is called by a program. It would be an anomalous argument to propose that a copyrighted picture taken by the owner of the program and was included in his distribution of his GNU GPL program could be used unless the owner consented.

Similarly, it follows that a presentation, template or display, which is created utilizing copyrighted programs, may not in and of itself be a "program."

Very generally, there is no impediment to obtaining independent copyrights for original works of authorship created by utilizing programs. If there were, Microsoft would be able to prosecute every author who submitted an original manuscript to a publisher in Word format and digital artists would be unable to copyright their works because they used a paint program.

Similarly, if someone creates a theme or skin that artistically rises to the level of an original work of authorship utilizing a program, the resulting theme or skin should be copyrightable separately from the program that created it. It could be argued that the skin, theme, or result is a new, original work of authorship fixed in a tangible medium of expression, and not a derivative or compilation of the original program (i.e. Word, Paint Shop Pro, or, for that matter, Autotheme).

Turning to paragraph 0. of the GNU GPL, licensing a program or work under its terms does not make all files included with the distribution subject thereto See paragraph 0., supra. In our hypothetical, the notice only refers to the "program", and not any particular resulting theme or image therein.

Turning to paragraph 2. of the GNU GPL, "the mere aggregation" of an original work of authorship which is not a derivative or compilation of the program with the program (or with a work based on the Program) on a ... distribution medium "does not bring the other work under the scope of the License." In plain English, this means that just because a distribution contains some files which are subject to the GNU GPL, NOT ALL files contained in the distribution may be so subject. This argument should also apply to data entered into the program to make it display an original work of authorship.

With respect to the language contained in the notice contained in Party A's distribution, a reasonable interpretation of same should lead a Court and/or jury to determine that a program is not the resulting theme, skin, etc., but a set of instructions that the "artist" utilizes to create same. Just because core code is distributed with additional files, or data is entered into existing code to make, draw or display the new skin on screen, should not, in and of itself, make the new files or data subject to the license. See GNU GPL paragraphs 0 and 2 above.

Pursuant to 17 U.S.C. 106, copyrights are divisible (i.e. you can retain certain exclusive rights, but transfer others). Accordingly, it could be argued that Party A's copyright in and to the theme or skin or image remains the sole and exclusive property of Party A. If the argument succeeds, those who violated Party A's exclusive rights (17 U.S.C. 106) in the resulting theme, display, image, skin, etc., face exposure to federal suit for copyright infringement.

Notwithstanding, the program code and modifications made thereto which are considered to be derivatives or compilations ARE subject to GNU GPL, unless the additional code merely "plugs-in" to the preexisting code, is "not based on preexisiting code," and is capable of "standing alone." Note, early cases did not hold telephone manufacturers liable for patent/copyright infringement because their pin out to wall jacks was identical to that of the other's pin out, allowing access to the other's network.

It would logically follow that a third party can utilize GNU GPL code to create an original work of authorship (i.e. a new theme) and obtain a copyright in the new material. However, if the resulting theme, display, image, and or template is similar to that which the artist has not released under the GNU GPL, the third party could be prosecuted for copyright infringement if that third party did not get consent (provided other procedural requirements are fulfilled).

It is worth mentioning that the creator of a program who initially released it under certain conditions, may be able to revoke same at any time (but this would require further research and is a topic for another discussion).

Elliot Zimmerman, Esq.
The Law Offices of Elliot Zimmerman, P.A.
5353 North Federal Highway, PH 405
Fort Lauderdale, FL 33308
http://cyberlaw.info
legal@cyberlaw.info

Generated on April 30, 2004.

Content Express Training Course Availalble for Dutch Users   (News)

and eventuallly will go indepth to the more advanced features of this module. Afterwards we all go to the pub and have a beer.

Date: May 15, 2004
Location: Amsterdam
Max number of people: 20 *
(at time of posting just 15 available spots left)

Cost: 10 euro (includes lunch, coffee and tea)
More info: http://postnuke.opencms.nl

Everybody is invited, but since the course is in Dutch and held in Amsterdam, I don't suppose many are interested...

To register for this course, see the posting on the main page of http://postnuke.opencms.nl

--- For the Dutch People----
BraveCobra, Projectleider van Content Express zal een IRL (In Real Life) presentatie houden over de mogelijkheden van Content Express.

In deze presentatie beginnen we met een korte introductie van postnuke. Vervolgens legt hij de basisfunctionaliteiten van Content Express uit, waarna we uiteindelijk nog dieper duiken in de meer geavanceerde mogelijkheden die Content Express kan bieden. Na afloop kan je vragen stellen en gaan we met zijn allen naar een barretje in de buurt (moet lukken in Amsterdam:) )

Datum: 15 mei
Locatie: Amsterdam
Max aantal inschrijvingen: 20 *(nog 15 plaatsen vrij als ik dit post)
Kosten: 10 euro (inclusief lunch,koffie en thee)
Meer info: http://postnuke.opencms.nl

Iedereen die klein beetje weet wat postnuke is en ga e.e.a. wat verder zou willen ontdekken is van harte uitgenodigt. (of als je gewoon een keer gezellig een biertje wilt doen met medepostnukers.)

Om je in te schrijven, zie de posting op onze hoofdpagina : http://postnuke.opencms.nl

Generated on April 28, 2004.

Postnuke .8 - A Preview   (News)

order to improve Postnuke's performance the code was optimized. Additionally Smarty's (Xanthia) and ADODB'd caching can be used.

5. Advanced User Module - All features of Chestnuts pncUserHack will be included in the new user module. Dynamic user date will be kept in an extra module.

6. Mailer Module - Basing upon phpMailer (PHP Libary) external SMTP-/Mailservers, HTML-mails and attachements can be used.

7. Further Database Abstraction - ADODB data dictionary Tools will support installation with various database management systems other than mysql.

8. Advanced Authentication - Additional to Postnuke's user database authentication with other system can be realized. LDAP will be supported and other systems can be added via plugins.

9. Additional Hook Modules - Jörg Napp's EZComments replaces the hitherto NS-Comment modules. Other hooks will be bbcode, bbclick, bbsmile and hitcount.

10. Advanced Statistics - Craig Saunder's AdvStats Module will replace the HTTP-referer and the statistics module.

11. Syndication Feeds (RSS / Atom) - Feeds can be generated from all modules using templates.

12. extended RSS Support - Future RSS support will be using external RSS parser Onyx RSS

13. Global Categories - The new categories module provides cateories in all compatible modules like FAQ, News, WebLinks aso.

14. Collected Pending Content - Basing upon the SnakePending module all pending content will be collected and displayed in a to-do overview.

15. Printing - Printing view supported via special printing template

16. Better Support of current Standarts - All output will be valid HTML strict (hitherto: transitional) and XHTML. This also applies for the the feeds.

17. Support of 3rd Party Developements - Postnuke will in future include 3rd party open source developements. Since the .7 series only featured ADODB as an example, .8 will make use of the Smarty developement, but will also include phpMailer and Onyx RSS.

Together with Jørn Lind-Nielsen globally available pictures gallery Photoshare and his meta module pagesetter, pnCommerce, PagEd, Content Express and all the other great modules this all sounds great, doesn't it?

The ultimate question remains unanswered: When will .8 be released? pnCore-Team manager Larsneo expects a milestone release in

Generated on March 11, 2004.

New version of Backend.php for Postnuke supports Atom Feeds   (News)

to also use the same namingconvemtion as other stuff from this site, you will gain a wider syndication solution for your users.

First of all you get all the benefits from the backend2.php which is already out and used by a lot of people. See more information here

Second you will gain support for multiple feedtypes, just by adding something to the url.

By default you will recieve a RSS 2.0 feed. But if you specify an other of the supportet feedtypes you will be able to get validating RSS 0.91 feeds and validating Atom feeds.

However the Atom specification is only at version 0.3 so that may change in the future, but I will try to keep up with the development as it goes.

At the same time I would like to request some help from the community. I am looking for a coder who woul dlike to help me make a new version of the xRss module for Postnuke.
It seems there are a growing interrest for this, and I would like to add more functionality. My trouble is that I am not familiar with how to recieve information from other modules. Like getting lists of topics, languages, categories etc. to choose from while selcting your sources for the feed url or script.

Demonstration:

Atom
Atom validator

RSS 2
RSS 2 validator

RSS 0.91
RSS 0.91 validator

Functionality demo:

RSS 2 topic 1 and 18 only in danish and english languages

To support multilingual sites the language of the story is included in the link.

I will also be interested in headring from anyone who have special requirements for the feeds, like if you woul dlike to expand the use of elements in a feed.

Example: Under each Item a number of extra elements can be added like a link and description to the Category or topic. Postnuke

Generated on February 7, 2004.

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