PostNuke

Site search

Search results

Number of hits: 22

What's going on?   (News)

holidays there was not much acitivty in the SVN but now that both Mark and SVN are back we are fixing the remaining bugs for the RC2.

2. A name for the rebranding has been chosen. The Postnuke Foundation is currently in the process of trademark- and domain registration. The legal stuff seems to take some time. It won't contain a P or a N - so if you plan any new modules you shouldn't call them pnThisAndThat.

3. Speaking of module development:

a) Axel Guckelsberger of the Steering Committee just presented his diploma thesis: Modulestudio will not only revolutionize the way of programming Postnuke modules. It is way ahead of other similar systems. There will be a free version available but this will be a limited version.

Modulestudio, Google Video

b) Jørn Wildt started the work on the content module we discussed some months ago here and at the pnMeeting. This module is simply called "Content" and it uses all the new stuff in .8. The principle behind "Content" is that you first choose the layout of the article you want to write (1 column, 2 colums, whatever you like) and then you place blocks of content inside this layout with a smooth javascript interface. These blocks can contain text, images, videos, Google Maps aso. More blocks can be included as plugins.
http://noc.postnuke.com/projects/content/

c) As Jørn Wildt ceased work on Pagesetter ("I does all I need and it runs with .8") German programmer "Kundi" has picked up this work. He completely rewrites Pagesetter in order to remove Jørn's Guppy form framework and to include .8's Form framework, workflows aso. His first release will do everything that Pagesetter 6.3 does and it will be able to import from Pagesetter. Kundi is currently looking for a nice new module name. Any suggestions?

d) Robert Gasch works on a shopping module which won't be GPL - I was able to take a preview and it looks very adult and I think it will be worth it's money.

e) The last time I looked at pnUpper it was kind of a niche module that I never really had any use for. Axel Guckelsberger is currently turning it into a full fletched media library for the central storage of any kind of media to be used in other modules. Thus he renamed it to MediaAttach.

MediaAttach

4. Now that the NOC seems to be kind of stable again we hope to have time to replace it with a less complicated software. We ar

Generated on November 20, 2007.

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.

New Shop, New Calendar - Postnuke Community gains speed again   (News)

New Community Modules
Have you seen Florian Schliessl's modules? The central module is pnProfile - an alternative profile module similar to the new core module or AdvProfile (which actually has become the new core profile module ;-) ). pnProfile offers dropdowns, textfields aso.
Demo: technobilder.de.

Another nice community module is Florian's UserPictures. It allows users to keep their own personal gallery.
Demo: technobilder.de

I personally very much like Florian's ClickedMe which displays all the people who checked out you profile. Every user can choose for himself if he wants to be seen or not.
Download: ClickedMe.

To cut a long story short: Florian has released a bunch other modules. A list can be found in his NOC profile.

PostBuddy is a module that copies a very popular function of mySpace aso - you can make people your friend and display a list of your friends in your profile. Cool, eh?

Has anybody tried pnConnections? It sounds like a cool module.

Shops!
Did you see that Bernd Plagge adopted pnCommerce and released a working version? Contact him, if you are interested in cooperating with him! pnCommerce could use some cool new templates.

And pnCommerce has a young competitor! The development team has released a first beta of ShoppingKart. They are very active and keen on making ShoppingKart a cool module. IMHO their templates also lack beauty - but it's a first beta. ;-)

New Calendar
Robert Gasch and a user named "bones" announced to start working on a successor for PostCalendar - I'm really looking forward for that one.

But the grandmother of all calendar modules also has a competitor: crpCalendar. A neat little modules that's made to display a list of event dates - if you don't have too many of them it could fit your needs.

What else?
Did you see that Treverj is working on a cool Postnuke based Web 2.0 community site? Read: Project Updates.

The Spanish community released a Karma Addon for pnForum. You only need dpGraph for it.

Mark West released a new version of EZComments and added Akismet support. Akismet is the spam detection API of Wordpress. So EZComments sends all comments and trackbacks through Akismet to find out if it's spam or not. If you are working on any module that's been spammed - check out the Akismet module API and integrate its features into you module.

InvalidResponse released a first final version of his ElementBB forum. It's a nice and slim forum with great templates. Check it out at his homepage.

Jørn Wildt released a new content module that keeps content in a book like way and is made for team work. It's called CoType and should also serve as an example for a .8 implementation.

Hilope's Scribite is not only a module that adds the WYSIWYG editor of your choice to Postnuke modules. If you look deeper into the possibilities of for examples Xinha you will certainly never work on any site without this module. BTW: The initial development of Scribite was sponsored by the German Postnuke foundation. ;-)

Forgive me if I forgot your cool new module - this article wasn't meant to be complete. I wanted to give a little overview o

Generated on June 7, 2007.

Introducing: Scribite!   (News)

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

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

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

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

Links:

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

Generated on March 2, 2007.

PostNuke Community User Survey Results   (News)

http://www.designs4nuke.com/results/

PostNuke Site Navigation
We are currently working on improving the navigation and look/feel of the main PN site. And with all things it doesn't always go as quickly as we'd like but we expect to launch a preview of a new site in the very near future.

Documentation
This is constant concern for everyone involved in the project. There have been some nice additions to the documentation project over the past few months and I think more than not having documentation, the real issue it is difficult to find. So as we improve the main site we are paying close attention the issue of documentation. So look for improvement in this area in the near future.

Module/Block Repository
Some users requested a "full and complete list of all available modules/blocks/themes" - and we would like to say this is nearly impossible and it it were possible, it would be alot of work to keep it up-to-date. Several years ago we setup PostNuke's NOC as a centralized place to support any PostNuke related project for FREE.

The site offers the following developement tools: CVS (including a web interface), mailing lists, discussion forums, bug/feature tracking, document mgmt, task lists, and a website that provides usage statistics, including the project members, the number of mailing lists, CVS statistics, the number of items in the discussion forums, etc.

We encourage anyone, developers and designers, with a PostNuke related project to register their project.

Register a Project
Check out the Current Projects

UPDATE: The NOC is not perfect. The team knows it has flaws and that support there was lacking so we've added additional admins so no one should have to wait for weeks for project approval any longer.

Current NOC admins Drak Valerio, Frank Schummertz (pnCommerce.com) and IIRC Franky Chestnut (pnConcept.com).

This is our attempt to build a module, block, and theme repository for all PostNuke related projects.

Module Info
There are so many modules claiming to be PostNuke modules and were only half heartedly ported it the first days of PostNuke so beware there have been so many changes in the development over the past four years some modules may not work with the most up-to-date versions of the PostNuke CMS.

Better Forum Support
First let's agree the forum is quite helpful but we recognize there are some areas we can improve. We appreciate the feedback and are looking into ways we can optimize the technology to help us provide better forum support. But don't be shy, once you learn to do something or have an answer/response to a question get involved.

Summary
Finally as mentioned in the comments there were design errors in this initial survey but even with these errors the results are valuable and has shed light on several areas of the project. Again, it's our first survey and we will improve as we create more surveys in the future. There's no such thing as a perfect questionaire but we intend to get closer to perfection in the future. :)

Get Involved
We are looking for volunteers for several positions listed below:

1. Module Review Reporter: Responsible for testing and reviewing new and older modules to publish on the main PostNuke site. Your articles/publications will include your picture, a short bio, and a link back to your site.

2. PostNuke Community Reporter - not every module developer writes his own news at PostNuke and we're looking for someone who is interested in writing up announcements, interviewing developers, and looking for exciting developments in this specific area of the community.

3. International Community Reporter: As a project we want to build relationships with the wonderful international sites and communities. The person who takes on this position will be responsible for writing announcements, and conducting interviews. Your articles/publications will include your picture, a short bio, and a link back to your site.

4. PostNuke Theme Reporter: Responsible for theming news, short how-tos, tutorials, and introducing/interviewing designers. You should be familiar with all the elements of theming for PostNuke including the Xanthia and AutoTheme. All your articles/publications will include your picture, a short bio, and a link back to your site.

5. Special Content/Documentation : We are looking for someone to compare/contrast the features of PostNuke to the following: PHP-Nuke, Mambo, and Drupal. The person should be familiar with both software CMS's to do a clear, concise comparison of features, functions, etc. Also you would have access to the PN team to review the comparison to offer technical feedback and information for accuracy. And the document would be included on the main PN site to help potential users decide which package to use. You would also be provided with a matrix of specifics to compare with guidelines so you wouldn't have to start from scratch. Your publications will include your picture, a short bio, and a link back to your site.

For more information about the volunteer positions contact us at: vanessa at postnuke dot com

Generated on July 12, 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.

Interview: Lee Eason   (News)

Tell me about your postnuke "career".
Well, when I first started with PHP it was to build an object translator for
a Flash based order management application I was building. The key was to
keep cost low, so we were using all open source stuff. I liked PHP because
it was fast and very easy to use. Then I started seeing how much PHP was
being used on the web as a language for dynamic sites. That led me to the
open source CMS world, which is where I found PostNuke. I liked how easy it
was to install and extend. I messed with some other systems but PostNuke
was the one I settled on because of its flexibility.

What is your task in within pnCore?
Good question, lol. I don't really know for sure. I'm pretty sure it has
something to do with an article I wrote a while back outlining a PostNuke
module development SDK I have a vision for. It would include a couple of
modules that would work together to help people develop PostNuke modules
rapidly with documentation and support tools all built in.

When did you start programming for PostNuke?
I have not actually started programming for PostNuke yet. I suspect most of
my contribution to the core will consist of input on the project's direction
whenever I can help, and in the writing and development of the SDK's
modules.

What is your development like?
I hope it will be huge. I'd like to see more of the "average joe" be able
to developer, deliver, and support modules they have a need for and can pass
on to the rest of us.

What is the biggest difficulty in your development?
The most difficult thing about developing is trying to create cutting edge
features that will work on any server configuration. I found with
pnFlashGames that subtle differences in PHP and mySQL versions can really
throw a monkey wrench in the works.

Which route will Postnuke in your opinion go in the future?
I think that with the introduction of Xanthia the doors have been opened
wide. The upcoming .76 release also shows us that the developers are
thinking in practical terms, which is great. I would like to see PostNuke
go towards a more business oriented platform, but that is greatly dependant
on module developers providing the functionality to make that work.

What is the weakest/strongest point in PostNuke?
I think PostNuke's greatest weakness is also its greatest strength: the
modular nature of the system. PostNuke relies on third party modules to
deliver a good bit of functionality that every site needs or wants. As a
result, users are at the mercy of the developers of these modules. So if
the modules are buggy then it makes PostNuke look buggy. Conversely, if
they are written and supported well then it makes PostNuke look all the
better. This is another driving force behind my vision for the SDK.

Anything else you always wanted to say about Postnuke?
It never ceases to amaze me how no matter what you do or where you go,
everything is run by individuals. Everyone has their own personality,
complete with their own set of characteristics. This simple fact is what
makes working in a global community like PostNuke so exciting. But you
know, even with all the different cultures and languages the pnCore has to
deal with, module developers and the pnCore team alike all just has to
provide good quality customer support and that will guarantee PostNuke's
continued success. I have always been impressed with the pnCore's customer
support. I strive to offer a high level of support to my module's users as
well; staying positive and trying to be helpful has helped me to establish a
good reputation and a successful project. I only wish we could see more of
that with the third party module developers.

Tell me something about your module work?
I am the author and director of pnFlashGames and pnFlashGames.com.

When did you start working on your own module?
When I first starting using PostNuke I wanted to build a website for my
company and have some tools to help our customers get downloads and
information they needed quickly and efficiently. I could not find modules
that did what I needed so I set out to learn how to make my own modules. I
thought that the best way to do that is just to make my own. So I chose a
fun and easy subject for my first module, a flash games gallery. I found
some flash games to start out with and it just so happened they had a common
high score system (they came from the same author - Paul Neave). So then I
though, if Paul Neave can store high scores in a text file with a common API
for his games, I can make my own API and store the scores in PostNuke's
database for any flash game. Thus, pnFlashGames was born. I never thought
it would become as popular as it is now. I still chuckle when I look back
at my first release.

What features should the Postnuke .8 core have to simplify your
work?
:lol: an automatic conversion script that will take a pnHTML module and
convert it to pnRender.... Seriously though, I'd love the ability to load a
"light" version of the PostNuke API that gives me access to the database and
module API for only the parts I need. This way, I don't have to load the
entire application just to store a score. I only have to load just enough
to get to the pnFlashGames API and make a database call.

Which route will your module in your opinion go in the future?
My community is so fantastic. They are always providing me with great
suggestions and very cool ideas for features and direction. We are working
on multiplayer games, global high scores (site vs. site competitions),
enhanced team functionality (team vs. team competitions), and better quality
and more port projects for other CMS. Currently, pnFlashGames has been
ported to Xoops, Mambo, Invision, and just recently to PHPNuke.

Recently a wonderful thing has happened with pnFlashGames as well. My
company, SourceKit, acquired pnFlashGames and pnFlashGames.com. It's great
news and means that big things are happening with our project. I believe
this is the first time a PostNuke module has been purchased by an
independent company. It says a lot about PostNuke and a lot about
pnFlashGames that a company not involved with PostNuke would see enough
potential and value in a module project to invest like they have done. Best
of all, I still run the project and it is still open source. :) For full
details you can go to the press release on
pnflashgames.com.

What should users of your module regard?
Well, the weakest part of my module is the pnHTML I think. However, I have
addressed that in the short term by using CSS classes in the output whenever
possible and documenting how to use them to customize their look and feel.
I think they are happy with that for now. Eventually I'll port it to
pnRender, but its going to be a lot of work. The strongest part of
pnFlashGames is the traffic generation that comes from it. People like
being on the score board and they will come back to check and make sure
their rank is held. pnFlashGames is an automatic community builder. I
think it is even more effective than a forum because more people will play a
game than post in a forum. Every feature I write is done with that thought
in mind.

Thank you very much for your patience

Generated on January 14, 2005.

New Permissions Module for PostNuke   (News)

interested in the topics related to the site. The module itself can be found at >http://noc.postnuke.com/projects/bscipermissions.

The current version of the module is designed to use Xanthia and pnRender. The production site is not currently using Xanthia since it hasn't been officially released yet. You can find Xanthia >here. I would put up a link to my dev box where you could see this latest version, but it is on a dynamic ip address that changes every couple of hours so it is out of the question. The solution....Install it yourself and give it a try.

Access to the various modules is defined by group. Anonymous, Registered User, Admin, or any any other group that you have defined in the Groups module of PostNuke (NS-Groups). If you want a certain group to have access to a module you just go to the BSCIpermissions Administration section and choose the module. Then put a check next to each group that you want to be able to access the module. It's that easy. If you want to temporarily disable access to a module on your site, just remove all the checks for each of the groups for that module. You can set the permissions on a module so that it can only be accessed by an admin. This allows you to install a module and test it's functionality without giving every user access to the module until you know that it works properly.

You may be asking yourself why you would need this module. You may be saying to yourself "PostNuke already has a permission system it doesn't need another one". To that I would suggest that you try and configure your system to not allow anyone but registered users to access the News module on your site. How about any other 3rd party module that hasn't implemented the PostNuke security system. The ability to grant/deny access to a part of your site shouldn't be limited to the ability of the module designer. Do you know they wrote the module correctly? Are you sure they put the appropriate checks in place for each function? What if they didn't? Do you really want to leave that up to the developer? The BSCI Permissions module leaves the control in the hands of the Systems Administrator where it belongs.

Don't get me wrong. I like the flexibility of the current PostNuke permissions system. That is why I wrote this module to work in conjunction with it. The BSCI Permissions module isn't meant to replace the current permission system. It is meant to enhance it. It is meant to plug the holes that exist in the current system since the current system can't be used to allow/block access to all PostNuke modules. (Since all modules don't implement the PostNuke permissions system.) Even if a module correctly implements the PostNuke permission system it is a difficult system to learn to correctly operate as a Systems Administrator. How many posts have we seen in the forums by people who can't figure it out. The BSCI Permissions system has been designed to be simple enough that even someone who is using PostNuke for the first time can figure it out in a matter of minutes.

Download the files, Read the install file and then take control of your site. See for yourself if it is as easy as I say. I personally think it should be part of the Core PostNuke system. What do you think? Install the files, take it for a test drive and post your comments. What would you change? What would you add? Do you agree with me that it should be part of the Core or do you think it is better to be an add-on? Keep in mind that the module requires that you add approximately 11 lines of code to your main index.php file and your modules.php file. In order to protect ALL modules there needs to be code in the files that load the modules. This is why I think it should be part of the Core. The System Admin should be able to use the system without needing to modify their index.php and modules.php files. The overhead of not using the system is a single call to see if the BSCI Permissions module is activated or not.
Test it out. See if it isn't as easy as I say it is. Once you've used it you won't want to go back.
Chris Mille

Generated on January 27, 2004.

Open Source Content Management Systems Make E-commerce Websites Affordable   (News)

rmation the staff had gathered and uploaded, and most of their cash reserves—because the custom developer failed to backup the site.

My first concern was how computer savvy and organized this client was. If she was going to require a lot of training and hand-holding, even implementing an open-source solution would cost more than her budget would allow. So I sent her a number of questions to answer, such as:


What kind of site do you need developed?
How did you choose php?
Is an admin interface required?
Do you need to manage banner ads?
What are your support requirements after implementation?”



After she ‘passed my test,’ I told her that I thought she’d have difficulty programming the site from scratch for $4-5,000, even in India. Then I told her that from her requirements, she was ‘re-inventing the wheel.’I told her that there are numerous free open source CMSs with all of the functionality she needed and then some. I told her that by using this approach, I could deliver a fully functional site by the end of the year within the budget she specified.

Within hours, I received a request for an in-person meeting. Because this client had a clear idea of all of the components and capabilities she wanted, I was able to recommend a comprehensive solution that would address all of the issues her specifications raised. This saved a lot of time and expense, as well as made my job much less frustrating.

After the meeting, I sent the PostNuke (http://www.postnuke.com/) manual to the client for review. I recommended PostNuke because it provides full CSS support, HTML 4.01 transitional compliance, and an advanced blocks system. However, she astutely pointed out that, according to the documentation, unique block/page configuration for multiple pages isn’t possible—a stringent requirement for the DoctorVAR.com implementation.

By examining other PostNuke site installations and reading PostNuke.com forum discussions, I quickly figured out that multiple PostNuke installs would work around the page layout problem and provide complete control over the subsite blocks. A PostNuke subsite is an additional installation of PostNuke within the ‘main’ PostNuke installation. For example, if the main PostNuke installation is installed under ‘/htdocs/postnuke’, a subsite would be installed under ‘/htdocs/postnuke/subsite1’.

Each subsite has the ability to be configured completely separately from the main PostNuke installation. This allows the administrator to manage separate topics as their own distinct ‘subsites.’ DoctorVAR.com is configured to share all information between the subsites except for the subsites’ block configuration. Subsites are configured to maintain their own block layouts—thus each page can be laid out uniquely.

The client wanted to use html blocks to handle the bulk of the content since she thought the PostNuke articles feature would be tedious to maintain. However, PostNuke only searches major modules, not html pages. To resolve the html layout and search issues, I integrated a PostNuke module called Content Express (http://pn.arising.net/ce/). This module provides the site with a very friendly admin interface for adding html pages and controlling the site navigation, as well as a search engine for html pages. However, Content Express wasn’t built for multi-site configuration, so I had to figure out what it was doing to know how to integrate it for the multi-site solution.”

To complete the site, I integrated free PostNuke modules to provide an ezine, forum, job bank, and banner/ad management. Within two weeks, my client was laying out pages and uploading data. And by the end of two months the DoctorVAR.com site was up—within her budget and without sacrificing one feature or requirement. The only software she had to purchase was a classified ads module and shopping cart for $59, plus a $30 theme. The rest of the modules were free.”

The flexibility, performance, and ease of administration of the DoctorVAR.com (http://www.doctorvar.com/) implementation is a testament to how robust and cost effective open source CMSs are.”

Additional Resources:

PostNuke.com (open source weblog/content management system) http://www.postnuke.com/

Content Express (open source Web content management system) http://pn.arising.net/ce/

WhatsNews (open source ezine module) http://nuke-modules.gading.de/

phpAdsNew (open source ad server) http://www.phpadsnew.com/one/

phpBB (open-source bulletin board package) http://www.phpbb.com/

phProfession (open source job bank) http://www.phpsolutions.co.uk/index.php

DoctorVAR.com Website Content/Stickiness Articles http://www.doctorvar.com/subsite8/?mid=12#stickiness/

DoctorVAR.com Web Presence Articles http://www.doctorvar.com/subsite27/?mid=22#WebPresence/

Web Marketing & E-Commerce http://www.wilsonweb.com/

Apromotionguide.com - Free website promotion tutorial http://apromotionguide.com/


Linda Christie, a freelance writer based in Omaha NE, is the Executive Editor for DoctorVAR.com.

Generated on April 23, 2003.

PostNuke CMS Make E-commerce Websites Affordable   (News)

e said. “So I started planning my site by analyzing how sites keep me coming back. Good content is the primary draw, but what else?”

Analyzing Website Assets and Annoyances

After a few days of surfing her favorite haunts and examining sites she’d let fall by the wayside, Christie came up with a laundry list of characteristics that she liked: short, easy to remember and descriptive site name; clear focus and organization; easy navigation; free and meaty content; plus links to additional resources.

She also identified a number of annoyances that sent her running to another site: multiple broken links, signup required to access content, popup ads, outdated content, poor navigation and/or search capability. And her number one complaint—locking you onto the site by disabling the browser back button!

Website Do’s and Don’ts

Then she went one step further and read numerous articles on what other people look for. “These articles strongly influenced not only what features were incorporated, but where they are placed,” Christie said. “For example, privacy and the ability to contact a real person are top priorities for many site visitors. So I placed both in the top navigation bar for easy access.”

She also discovered that the best sites are designed to involve visitors—to invite them to contribute content, give feedback, voice their opinions, and exchange information with and help each other. “To improve the ‘stickiness’ of the site, we expanded our plan to include a forum, polls, contributing content, free classifieds and a job bank. I also redesigned my e-newsletter tone to make it more personal, as well as to make subscribers come to the site to read the full story or fill out an opinion poll.”

Custom Development Gone Wrong

After talking to several Web developers, Christie chose a developer offering a custom designed PHP solution using SQL databases to store thousands of stories and favorite links. However, two months into the project, it became evident that the developer didn’t have adequate programming staff to launch the site within the promised three-month schedule. Unfortunately, Christie felt she had few alternatives. “I’d already spent hundreds of hours working on the site design and adding thousands of favorite links and articles to the database—work that would be lost if I changed vendors.”

Three months later and one week before launch, the site went down. The next day it was still offline, even the backend admin area. Then the dreaded call came: hackers had broken into the server hosting facility. “What about the backup? I asked.”

“The last backup file was corrupted,” was the answer. A two-month old zip file didn’t match the current software version, making site restoration almost impossible—but they said they would try. “At this point, I lost all confidence in the developer—not to mention over five-thousand records I’d uploaded,” Christie said.

Searching for a New Solution

Christie wasn’t sure what to do. “I couldn’t afford the time or money to start coding the site from scratch. I knew I would be shopping for champagne on a beer pocketbook of $5,000,” Christie said. “But I didn’t want to compromise unless I had to.”

Christie began searching online for a new developer. Soon, one of the people she contacted emailed her a slew of probing questions.

What kind of site do you need developed?
How did you choose PHP?
Is an admin interface required?
Do you need to manage banner ads?
What are your support requirements after implementation?”


“I felt like I was taking a test,” Christie said. “But the quality of his inquiries gave me confidence this person wanted to clearly understand the scope of the project, as well as my level of expertise to manage the site.”

Soon Christie scheduled a meeting with Scott Kroeger, owner of Hudson Avenue Technologies in Omaha NE, to discuss the challenges of launching such a complex site on a limited budget. After Christie reviewed her well-documented site map and specifications with Kroeger, he recommended a proven and supported open source content management system (CMS): PostNuke.

“Many developers start coding right away,” Kroeger said. “Since my background is in integration, I get more excited about finding open source software, figuring out how the code works and then using my technical skills and coding to make the modules work together. This way I don’t have to spend a lot of time programming from scratch and debugging code.”

Integrating/Customizing Open Source Solutions

The two biggest challenges Kroeger faced with the PostNuke implementation were finding a site search solution and providing unique page layout capabilities for each major category or page.

“Linda wanted the flexibility of using html blocks to handle the bulk of the content,” Kroeger said. “However, PostNuke only searches major modules, not html pages. To resolve this issue, I integrated a PostNuke module called Content Express. This module provides the site with a very friendly admin interface for adding html pages and controlling the site navigation, as well as a search engine for html pages.”

Unique block/page configuration for additional pages isn’t supported by a single PostNuke install. By examining other PostNuke site installations and reading forum discussions, Kroeger quickly figured out that multiple PostNuke installs would work around the page layout problem and provide complete control over the subsite blocks.

“A PostNuke subsite is an additional installation of PostNuke within the ‘main’ PostNuke installation,” Kroeger said. “For example, if the main PostNuke installation is installed under ‘/htdocs/postnuke’, a subsite would be installed under ‘/htdocs/postnuke/subsite1’. So my challenge was to figure out how to make all 28 installs talk to each other by modifying what database tables each subsite looked at. I configured the subsites to maintain their own block layouts—thus each major topic category or subsite/page can be laid out uniquely. Also, Content Express wasn’t built for multi-site configuration, so I had to figure out what it was doing to know how to integrate it for the multi-site solution.”

To complete the site, Kroeger integrated free PostNuke modules to provide an ezine, forum, job bank, and banner/ad management. “Within two weeks, I was laying out pages and uploading data.” Christie said. “And by the end of two months the DoctorVAR.com site I’d dreamed about was up—within my $5,000 budget and without sacrificing one feature or requirement. The only software I had to purchase was a classified ads module and shopping cart for $59, plus a $30 theme. The rest of the software was free.”

Kroeger added, “Because Linda had educated herself on Website design and defined the site specifications so well, I knew clearly from the start what was expected. This made my job much easier, which combined with my open source integration strategy, saved her a lot of time and money.”

The flexibility, performance, and ease of administration of the DoctorVAR.com implementation is a testament to how robust and cost effective open source content management systems are for supporting robust e-commerce Websites.


For additional information about DoctorVAR.com visit their Web site at http://www.doctorvar.com.


Additional Resources:
DoctorVAR.com Website Content/Stickiness Articles

DoctorVar Web Presence Articles

Web Marketing & E-Commerce http://www.wilsonWeb.com/

Apromotionguide.com - Free Website promotion tutorial http://apromotionguide.com/

Content Express (PostNuke Module)http://pn.arising.net/ce/

WhatsNews (PostNuke ezine module)http://nuke-modules.gading.de/

phpAdsNew (open source ad server)http://www.phpadsnew.com/one/

phpBB (open source bulletin board) http://www.phpbb.com/

phProfession (PostNuke job bank module) http://www.phpsolutions.co.uk/index.php


Linda Freeman is a freelance writer based in Omaha NE.

Generated on March 15, 2003.

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