PostNuke
Flexible Content Management System
News
Postnuke Verified Module program
Question and Answer
Q: What does the term "Verified Module" mean?
A: Basically, the term "Verified" replaces the old term "Official" so now in place of "PostNuke Official Module" the term will be "PostNuke Verified Module".
Q. Is module verification required?
A. No, it is optional. The developer must request verification.
Q: Why the change?
A: The verification process will allow our community an easier way to find quality modules and will ensure compatibility with future releases of PostNuke.
Q: Why use the term "Verified"?
A: The word "Verified" just fits well with the process, of registering your module name, and developing under the API standards that have been set down, again all to ensure that your module will work with all future versions of PostNuke.
Q: Who tests and examines the module?
A: The Modules QA manager and staff administer the verification program.
Q: What do you examine for during the verification process?
A: The <a href=http://centre.ics.uci.edu/~grape/modules.php?op=modload&name=Wiki&file=index&pagename=Verified%20Modules>Verification Standards document describes the standards and it can be found on the Documentation Central site. We've included the current version below.
Q. What will I have to change in my modules?
A. You should not have to make any changes if you followed the PostNuke Modules Developer Guide.
Q: Why would I want my module to be "Verified" by the PostNuke team?
A: We presume that Verified Modules will have broader community acceptance.
Q: Will PostNuke only run with Verified Modules in the future?
A: No. PostNuke recommends Verification for modules, but it does not enforce it. Module authors are free to make their own choice about
verification.
Q: Why does Verification test for design standards?
A: Modules that meet these design standards will allow compatibility with future versions of PostNuke. This means fewer problems in the future and easier upgrades.
Q. Why do we require a Verified Module to be Open Source and reside in the PostNuke Modules CVS?
A. We want to ensure continunity. These criteria allows someone else to support the module in case the original developer departs
Q. Does the verification program include commercial modules?
A. Not at this time. Adding commercial modules will be considered later.
PostNuke Verified Modules Criteria - Version 1.0
Proper Documentation
Documenting your module is a vital step. There are three areas in which your module may need documentation: webmaster, user and code documentation.
The webmaster and user areas are covered by producing manuals and placing them in the appropriate place in the directory hierarchy (below). Webmaster information tells how to install, configure and operate the module. User doeumentation tells the end user how to use the module.
Code is covered by writing a short description of each function, noting the parameters and return values that it has, and placing that at the head of the function. Writing the code documentation in the style of PHPDoc (http://www.phpdoc.de/) will allow for automatic parsing of the documentation by other developers who wish to use your module.
Software Design
The module software will be examined to ensure proper design standards were followed. We look at:
Reserved Variable Names
A number of variables are reserved by PostNuke. These variables must not be duplicated within modules as they will conflict with the PostNuke core and cause unpredictable results. The current list of variables which are reserved can be found in the PostNuke Modules Developer Guide.
Module Directory Structure
A PostNuke module has a very specific directory structure. This allows the PostNuke System to use a generic system to access all modules without needing to know specific information about each separate module that is built. Following the directory structure as laid out below is an absolute requirement of any PostNuke compliant module.
Note: Extra files and directories in addition to these shown below are allowed. Also, if any of the files below are not required (eg. the module does not have database tables of its own so it does not require the pntables.php file) then they do not need to exist. However, files that perform the functions outlined below must comply with the file naming convention to allow the PostNuke system to load the suitable files at the appropriate times to ensure correct operation of the module.
Note: This shows the example layout that a gallery module might have. Other modules will have different names for their top-level directory and blocks as appropriate for their specific functionality.
modules/ [1]
gallery/ [2]
docs/ [3]
credit.txt [4]
install.txt [5]
changelog.txt [6]
licence.txt [7]
pnadmin.php [8]
pnadminapi.php [9]
pnblocks/ [10]
snapshot.php [11]
pnimages/ [12]
admin.jpg [13]
pninit.php [14]
pnlang/ [15]
deu/ [16]
admin.php [17]
init.php [18]
manual.htm [19]
snapahot.php [20]
user.php [21]
eng/ [22]
admin.php [23]
init.php [24]
manual.htm [25]
snapshot.php [26]
user.php [27]
...
pntables.php [28]
pnuser.php [29]
pnuserapi.php [30]
pnversion.php [31]
[1] The top-level directory in PostNuke for modules
[2] The directory that contains all of the module code (in this case the Gallery module is name "gallery"). This directory name must be lower case. You must also register your module name at http://centre.ics.uci.edu/~grape/modules.php?op=modload&name=Wiki&file=index&pagename=ModReg and obtain a module ID number.
[3] The directory that contains all of the module documentation
[4] The file that contains all of the credit information of the module
[5] The file that contains all of the installation instructions of the module
[6] The file that contains all of the changes to the module since the last release
[7] The file that contains all of the license information of the module
[8] The file that contains all administrative GUI function for the module
[9] The file that contains all administrative operational functions for the module
[10] The directory that contains all blocks associated with the module
[11] A file that contains a block associated with this module; in this case it displays a random snapshot from a gallery
[12] The directory that contains all images for the module
[13] The image for the administration icon of the module
[14] The file that contains initialization functions for the module
[15] The directory that contains all language translation files for the module
[16] The directory that contains all German language translation files for the module
[17] The file that contains German language translations for the administrative GUI functions of the module (i.e. pnadmin.php)
[18] The file that contains German language translations for the initialization functions of the module (i.e. pninit.php)
[19] The file that contains the German language translations for the manual for the module
[20] The file that contains the German language translation for the snapshot block
[21] The file that contains German language translations for the user GUI functions of the module (i.e. pnuser.php)
[22] The directory that contains all English language translations files for the module
[23] The file that contains the English language translations for the administrative GUI functions for the module (i.e. pnadmin.php)
[24] The file that contains the English language translations for the initialization functions of the module (i.e. pninit.php)
[25] The file that contains the English translation of the manual for the module
[26] The file that contains the English translations for the snapshot block
[27] The file that contains the English language translations for the user GUI functions of the module (i.e. pnuser.php)
[28] The file that contains all information on database tables for the module
[29] The file that contains all user GUI functions for the module
[30] The file that contains all user operational functions for the module
[31] The file that contains all version and credit information for the module
Use Standard Function Names
There are a number of function names that are considered standard i.e. they have well-known meanings and are used in a number of modules. Using the standard function names makes it easier for other module developers to use your module. See the PostNuke Modules Developers Guide for a complete list.
Calls to pnModCallHooks() in all appropriate locations
Use pnAPI
pnAPI is the PostNuke Application Programming Interface, a way for modules to interact with the PostNuke core without needing to access tables and internal structures directly. The API also allows for the underlying implementation details of PostNuke to be hidden from a developer so that they can write modules in a standard fashion and not worry about what it might change under the hood. This is very important for a system such as PostNuke which has undergone, and continues to undergo, radical changes in the core design to allow it to be faster, more secure, and more flexible.
pnAPI is the only supported way of accessing core information. Module developers must use these methods of obtaining information from the PostNuke core system; failure to do so will very likely result in the module not working when the next version of PostNuke is released.
Output
All output generated by module functions must be returned to the PostNuke core. No output of any type should be made directly from the module; doing this is not supported and will break in future versions of PostNuke.
All output should be parsed through pnVarPrepForDisplay() or pnVarPrepHTMLDisplay()
All suitable output censored by pnVarCensor()
No echo or print statements used
Global Variables
If your package needs to define global variables, their name should start with a single underscore followed by the package name and another underscore.
Security
All operations protected by pnSecAuthAction()
All form results protected by pnSecConfirmAuthKey()
All form variables obtained by pnVarCleanForInput()
All variables in SQL queries protected by pnVarPrepForStore()
All variables in filesystem access protected by pnVarPrepForOS()
All directories have an empty index.html file present
Continuity
The following requirements exist to ensure that Verified Modules can continue even if the original author abandons the module and vanishes.
The source code must reside in the PostNuke CVS.
Licensed under the terms of the GNU General Public License or another Open Source License.
Uses Pear coding standards (http://pear.php.net/manual/en/standards.php)
Database Usage for Modules
ADODB database abstraction (a way for PostNuke to support multiple database types such as Oracle, Postgres and ODBC)
All fields must be prefixed to prevent problems with reserved words
All table names must not be a database reserved word.
Testing
Installs / Uninstalls without problems
No obvious bugs
No detectable security exposures
Support
Module has support from developer(s)
Commercial Modules
We've not received any requests to certified commercial modules and will handle them individually. Some criteria (ie: CVS, Open Souce license, etc) may not apply to commercial modules.
Q: What does the term "Verified Module" mean?
A: Basically, the term "Verified" replaces the old term "Official" so now in place of "PostNuke Official Module" the term will be "PostNuke Verified Module".
Q. Is module verification required?
A. No, it is optional. The developer must request verification.
Q: Why the change?
A: The verification process will allow our community an easier way to find quality modules and will ensure compatibility with future releases of PostNuke.
Q: Why use the term "Verified"?
A: The word "Verified" just fits well with the process, of registering your module name, and developing under the API standards that have been set down, again all to ensure that your module will work with all future versions of PostNuke.
Q: Who tests and examines the module?
A: The Modules QA manager and staff administer the verification program.
Q: What do you examine for during the verification process?
A: The <a href=http://centre.ics.uci.edu/~grape/modules.php?op=modload&name=Wiki&file=index&pagename=Verified%20Modules>Verification Standards document describes the standards and it can be found on the Documentation Central site. We've included the current version below.
Q. What will I have to change in my modules?
A. You should not have to make any changes if you followed the PostNuke Modules Developer Guide.
Q: Why would I want my module to be "Verified" by the PostNuke team?
A: We presume that Verified Modules will have broader community acceptance.
Q: Will PostNuke only run with Verified Modules in the future?
A: No. PostNuke recommends Verification for modules, but it does not enforce it. Module authors are free to make their own choice about
verification.
Q: Why does Verification test for design standards?
A: Modules that meet these design standards will allow compatibility with future versions of PostNuke. This means fewer problems in the future and easier upgrades.
Q. Why do we require a Verified Module to be Open Source and reside in the PostNuke Modules CVS?
A. We want to ensure continunity. These criteria allows someone else to support the module in case the original developer departs
Q. Does the verification program include commercial modules?
A. Not at this time. Adding commercial modules will be considered later.
PostNuke Verified Modules Criteria - Version 1.0
Proper Documentation
Documenting your module is a vital step. There are three areas in which your module may need documentation: webmaster, user and code documentation.
The webmaster and user areas are covered by producing manuals and placing them in the appropriate place in the directory hierarchy (below). Webmaster information tells how to install, configure and operate the module. User doeumentation tells the end user how to use the module.
Code is covered by writing a short description of each function, noting the parameters and return values that it has, and placing that at the head of the function. Writing the code documentation in the style of PHPDoc (http://www.phpdoc.de/) will allow for automatic parsing of the documentation by other developers who wish to use your module.
Software Design
The module software will be examined to ensure proper design standards were followed. We look at:
Reserved Variable Names
A number of variables are reserved by PostNuke. These variables must not be duplicated within modules as they will conflict with the PostNuke core and cause unpredictable results. The current list of variables which are reserved can be found in the PostNuke Modules Developer Guide.
Module Directory Structure
A PostNuke module has a very specific directory structure. This allows the PostNuke System to use a generic system to access all modules without needing to know specific information about each separate module that is built. Following the directory structure as laid out below is an absolute requirement of any PostNuke compliant module.
Note: Extra files and directories in addition to these shown below are allowed. Also, if any of the files below are not required (eg. the module does not have database tables of its own so it does not require the pntables.php file) then they do not need to exist. However, files that perform the functions outlined below must comply with the file naming convention to allow the PostNuke system to load the suitable files at the appropriate times to ensure correct operation of the module.
Note: This shows the example layout that a gallery module might have. Other modules will have different names for their top-level directory and blocks as appropriate for their specific functionality.
modules/ [1]
gallery/ [2]
docs/ [3]
credit.txt [4]
install.txt [5]
changelog.txt [6]
licence.txt [7]
pnadmin.php [8]
pnadminapi.php [9]
pnblocks/ [10]
snapshot.php [11]
pnimages/ [12]
admin.jpg [13]
pninit.php [14]
pnlang/ [15]
deu/ [16]
admin.php [17]
init.php [18]
manual.htm [19]
snapahot.php [20]
user.php [21]
eng/ [22]
admin.php [23]
init.php [24]
manual.htm [25]
snapshot.php [26]
user.php [27]
...
pntables.php [28]
pnuser.php [29]
pnuserapi.php [30]
pnversion.php [31]
[1] The top-level directory in PostNuke for modules
[2] The directory that contains all of the module code (in this case the Gallery module is name "gallery"). This directory name must be lower case. You must also register your module name at http://centre.ics.uci.edu/~grape/modules.php?op=modload&name=Wiki&file=index&pagename=ModReg and obtain a module ID number.
[3] The directory that contains all of the module documentation
[4] The file that contains all of the credit information of the module
[5] The file that contains all of the installation instructions of the module
[6] The file that contains all of the changes to the module since the last release
[7] The file that contains all of the license information of the module
[8] The file that contains all administrative GUI function for the module
[9] The file that contains all administrative operational functions for the module
[10] The directory that contains all blocks associated with the module
[11] A file that contains a block associated with this module; in this case it displays a random snapshot from a gallery
[12] The directory that contains all images for the module
[13] The image for the administration icon of the module
[14] The file that contains initialization functions for the module
[15] The directory that contains all language translation files for the module
[16] The directory that contains all German language translation files for the module
[17] The file that contains German language translations for the administrative GUI functions of the module (i.e. pnadmin.php)
[18] The file that contains German language translations for the initialization functions of the module (i.e. pninit.php)
[19] The file that contains the German language translations for the manual for the module
[20] The file that contains the German language translation for the snapshot block
[21] The file that contains German language translations for the user GUI functions of the module (i.e. pnuser.php)
[22] The directory that contains all English language translations files for the module
[23] The file that contains the English language translations for the administrative GUI functions for the module (i.e. pnadmin.php)
[24] The file that contains the English language translations for the initialization functions of the module (i.e. pninit.php)
[25] The file that contains the English translation of the manual for the module
[26] The file that contains the English translations for the snapshot block
[27] The file that contains the English language translations for the user GUI functions of the module (i.e. pnuser.php)
[28] The file that contains all information on database tables for the module
[29] The file that contains all user GUI functions for the module
[30] The file that contains all user operational functions for the module
[31] The file that contains all version and credit information for the module
Use Standard Function Names
There are a number of function names that are considered standard i.e. they have well-known meanings and are used in a number of modules. Using the standard function names makes it easier for other module developers to use your module. See the PostNuke Modules Developers Guide for a complete list.
Use pnAPI
pnAPI is the PostNuke Application Programming Interface, a way for modules to interact with the PostNuke core without needing to access tables and internal structures directly. The API also allows for the underlying implementation details of PostNuke to be hidden from a developer so that they can write modules in a standard fashion and not worry about what it might change under the hood. This is very important for a system such as PostNuke which has undergone, and continues to undergo, radical changes in the core design to allow it to be faster, more secure, and more flexible.
pnAPI is the only supported way of accessing core information. Module developers must use these methods of obtaining information from the PostNuke core system; failure to do so will very likely result in the module not working when the next version of PostNuke is released.
Output
All output generated by module functions must be returned to the PostNuke core. No output of any type should be made directly from the module; doing this is not supported and will break in future versions of PostNuke.
Global Variables
If your package needs to define global variables, their name should start with a single underscore followed by the package name and another underscore.
Security
Continuity
The following requirements exist to ensure that Verified Modules can continue even if the original author abandons the module and vanishes.
Database Usage for Modules
ADODB database abstraction (a way for PostNuke to support multiple database types such as Oracle, Postgres and ODBC)
Testing
Support
Module has support from developer(s)
Commercial Modules
We've not received any requests to certified commercial modules and will handle them individually. Some criteria (ie: CVS, Open Souce license, etc) may not apply to commercial modules.
We Need Your Help!
Footnote: 1
FREE dedicated hosting for all PostNukers!!!
We also want you to gather as much friends as possible to get
this offer!!! You don't want them to miss this chance, do you?!
There's a catch:
1. You must be at least 18 years old.
2. You have to download *ppt presentation to see what you getting
in to, at http://www.worldgamesinc.com/presentation
3. Then you have to register at http://members.worldgamesinc.com/erv
and use IDnumber:'6546' with the registration.
4. To confirm your registration, send us an email to post@eiken.as
with your username (username choosen in your registration) so we can
send you further information and instructions.
Then we are commited to providing you with our excellent
dedicated web hosting solutions absolutly for free. Please
look at the hosting plans below and see if it fits your needs.
<<<<<<<<<<Free of charge>>>>>>>
100 MB Disk Space Yourname.com
10 Email Accounts 10 Mailing Lists
10 Sub-Domains 3 MySQL Databases
Password-Protected Dirs. 24/7 SSH Access
3 GB Data Transfer Virtual IP Address
10 Email Forwarders SSL Server Access
Custom 404 Error Page Daily Offsite Backup
<<<<<<<<<<Standard features>>>>>
Debian Linux Server Webalizer Log Analyzer
Perl Support 24/7 FTP Access
Multimedia Support UPS Battery Backup
Apache 1.3 Web Server Personal CGI-BIN
PHP Support Raw Log Access
Yourname.com (with www) On-Site Power Generator
<<<<<<<<<<Extras>>>>>>>>>>>
Setup Fee Monthly Fee
Script Installation $25 $0
100MB Disk Space $10 $0
SSL Server $25 $10
1GB Data Transfer $0 $4
Dedicated IP Address $10 $5
Best regards,
Eiken Vold
BC Direct
this offer!!! You don't want them to miss this chance, do you?!
There's a catch:
1. You must be at least 18 years old.
2. You have to download *ppt presentation to see what you getting
in to, at http://www.worldgamesinc.com/presentation
3. Then you have to register at http://members.worldgamesinc.com/erv
and use IDnumber:'6546' with the registration.
4. To confirm your registration, send us an email to post@eiken.as
with your username (username choosen in your registration) so we can
send you further information and instructions.
Then we are commited to providing you with our excellent
dedicated web hosting solutions absolutly for free. Please
look at the hosting plans below and see if it fits your needs.
<<<<<<<<<<Free of charge>>>>>>>
100 MB Disk Space Yourname.com
10 Email Accounts 10 Mailing Lists
10 Sub-Domains 3 MySQL Databases
Password-Protected Dirs. 24/7 SSH Access
3 GB Data Transfer Virtual IP Address
10 Email Forwarders SSL Server Access
Custom 404 Error Page Daily Offsite Backup
<<<<<<<<<<Standard features>>>>>
Debian Linux Server Webalizer Log Analyzer
Perl Support 24/7 FTP Access
Multimedia Support UPS Battery Backup
Apache 1.3 Web Server Personal CGI-BIN
PHP Support Raw Log Access
Yourname.com (with www) On-Site Power Generator
<<<<<<<<<<Extras>>>>>>>>>>>
Setup Fee Monthly Fee
Script Installation $25 $0
100MB Disk Space $10 $0
SSL Server $25 $10
1GB Data Transfer $0 $4
Dedicated IP Address $10 $5
Best regards,
Eiken Vold
BC Direct
Footnote: 1
WebPosition Gold2 Released!
Read more and download a free copy <a href=http://www.web-dj.net/webshop/modules.php?op=modload&name=News&file=article&sid=2&mode=thread&order=0&thold=0 target=_blank>HERE You DO NOT have to register in order to download the software, but may elect to receive a free newsletter, if you would like.
Footnote: 1
PostNuke Portugal Coming soon!
Footnote: 1
WAMP-system news: FoxSERV Public 3 BETA 3 released
FoxServ 3.0 (Final) will come with <a href="http://www.apache.org"target="_blank">apache 2.0 and the newest PHP-release.
The <a href="http://foxserv.linuxmax.net/portal.php"target="_blank">FoxSERV-crew will also release a retail-version, with a debugging-server and a integrated PHP+Python+Perl+HTML-editor (approx. 40 US $):
1. Debugging Server for PHP+Perl+Python-Developement;
2. FoxEdit IDE environment;
3. FoxRun MySQL (enhanced MySQL server);
4. enhanced installer.
By the way: If you need a new free editor, check back <a href="http://www.phpedit.org/"target="_blank">phpEdit.org for the latest version: build up your WAMPE-system in only ten minutes.
The <a href="http://foxserv.linuxmax.net/portal.php"target="_blank">FoxSERV-crew will also release a retail-version, with a debugging-server and a integrated PHP+Python+Perl+HTML-editor (approx. 40 US $):
1. Debugging Server for PHP+Perl+Python-Developement;
2. FoxEdit IDE environment;
3. FoxRun MySQL (enhanced MySQL server);
4. enhanced installer.
By the way: If you need a new free editor, check back <a href="http://www.phpedit.org/"target="_blank">phpEdit.org for the latest version: build up your WAMPE-system in only ten minutes.
Nuke Install - PostNuked
Footnote: 1
Weblinks module on the main page
In my case i wanted some specific weblinks category to be displayed at main page, sort of a top sites script. More or less i have accomplished that ;)
spathi
spathi
Footnote: 1
Arkansas Publik Skules
Footnote: 1
PostContact v0.2.3 in the wild
Feature List:
- Unlimited contact departments
- Unlimited Contact persons
- Ability to connect contact persons with multiple departments
- Every contact person have there own "bussines card" and contact form
- Every department have there own contact forms
- Possiblity to upload picture for every contactperson (shown in there "businesscard")
- If no address information is given for the person, PostContact will use the defaultinformation given in companyinfo
- Find the last bugs (v0.2.4)
- Make the mod fully PN API compatible (v0.2.5)
Page 81 / 277 (801 - 810 of 2763 Total)
