Is there an official module naming scheme? pnMod[Name], PN[Name] et cetera

[from pnversion.php] $modversion['official'] official in what capacity? official from the PN dev team or a stable/published mod?


[from pnversion.php] $modversion['securityschema'] = array('Example::' => 'Example item name::Example item ID');
What does this accomplish? add a declaration of a security object and store it somewhere?

Are default perms set by PN or do you include that in the module itself?

How can I get a list/array of:
hookable functions
topics
sections

How do you set a $preformat/$info/$links['var'] for themes? an API, hook or hack? A way that's compatable with all the themeing engines would be nice, if that's possible.

How should database stored variables be handled, completely independent of the PostNuke tables, or is adding columns to existing tables tolerated?

OK so to try to answer the first question, if you plan on a public release of the module you should check into registration of the module to ensure the "NAME" is stored and not another module can take that name. I believe the standard is to name the module all lower case.

On to the schema this is what a admin would see when they go into the permissions modulke and select the "Component" link, kinda a direction to a site admin on how permissions are used throughout your module.

And for the permissions these are set via your functions in your pnuser & pnadmin files, set by the pnSecAuthAction() call. I would suggest you take a deep look at the Example module that MArk West has written as it really explains everything in detail.

Now for the rest of your questions I am really not sure on those, still new myself to the mod dev but I hope the above helps a bit.

-SUNADMN

Thanks sunadmn

After finding the registration page, a naming convention doesn't seem to exist, the official modules list [30] seems to be the choice of the author.

I've been enthralled with the example module for awhile, dividing and conquering, it's pretty well documented and the amount of tutorials on the subject its been less of a learning curve then I thought I'd face when first committing to the task.

Anyone with answers to the other questions, please don't be coy, I don't think I'll be the last one to ask; I wouldn't have thought I'd be the one asking for the first time. *sigh*

To answer the questions about topics, sections.

Firstly it's important that there are two module types in PN - API compliant and non API compliant. Each of these has different characteristics. non API compliant is where we are coming from and API compliant where we are going.

The non API compliant modules are a legacy from the PHP-nuke codebase from which PN forked. These can be identified by urls of the type modules.php?op=modload&name= and via admin.php/index.php files in the module directory.

These modules directly echo HTML within the module and manually include the header and footer. They offer no easy or standard method for exposing functions for other modules to access. Essentially they're stand-alone applications making use of some basic core functions and header/footer to display things within the site theme.

API compliant modules are the standard to which all PN modules should be authored and one to which any new developments by the PN team are being authored. These modules are characterised by urls of the form index.php?module=mymod&type=....&func= Furtyher these modules are characterised by the files pnadmin.php/pnadminapi.php, pnuser.php/pnuserapi.php These modules expose any number of API functions to gain access to that modules functionality and are called using the pnModAPIFunc core API.

The example module is the implementation of that definitive standard. The example module will be updated through each release to add demonstations of the new functionality added to the core and modules within that release (i've outlined in another thread changes to this module for .760). However the modules authored using an older example module (or even the previous template module) continue to run but, obviously don't make use of the newer features.

Now i've covered the background.... The topics and sections modules are, at this stage, non API compliant and thus are not the type of module that you can easiliy interact with. The simplest way would be to talk directly to the database tables. These modules will not be API compliant in .760 either.

Given the length of this post i'll add a further post about hooks a bit later.

-Mark

I think all of this is, is the kind of info that should be in the Module Development Guide (MDG) already. The last revision of the MDG was May 11th 2002, just seems very odd; I'm guessing the maintainers dropped it and noone has picked up the slack, its a shame.

Great bits of ambrosia there Mark, keep them coming.

I saw pnsearchapi.php in CVS, is this a .8 feature or will it be released in an upcoming .7xx release? Is the search API the only thing that's holding back releasing all the core modules as API-compliant?

I read on some other topic that the dev team was considering SVN, any progress made there?