PostNuke

Site search

Search results

Number of hits: 44

RosterMaster(PostNuke) 0.97 and TaskMaster(PostNuke)x .xx   (News)

only that, but the same guild or clan can also have different rosters for the different servers of the different games they play.

You will also be able to create rosters from either single user groups, or groups of user groups, as well as rosters of the entire user base (for controlled sites). If all works as I would like it to, you will be able to have a roster of user groups that acts like (using the above gaming environment example) another roster of that particular guild.

As should be obvious by now, roster objects will not be limited to any one 'Guild' as the last RosterMaster was and one can build many different roster objects based on many different roster needs.

The current architecture (NOT final) looks like this (I won't claim this is the best setup, but it works with my current aspirations):

ObjectTable MemberTable User(assoc.)Table
ObjectID(prime) ---------- ObectjID(idx) rmUID(prime)
ObjClass MemberID(prime) --------- MemberID(idx)
Name Name pnUserID
etc... etc. etc.

The ObjClass field of the Object Table is a suffix for the module object class called. In the case of Everquest II I used 'EQ2' as the value and named my classes PNRosterMasterEQII and PNRosterMasterEQIIArray calling them with a combination of DBUtil::selectFieldByID([ObjectClass by ObjID) and Loader::loadClasFromModule() with a derived php string as the 'base_obj_type'.

Along with this is a vars table with API functions that work identical to PostNukes' pMod[Get|Set|Del]Var() but requires an ObjID instead of modname so that different sets of vars can be associated to each roster object.

The logging functionality will also be ObjID oriented, and as such care must be taken when setting up logging as to avoid unnecessarily bloated log tables. Accordingly all loging will be set by default to 'off' except in the case of an upgrade from RosterMaster(PostNuke)0.96.

RosterMasters current status is a working upgrade script along with all the functionality of the 'main' RosterMaster display (although the func is now display (ya I'm learning)) for Everquest II. This includes table header reverse sort as well as advanced sort allowing two fields to be sorted in individual directions. The rest is forms and options. Once the EQII class is fully functional I'll begin to set up the other classes and refine the API.

My vision here is to have RosterMaster act as an extensible roster module suitable to organizing and maintaining roster and roster member profiles in association with, or indifferent to, the user base with consideration of user groups.

TaskMaster has the same goals but with reference to levels of accomplished tasks,

All of this has been made possible via PostNukes' 'adambaum' pre-release... this module will not work with anything prior and WILL BE COMPLETELY UNSOPPORTED until the adambaum release (other than beta testing).

Once the EQII class has been made fully functional I'll commit the project to the current PostNuke NOC project SVN for beta testing.

RosterMaster(PostNuke)0.97 and TaskMaster(PostNuke)x.xx naming policy will be dependent on the official release name of the adambaum

Generated on September 25, 2007.

pnMeeting 2007: Mark West talks about .8/.9   (News)

system information module will make it easier for webmasters to collect the needed information in case they seek help in the forums.

The use of Ajax makes the handling of various modules far easier. You can drag and drop permissions or user information fields. And on the user side you can for example rate a content item using the Ratings hook using an Ajax function and not having to reload the whole page after rating it.

The new URL system add permalinks to .8 and make URLs nice and readable as you can already find them in other systems like Wordpress. The permalinks can be defined by the administrator and can be included into other modules. It already works for example with the News module and the Pages module. The Pages module in the Value Addons package is the successor of Mark's htmlpages.

Included into the new Theme module is a Theme generator that creates all the basic files and file entries you need to start working on a new layout.

A real enhancement compared to .7 can be found in the block control - Blocks can be dragged and dropped into place and various block setups can be set not only for modules but for single content items.

There are still 2 or 3 major bugs in the bugtracker that are already partly fixed but which must be fixed before RC2 can be releast. That shouldn't take too much time.

In his outlook on .9 Mark explained that all Postnuke releases after Feburary next year will at least require PHP 5.2 - so ask your hosting providers early enough for updates. The background of this decision is the move towards object orientation in the Postnuke codebase and the fact that PHP 5 is around long enough now to become standard.

The language system is the last big project on the roadmap towards Postnuke 1.0 - other PHP projects will be evaluated to find the best solution. In the same move the internationalisation of content will be improved. Direct translations for content must be possible - News articles with the same ID in different languages are the result. Again getText was discussed as a possible solution and the move to UTF-8.

One of the most complex parts of Postnuke today is the Permission system. It is powerful yet often to complicated. So soultions have to be found to solve standard permissions requirements.

Axel Guckelsberger requested an addition to the hooks system - hooks don't know the permissions a user has for the item they are hooked into. So if you want to download a files that is attached to a forum post the permissions to download would result from the a) the permission of the user to view the thread and b) the permission of the user to download files. Hooks are today blind for this. Mark agreed that this had to be changed for future releases.

While talking about hooks Frank Schummertz requested more hook types. Currently we have display, transform, create, update and delete hooks. A required new type is the init or pageload hook that hooks into the start of the system like the spam prevention system BadBehaviour for example that stops the loading of the page if it detects a spam bot.

Mark Ronchera asked for the use of OpenID in future releases which Mark West answered by explaining the flexibility of the .8

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

Development Update, October 2006-04   (News)

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

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

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

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

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

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

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

Generated on October 10, 2006.

New Website Goes Live!   (News)

format. Each item should now only have one listing, whereas before there were often large numbers of articles to search through.

We've also moved one step closer to improving the documentation available for PostNuke. Any member of community.postnuke.com can now contribute to our documentation, and we would encourage you to do so. Through working together we aim to drastically improve the availablity of documentation for both users and developers.

Our forum support module has switched from PNphpBB to pnForum. This decision was taken for a number of reasons, mainly as the API compliant pnForum offers an easier platform for support through hooks. Common problem phrases in posts can now be autolinked to useful knowledgebase tutorials and wiki pages. Please note that the forum structure has been rearranged as a result of this move, and ensure that you are posting in the correct forum for your problem.

Finally, we think the new site offers improved navigation, content and functionality. We've tested fairly well, but if you do find any bugs in the new setup please post them in the forums.


Simon Birtwistle
PostNuke Steering Committe

Generated on May 2, 2006.

.8 Development Summary   (News)

New Theme Module
Recently, the new theme module, which acts as a replacement for Xanthia in the .8 series was committed to CVS. This module corrects many of the established flaws in the .7x Xanthia codebase and also provides new enhancements. New in this module is the ability to assign a custom template to any page on your website, the use of .ini configuration files in themes, the removal of block control in favour of a new Blocks module and the ability for theme authors to provide a 'version.php' file in their theme to provide relevant information to site administrators.

Using .ini configuration files in the new Themes module brings two advantages over the current setup of Xanthia. Firstly, theme generation and display are much faster as no database queries are required to build the layout. This should provide a marked performance increase in .8 websites. Additionally, it is much easier for theme authors to export their themes, as in the new Theme module the details previously contained in xaninit.php in PHP code are now automatically generated by the Theme module.

Due to the sweeping changes in this new module, the user interface has been completely redesigned. While we realise this will take some getting used to, the new interface is more intuitive than previous versions and logically follows the layout of the Modules module when displaying the available themes. Additionally, all theme related settings have been moved from the Settings module to the Theme module, and the user theme switcher is now part of the Theme module display.

Themes used under the .7x Xanthia module will need upgrading to use the new .8 Themes module. This is a relatively simple process which is mostly handled by the Themes module itself, as both systems are based on Smarty the template logic is the same and there are few changes to the tags themselves. These by and large stay the same with one notable expection, block tags are replaced with the plugin call where name is the name of the block zone to display.

The recoded Blocks module has yet to be checked into CVS, however we anticipate this within the next week. Until that time, the Theme module in CVS is nearing completion and is fully functional.

New Themes / Removal of Old Themes
Two new themes designed for the new Theme engine have been added to CVS. These are free templates from Open Source Web Design, and serve as an example of what can be achieved with the new module. The new themes are tableless and HTML compliant, which along with the improvements in compliance in the rest of the codebase serve to ensure PostNuke remains one of the few content management systems to take HTML standards seriously. All output in .8 will be XHTML valid.

To this end, the old themes that have been present throughout the .7x series are no longer in CVS. While they can be easily converted to work with the new Themes module, they use table based layouts which do not conform to the standards PostNuke has set for output. A appearence overhaul is well overdue for the PostNuke codebase and so a set of new themes will be available with the .8 release.

Workflow Engine
The release of .8 will also bring a new statebased XML Workflow engine to PostNuke with simple API implementation. Additional enhancements are planned to include a workflow schedular to process workflows at timed intervals in batches.

Use of the module is simply a case of adding a directory 'pnworkflows' to your module containing a set of workflows with operations, states and actions. The workflow engine also fully supports the PostNuke permissions system. Documentation for the module will be released with the first .8 Milestone.


XML Event Based Forms
GuppyForm allows a developer to describe a form content and layout in XML with an event handler bringing automatic validation. This can drastically reduce the time taken to develop user input forms. Can be combined with pnRender templates or used standalone. For those that like OO, and descriptive coding, this is an interesting option in the framework.


Completion of Users Module and Profile Enhancements
Another recent change to CVS are updates to the Users and Profile modules. These now almost fully functional, with huge improvements to the dynamic data system now in CVS. New field types avaiable for user input are date fields, calendar 'select date' fields and combination fields where a number of seperate input types can be combined. The new users module also allows for the use of SHA-1 or MD5 password encryption, you can store the user's last login date in the database and finally the registration process has been improved to include the option to vaidate user's email addresses through an activation link. All these improvements are optional and can be enabled and disabled through the Users module administration interface.

Template Updates
As part of an overview of usability and update to the 'look and feel' of PostNuke many of the module templates have been enhanced. These range from subtle changes to much more obvious improvements in the location of links and reporting of status messages. As previously mentioned all templates validate to XHTML standards and further improvements will be made before the final release of .8.

Languages Changes and config Directory
pnDefineMachine is now the recommended tool to use for translating PostNuke into other languages. This third party module scans the whole codebase for language defines and provides an easy to use administration form for translators to write new language files. A new version of pnDefineMachine was released recently, and to facilitate its future development a number of internal define changes have been made. These should not, however affect translators themselves.

Another addition which does affect translators and site administrators is a global language file which can be edited by users and is safe from being overwritten on an upgrade. PostNuke now contains a 'config' directory where all PostNuke's configuration details are stored. The files config.php and config-old.php have been moved to this directory, and furthermore the directory can contain both global template overrides (in addition to theme-specific overrides in use in .7x) and also global language defines. While it is not currently possible to override core language defines through this change without generating a PHP Notice, you can store your own language defines for use in, for example, themes. Any changes you make here will then remain intact throughout any upgrades you may carry out.

.8 Milestone Release Date
After the Steering Committee Meeting held this Tuesday, a tentative release period for .8 Milestone 1 has been set. We currently aim to release .8 MS1 in the third or fourth weeks of April, however this may change if the codebase requires further work for the release to be of the required quality. A milestone release is an opportunity for third party module developers to test their modules with the upcoming release. It is not intended for a production environment and user support is not available for this release, however support for developers will be provided through the forums. The milestone will not be feature complete, and may not be stable.

The milestone can be taken as an indication that the codebase is beginning to get to a usable stage from which we can work towards

Generated on March 31, 2006.

pnSEO - Postnuke Search Engine Optimization: Strategies and Methods   (News)

is not right. When I was reading an article in postnuke forum, the term seo came up. That's the time I started working on pnSEO.

I implemented some strategies one Sat. morning at 9:00am and have a tour of Washington DC. When I came back at 11pm, the ranking jumped from page 13 to page 1. What a surprise!

The following are the strategy I developed for promoting CCUS. Hope it is helpful and useful.

Read this: http://www.google.com/webmasters/seo.html

2. Attitude: technique and marketing 20/80
Marketing is crucial to the success of your web site. pnSEO is part of marketing.

I would guess most people in pnCommunity will be like me: technical. Work on technical and enjoy to be technical. We may have spent 80% of our time on technical side. Setup the site, upgrade, add new functions, customization. Make the site look nice. But that's not the most important.

Do you have this experience: you work hours or days to add one module or add one function, or improve the interfaces, but no users are actually cared about it at all. This happened to me many times.

Before you start working on your web sites, think about effective and efficient. You are smart and hardworking, you maybe efficient, but are you working on the right thing (effective)?

Now 80% of the time should be spent on marketing. Start with pnSEO first.

3. Strategies

The following strategies are listed in the order of importance in my understanding.

SEO 1: SITEMAPS and Google Sitemaps.

This is the #1 strategy you should adopt. If you cannot do anything else, do this one.
It will overcome the shortcomings of CMS or dynamic sites such as Postnuke for search engines. It will let search engines to understand how your site is accessed by visitors.

"If your site has dynamic content or pages that aren't easily discovered by following links, you can use a Sitemap file to provide information about the pages on your site. This helps the spiders know what URLs are available on your site and about how often they change." -- google.com

1.1 Create sitemap using google sitemap generator.
. http://www.google.com/webmasters/sitemaps/docs/en/about.html
. Setup a schedule to resubmit your sitemap to google.

1.2 Use snakeseo to generate sitemap for Postnuke site.

SEO 2. use ShortURL and Remove session ID
Even yahoo.com is using short URLs. See http://news.yahoo.com/s/latimests/middleclassexilesstruggleforafoothold
2.1 Use shortURLs.
2.2 Enable Xnathia theme and enable shortURLs.
2.3 Remove session IDs from your postnuke site.

SEO 3. Title and Metadata
The page title weighs heavily in the algorithms of all the major search engines, so be prepared to spend some time on it.
Page title should be accurate, keywords-rich.
Do not include stop words (and, the, a etc.) in the title. That just wastes space.

Meta tags may not be important as before. However, some search engines still looks at meta tags.

3.1 use pnTitle to make page title relevant to the page content
3.2 use pnMeta
3.3 use Xanthia theme

SEO 4: Directory submission
4.1 Submit to ODP
4.2 Submit to Yahoo
4.3 Submit to other directory services
4.4 Submit to all kinds of search engines

SEO 5. Exchange links with top PR (page rankingweb sites. (LINK100)
5.1 use Web Links module as a repository for all external web links
5.2 Find similiar sites using keywords. We use 'Chinese Community'. ALso try using "Suggest a Link + your keywords"

5.3 Request the webmasters to include anchor text, title that reflect the keywords you are promoting
e.g. Chinese Community
instead of http://www.ChineseCommunity.us

SEO 6. Publish Blogs.
Expand the existence of your web sites in the world wide web. Let it appear in as many places as possible.
6.1 Yahoo - http://360.yahoo.com
6.2 Google - blogger.com
6.3 MSN - spaces.msn.com
6.4 CCUS - blog.chinesecommunity.us

SEO 7: RSS (feeds) submission

SEO 8. Write and Submit articles to many sites, forums, discussions.
Write down the techniques, tips, strategies, experience you have into articles. In your artciles, you can have some links to your web sites. Also your website and keywords as part of your profile.

8.1 postnuke.com. Get involved with pnCommunity. Contribute your knowledge, experience, thoughts to the growth of the community.
8.2 ezinearticles.com

SEO 9. Develop modules/utilities for others to use.
9.1 Join pnCommunity to contribute
9.2 Put your module and URL on their web sites.

SEO 10: Page design

Try to develop some common sense that will help search engines.
10.1 All web links inside have titles and appropriate anchor text
example: ChineseCommunity.us should be changed as
Chinese Community .us
Why? Title include some keywords I am promoting for Chinese Community.us. Anchor text has "Chinese Community" as keywords. Search engines are very sensitive to title text and anchor text.

10.2 All images should include descriptive, keyword-rich alt text.
Don't make it very long though.
e.g.

instead of


10.3 Internal links

1) Every page on your site should link to at least one other page.
2) Include anchor text and title text for your internal links. They should contain appropriate keywords you are promoting.
3) e.g.
go to <a href="http://www.chinesecommunity.us" title="Chinese Community">Chinese Personal

Generated on September 10, 2005.

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.

Hardening The Security of Your Website   (News)

the webserver itself. There it analyses all requests coming to the webserver and checks them against a set of definable rules.

If the request passes all these checks then the page is served to the end user. If there is a match then ModSecurity can take a number of actions, including doing nothing, logging the request, or simply denying the request with an error message.

I highly recommended ModSecurity as a tool against hackers, it says it has a slight performance hit but in my testing it wasn't noticable at all. Obviously ModSecurity is only for those people who have root access to the server where their site is hosted, as it's a plugin module for Apache.

It's really a layer 7 firewall for your webserver and it does an excellent job. I've had a number of people try to exploit a website I run with a PostNuke hack (now fixed by the recent patch), it was stopped by ModSecurity though because the exploit when it connects to your site doesn't send a browser version and I had ModSecurity configured to deny all attempts to connect if no browser version was present.

Setting it up is quite easy, there's a few basic filters that come with it out of the box but you'll want to modify those and add new ones as you see fit.

I won't go into anymore detail here, if you're interested then please take a look at the ModSecurity website, it has everything you need to get ModSecurity setup and working to your needs.

Finally, another tool for those of us using Linux to serve up their PostNuke sites is a kernel patch called grsecurity. I won't go into all of it's features but it really is a brilliant piece of code. Should your webserver get hacked, grsecurity properly configured would make it very hard for the hacker to get themselves a rootshell or install any backdoors. If you understand how to compile your own Linux kernel you should really look at this patch, I use it on all my production servers.

I hope this short article will help some of you with the security of your PostNuke sites.

Regards,
Ti

Generated on April 28, 2004.

Interview: Jørn Lind-Nielsen on his new module "Pagesetter"   (News)

evolve out of some special need, or how did you get the idea? What was the impulse to start a completly new and complex module?

The seed for Pagesetter was laid shortly after I started working with PostNuke back in the summer 2002. I needed a setup where I could let non-admins describe the mountaineering courses our web site promotes. Soon I discovered Content Express. It did the job, but you had to be very very carefull in order to make all pages look identical, and it was still difficult to get non-techies to do the job (which it may still be in Pagesetter?). Since then I have always been wanting a module that let me ("me me me" as Mr. Anderson would have said) define the database fields and layout, but still, of course, with all the fancy features of a module like Content Express. The same applies to PagEd which also is a really nice content module.

The final push came when I saw Xaraya's article system. At that point I was ready to convert Photoshare to Xaraya. But then something (I actually don't remember what) turned my mind on Pagesetter. Bang! I didn't have time for it at that point, it was awfull, and my mind was completely filled with all the stuff you could implement in such a module (I don't care much about what you can use it for, it just have to be fun implementing it - typical for my mindset).

In the last interview you told us, that you are doing 99% of the work on your other module, a gallery called Photoshare. Did you find any help for pagesetter? I read for example about a member of the pnCommerce project working on an import/export for pagesetter.

Yep, this time a have gotten a lot of input from Sebastian (pnCommerce) and Jörg Napp (core developer). Both have supplied code snippets and been very kind to answer my pnRender and Smarty questions. I have although not heard anything about a pnCommerce integration. Other people like yourself have
also been very kind to supply both ideas and code snippets for things that are needed. But as a whole Pagesetter is still a one man's show. Not that I don't need any help, it's just that I have so many specific ideas that I really really want to implement - myself.

Since pagesetter 2.0.0 you make use of the new postnuke templating system (Xanthia Templating Engine) based on smarty. How do you like working with it? What problems occurred?

The templating system works really well and is quite simple to use. Smarty took me a few hours in the initial version of Pagesetter and after that pnRender worked as a charm. A pnRender compatible module is really cool to work with. The complete control of layout it gives to the administrator is fantastic.

What happens to Photoshare? Is it more or less ready and it doesn't require much work anymore?

Yeah, what happens to a module when focus changes? It is obvious that I don't spend much time on it now. It does all I need it to, and a bit more, so there's no rush for me to do much for it. But Photoshare is still on my mind, and there are quite a few features that I want to implement. I keep saying "I'll just fix this thing in Pagesetter, and then ...", but (unfortunately?) I always get another idea for Pagesetter and fails
misserably to come back to Photoshare.

Thank you very much for this update on your work.

Homepage: http://www.elfisk.dk

Generated on December 28, 2003.

Page 1 / 5 (1 - 10 of 44 Total)