PostNuke

Footnote: 1

Potential candidates check list:

• A well-rounded understand of PostNuke. You need not be an expert in everything PostNuke, but you should be able to effectively administer, adapt and modify a PostNuke site.
• Able to reasonably read and write in English, as far as it pertains to PostNuke documentation writing. The key is reasonable; You do not have to master English writing, as content is more important over style. Contributing author's English will be edited for clear and concise grammar and usage.
• Able to work with a team. This may mean adjusting personal styles and viewpoints to the teams objectives. This also means to possess the ability to collaborate and construct ideas as a group member.
• Must have the time to work on such an extensive project. Yes, we offer flexible hours.
• Must be able to commit. Must be willing to commit. Also commitment is essential. And before I forget, we need someone who is going to commit to this project.

Benefits:

• Long hours and no pay
• Getting to contribute to the PostNuke project
• Having your name associated with PostNuke (Hey, you can put it on your resume)
• Development of friendship and camaraderie

Are you still interested? Well, if you are please send me a Private Message here on this site.

Include:

• Your name and PostNuke Handle (Nickname)
  
• Experience with PostNuke and related
  
• Your motivation for this project
• The amount of time you can give per week. Average.
• Any relevant information, you feel we should know about.
  
• Any spacial skills (related to this project) i.e. Technical Writer

Even though, we would like to accept all candidates to this project, we cannot. It is our intention to keep this project small enough to be manageable, yet large enough to be effective. I will be selecting only a few for final review and selection by the Steering Committee. Thank you in advance for your consideration to this project.

David Pahl -- Documentation Project Lead

Rebranding

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

EasyDist and the extension database

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

Release Manager

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

New Subdomains on postnuke.com

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

Documentation

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

Bug fixing weekend

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


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

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

Bernd Plagge (bplagge) is using PostNuke in Japan and has much experience with the gettext technology. Therefore he is going to play the main role in renewing the PostNuke language system for .9, we are glad to have an expert for these things onboard now.

Philipp Niethammer (philipp.ni) is already known as the author of pnBook, the first pnRender-based guestbook module. Recently he wrote several additions, i.e. a ListUtil for managing different types of lists (flat, nested aso) and FilterUtil for comfortable filter definitions including Pagesetter. His newest work is an interface for the logging system DBUtil provides so that one is able to manage the change history of a particular object. Along the way he also fixed some bugs in DBUtil and ObjectUtil, so we decided to get him into the team.

Thanks to both guys for their engagement and contributions to the project.

For this purpose Patrick and me will meet in Germany (near Osnabrück again) for these two days and work intensively on .8 (and maybe on .9 too). One slot is still available, if someone is interested in joining us, please contact me for details. Maybe Jorn can make a short stop when coming back from his holidays :-).

We did this several times before when working on pncommerce and out of our experience we know that such weekends are really productive and a valuable source for creativity.

For those who want to support this we will either create a Skype conference or an open IRC chat (not sure yet which one will make it), this will announced on time. So we can coordinate our efforts with those of other developers and you, the user.

Now is the time to check out .8 and see what is not working as expected. You can either add bugs on NOC as usual or, if you are not sure, tell us about this in the chat.

See you (or read you) on Oct. 6th/7th.

For example, from a gaming perspective, a guild or a clan can have have members on many servers within the same game and RosterMaster will accommodate this with different Rosters, and character to user associations, for each of those servers. Not 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 release.

At modulestudio.de you can see a nice example of what is possible with the separation of core an modules. You are able to point and click your own package - select some modules, chose a theme and there you have your very own package.

The easy distribution system will become part of pn.com and directly access the module database here. So that you are always up-to-date when you download your package. (BTW: They are not up-to-date now - it's only a beta!)

That is pretty cool, if you know what you need and if you know how to tie these modules together properly.

Become a Distributor
If you want to build a package that contains preconfigured modules with custom templates aso you should look into the wiki. There you find a description of a file that contains 2 functions. One function defines the modules that are to be installed and the other function can be used to call modules API function or any PHP function you like.

I this manner you can install your modules, configure them and fill them with demo content.

Finally you can replace the standard themes with some nice custom themes.

These distributions can then be included in Easydist as "Scenarios" or be distributed via your homepage or whatever you like.

Any questions? Comments? Critique?