PostNuke

https://sourceforge.net/projects/pnlanguages/

If you know of a language package that has not been included in this project or would like to add or update one please let me know. Each language package has the URL of it's origin under "release notes". As time permits we will add more credits.

If you are the maintainer of one of these language packages and would like to become a project admin please email me at webmaster@pnapi.com

please send the following information so that we may properly archive these language packs.

1) URL where the package may be downloaded.
2) precise name of package file
3) PostNuke version Number
4) Date of release.
5) Person(s) making the release.
6) Contact info.

Thank You
Mediatech

Has anyone testet PN 0.723+ with Mysql 4.0?

Just plug'n'play or something that could cause any trouble?

Fischer
www.humlebaekonline.dk

In response to this alert below is code to properly correct this issue.

Also posted here:
<a href="http://forums.postnuke.com/phpBB2/viewtopic.php?t=9153&highlight="target="blank">http://forums.postnuke.com/phpBB2/viewtopic.php?t=9153&highlight=

Here is a simple fix to the issue. Long term the error reporting should probably be done to a file or set as an option so that more details information could be presented when needed in debugging and none when in a production state.

Hope this helpful.

File: legacy.php

/**
* Error message due a ADODB SQL error and die
*/
function PN_DBMsgError($db='',$prg='',$line=0,$message='Error accesing to the database')
{

// 2 lines added to strip the server root path
$padprg = $prg ;
$prg = str_replace($_SERVER["SITE_HTMLROOT"], "...", $padprg);
//

$lcmessage = $message . "" .
"Program: " . $prg . " - " . "Line No.: " . $line . "" ;

// remove report of DB name not necessary in most cases
// "Database: " . $db->database . " ";

if($db->ErrorNo()<>0) {
$lcmessage .= "Error (" . $db->ErrorNo() . ") : " . $db->ErrorMsg() . "";
}
die($lcmessage);
}

Here goes...

Objective

The purpose of this development is to allow multiple methods of authentification for the Postnuke CMS (for example, allow users to login using their LDAP accounts, their POP accounts, etc.)
We consider that such a development, due to it's integration with existing systems, will greatly increase the acceptation of Postnuke in enterprise environments.

Requirements

We have identified the following requirements for such a development:
1. Allow definition of an external realm that will be used for authentification
2. Allow specifying which users will use the external realm for authentification. This includes the cases when the administrator of the site knows the credentials of the local user on the external realm, and when he does not.
3. Allow users that do not yet have a Postnuke account, but that are correctly identified by the external realm, to login into the system (new postnuke user records will be created for them)
4. Allow the import of a list of users accounts (possibly through the UserImport module), and setting the correct external authentification information for them.
5. In case the external realms are temporarily not available, allow users to login through the normal internal procedure. This means that in all cases, user records must exist for each user (including the externally authentified ones)

Implementation


We have chosen a hybrid approach of integration with the existing code of Postnuke.
The main functionality will be contained in a module, and changes will be made to the core to allow easy setup of the users' accounts and an easy transition from older installations of Postnuke.

The module will provide a framework allowing implementation of different realm models. Thus, in case another method of authentification is needed (excepting the ones we will implement), all one will need to do is writing the code for another realm model.
For example, we predict writing a LDAP realm model, a POP realm model, an external database realm model, a XML-RPC realm model.
The module will also support multiple external authentification realms (using more than one method of authentification, at the same time). The administrator of the site will be able to configure the Postnuke system to accept logins from one or more LDAPs, from a POP realm, etc. at the same time.
It will also provide the necessary API for the verification of the users accounts.

At the internal database level, the table that describes the users will be kept unchanged, and a new table will be added, that will contain all the needed data for the external authentification.

For each realm, the information needed is divided in two sets:
- realm specific information (the name of the server providing authentification, a short description, connection parameters, possibly how to retrieve any information that is needed in postnuke – i.e. the email – from the server) – this will be administered by the realm model code.
- postnuke specific information: if to allow external users that do not yet have an account to login in the system, the group in which such users will be placed – this will be administered by the module code.

The modifications to the core will be mainly at a graphical level. We have chosen to use as starting point the PNUserHack, and add code to this hack, rather than touch the core. The purpose of these modifications will be to allow the setup of the external authentification method at the same time as the setup of the "normal" PN user accounts.

The core modifications are briefly described here:
- User administration (for administrator): for each user and for each external server (as described in the module) add the necessary interface for allowing the user to login through the specified server, and for deciding which external account corresponds to the user, or for letting the user specify by himself the external account.
- Administration of a user's account (by himself): if the administrator allowed it, permit specifying which external account corresponds to the user.

Of course, the status of this document and of the development is still alpha (meaning we have a pretty good idea of what we want, and we are just starting to look around in the code and to implement things). We are however willing to invest a good amound of effort in this development, and we feel that all users and Postnuke in general could benefit from such add-on.

Best regards,
Tibi Dondera

Additional links:
http://atelier.epfl.ch - the site that contains some of our other modules. We are planning of posting shortly another article about our current/finished developments. (sorry, french only)

2) Being the source code closed, it should have a lot (I mean: A LOT) of customization options. I know that many of you touch the code to add or remove stuff, so, with the new code you should be able to modify as much as possible. You could be able to add new php files with your own functions and there will be a manual for all needed variables to do this.
3) Modules, blocks and themes developer will not have any problem at all. All of you, developers, can write your own modules/blocks/themes for it in a similar, but powerful, method as it's now.
4) There will be a Corporative version, with costs money for one site license basis. This version will differ from the free version in the fact that you'll not have the copyright/credits text at the bottom, no "PHP-Nuke" word on the whole code. Not a single reference to it, your customers/visitors will never know what code you're using, and with this corporative version you can develop and sell "commercialy signed" modules. This means that your encoded module will work only with the corp. version, and this last feature will open many doors to commercialy exploit your programmer skills, unfortunately you should have a Zend Encoder license for this.
5) Rewriting the code will give the chance to have a totaly new, secured and stable code and will open doors to have PHP-Nuke running in corporative environments.
6) The incomes will be used for more and more future versions full of new an cool features... better than ever.
7) The distribution method will remain the same: Alphas, Betas and RCs exclusive for Club members and the final version distributed 15 days before it goes public for free.
8) No forks
9) Since the encoded code needs to use Zend Optimizer, the code will run faster.

Of course, not all is pink... there are some contras:

1) Forget the bugs with fixes submissions in news and forums, just bugs reports (with my promise that I'll address all of them)
2) No core modifications allowed (but a highly customizable system instead)
3) The required use of Zend Optimizer (anyway it's free)

I think that this is 9 vs 3... I want that now, knowing this, all of you think about it, evaluate the pros and contras, and give me an objetive feedback.

For me, this step, can represent a unique opportunity to mature this project and pass it to the next level. Always giving it for free, have this in mind. And for one second try to put yourself into my shoes.

Have a nice day and be happy... "

The original article can be read HERE.

I am now happy to announce that the Installing PostNuke for the Absolute Beginner is now back and has been updated to tie in with the Phoenix release of PostNuke.

It can be found in the same place it used to be at http://postnuke.bloodymongrel.com. I hope people find it a useful guide to help them get started in the world of PostNuke. There is also a demo site online where people can just play around and see if PostNuke is what they need.

I hope you enjoy reading my tutorial as much as I enjoyed writing it and may it allow PostNuke to be available to users of all skill levels.

Cheers