has anyone successfully integrated phpGedView with current releases of PostNuke - guess we could do it with postwrap - but the ability to pick up existing userid and use that in authenticate etc would be nice - save an addition login in gedview etc?
Jim
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I can't remember now if murphdog is using phpNuke or postNuke though...
I designed the authentication.php file to be modular for exactly this reason. I was hoping that a user out there would be willing to do the work. All the needs to be done is implement the functions in the authentication.php file to use the user database for postNuke. Should be fairly simple to do.
--John
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
hi,
done a simplistic integration - will email you the bits tomorrow. It is called as a module on postnuke, then sets the pgv_user session variable (still need to work on the admin part) in my module - then passes control to the std gedview in a new page - haven't pulled it into the same page as the postnuke. but all works - picks up the logged in or not state of the user - very basic aproach but useable
Jim
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
playing with postnuke using phpGedView as a module. Can get it started with a little front end and it goes in fine. However a big problem is the path structure. When you call a module under postnuke the path stays as the root - so when phpGedView does a require it tries to get it from the root dir rather thanm the pgpGedView dir. What we really need to have, to make this much simpler, is a $GEDBASEDIR global initialised in config.php that prefaces each require - eg require($GEDBASEDIR."buildindex.php"); etc
what do you reckon on the chances ? :-)
Jim
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am just atarting to code the authentication.php so that it picks up the information from postnuke db rather than the authenticate.php . Couple of q's on design:
1. if user is already logged in to postnuke do I provide an auto login for gedview (config option controlled) or should the user have to login regardless with userid and password again in gedview. Note that the postnuke window could be closed but because of cookies the system will still return logged in. (ie remember me). So maybe a force to login would be sensible - but with an option to bypass and use auto login if wanted - process would still require the user to click on login - but wouldnt need to enter user and password
2.there is not a sensible level that meets canedit. should i use moderator as a level for canedit ? - admin will match the postnuke admin - that's clear
3. logout in gedview would not logout the postnuke side - correct ?
4. config option to use either postnuke or gedviews auth process ?
5. any other thoughts
This is just for authorisation - creating gedview as a module for postnuke is further down track and needs the basedir and a chunk more time from me :-)
Jim
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1. I envisioned it being an automatic login. The fewer times a user has to enter a username and password the better. When they come to your site, they can login or not. If they are logged in to postNuke they shouldn't have to login to gedview and if they are not logged into postNuke, then they can't login to gedview except by logging into postNuke.
2. The canedit feature is for future development and doesn't currently play any role. For now you can just have the userCanEdit() function return false, or true or whatever since nothing actually calls it. When I do start updating the editing features (which looks like it will be several months before I can get to it) you may want to have a user lookup array something like this:
$usercanedit['username1']=true;
$usercanedit['username2']=true;
Then the canedit function will simply return $usercanedit[$username];
This will give the user control over who can edit. The other alternative would be as you say, to user a moderator or other level as editor.
3. In your current environment where you pass the username to phpGedView in a cookie, No, logging out of phpGedView would not log you out of postNuke. When phpGedView becomes a module and uses the postNuke authentication functions, then yes it would. In this case I would disable the logout feature all together, by removing the logout link from the header.html file in the themes directory. You can also have the userLogout function return true and not do anything. So that if they tried to logout through phpGedView nothing would happen.
4. This option already exists. There is an option that tells phpGedView which authentication file to include. You would change this from authentication.php to postNukeAuthentication.php or any other file you want. My hope is to have several different authentication modules for phpGedView that use different user databases: postNuke, phpNuke, MySQL, LDAP, etc.
When you have it setup as a module, then you could call the postNuke functions to access the user in the authentication.php file. As a module all of the postNuke functions will then become available to phpGedView. So I would think you would be able to change the getUserName function to simply return pnUserGetVar('uname'); Then you wouldn't have to worry about passing cookies around and the user would login through the postNuke environment instead of logging in through phpGedView.
--John
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
yep - good approach - certainly the easiest one. I will do it all as a PostNuke module then with pn being the only login/logout (wondering how it will all look crammed into the std content area - may have to open a new page - will see).
I currently have a version that can be called from PostNuke to load up in a new page - it takes the PostNuke username via a cookie - works ok - but clunky (and for some reason cookies are playing up on my machine - is a new RedHat 9 but with older PHP 4.2.2 - will wait for your basedir mods (no hurry - am real busy myself as well :-) ) and then will work on that
Jim
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I released version 2.12 today which includes the base directory variable $PGV_BASE_DIRECTORY. This is something that has to be manually edited in the config file because the configure.php script needs it in place before it can run.
I don't include it when require'ing the config.php file. So there may be some more changes that need to be made there. Just let me know.
--John
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately that base directive also needs to apply to most of the href= or img directives. The base whgen you are a PostNuke module is the Postnuke base - probably not the same as the gedview one :-(
i will play around and do some updates of the html that is embedded to get it going - I have proven the theory as i have called it as a module and displayed the pedigree page with proof that it recognises that it is pnloggedin - so a good start - will play over next few days and try and make all the changes required to the html
Jim
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was making it harder than it needed to be :-( - wanted the gedview in a diff dir path - caused all sorts of fuss - now have it all in the modules/gedview dir and things are turning much simpler :-)
nearly there - should have something for you to see this weekend - ok if I send it to you via the sourceforge email path (may give you a password to login to check mine out first and dont want to publish that)
Jim
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
yes - you can see carey.id.au - it's very simplistic. If you are logged on to the postnuke system then you are automatically logged in to gedview when you call it. If not then you stay logged out with no option to login from gedview. pretty simple. I am packaging this up this weekend and passing back to John to put on the site.
see http://www.carey.id.au - sorry but i dont hand out userids to anyone but family so you cant see the difference between logged in or out.
If you are logged in to postnuke the module tests tosee if you have moderator or greater and assigns canedit, if you are defines as admin in postnuke then you become admin in gedview
Jim
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
has anyone successfully integrated phpGedView with current releases of PostNuke - guess we could do it with postwrap - but the ability to pick up existing userid and use that in authenticate etc would be nice - save an addition login in gedview etc?
Jim
There is some discussion on this topic here:
https://sourceforge.net/forum/forum.php?thread_id=880149&forum_id=185166
I can't remember now if murphdog is using phpNuke or postNuke though...
I designed the authentication.php file to be modular for exactly this reason. I was hoping that a user out there would be willing to do the work. All the needs to be done is implement the functions in the authentication.php file to use the user database for postNuke. Should be fairly simple to do.
--John
hi,
done a simplistic integration - will email you the bits tomorrow. It is called as a module on postnuke, then sets the pgv_user session variable (still need to work on the admin part) in my module - then passes control to the std gedview in a new page - haven't pulled it into the same page as the postnuke. but all works - picks up the logged in or not state of the user - very basic aproach but useable
Jim
Hi,
playing with postnuke using phpGedView as a module. Can get it started with a little front end and it goes in fine. However a big problem is the path structure. When you call a module under postnuke the path stays as the root - so when phpGedView does a require it tries to get it from the root dir rather thanm the pgpGedView dir. What we really need to have, to make this much simpler, is a $GEDBASEDIR global initialised in config.php that prefaces each require - eg require($GEDBASEDIR."buildindex.php"); etc
what do you reckon on the chances ? :-)
Jim
The chances are good. ;-)
I'll have a base directory variable part of the configuration in the next release.
--John
I am just atarting to code the authentication.php so that it picks up the information from postnuke db rather than the authenticate.php . Couple of q's on design:
1. if user is already logged in to postnuke do I provide an auto login for gedview (config option controlled) or should the user have to login regardless with userid and password again in gedview. Note that the postnuke window could be closed but because of cookies the system will still return logged in. (ie remember me). So maybe a force to login would be sensible - but with an option to bypass and use auto login if wanted - process would still require the user to click on login - but wouldnt need to enter user and password
2.there is not a sensible level that meets canedit. should i use moderator as a level for canedit ? - admin will match the postnuke admin - that's clear
3. logout in gedview would not logout the postnuke side - correct ?
4. config option to use either postnuke or gedviews auth process ?
5. any other thoughts
This is just for authorisation - creating gedview as a module for postnuke is further down track and needs the basedir and a chunk more time from me :-)
Jim
Jim,
1. I envisioned it being an automatic login. The fewer times a user has to enter a username and password the better. When they come to your site, they can login or not. If they are logged in to postNuke they shouldn't have to login to gedview and if they are not logged into postNuke, then they can't login to gedview except by logging into postNuke.
2. The canedit feature is for future development and doesn't currently play any role. For now you can just have the userCanEdit() function return false, or true or whatever since nothing actually calls it. When I do start updating the editing features (which looks like it will be several months before I can get to it) you may want to have a user lookup array something like this:
$usercanedit['username1']=true;
$usercanedit['username2']=true;
Then the canedit function will simply return $usercanedit[$username];
This will give the user control over who can edit. The other alternative would be as you say, to user a moderator or other level as editor.
3. In your current environment where you pass the username to phpGedView in a cookie, No, logging out of phpGedView would not log you out of postNuke. When phpGedView becomes a module and uses the postNuke authentication functions, then yes it would. In this case I would disable the logout feature all together, by removing the logout link from the header.html file in the themes directory. You can also have the userLogout function return true and not do anything. So that if they tried to logout through phpGedView nothing would happen.
4. This option already exists. There is an option that tells phpGedView which authentication file to include. You would change this from authentication.php to postNukeAuthentication.php or any other file you want. My hope is to have several different authentication modules for phpGedView that use different user databases: postNuke, phpNuke, MySQL, LDAP, etc.
When you have it setup as a module, then you could call the postNuke functions to access the user in the authentication.php file. As a module all of the postNuke functions will then become available to phpGedView. So I would think you would be able to change the getUserName function to simply return pnUserGetVar('uname'); Then you wouldn't have to worry about passing cookies around and the user would login through the postNuke environment instead of logging in through phpGedView.
--John
yep - good approach - certainly the easiest one. I will do it all as a PostNuke module then with pn being the only login/logout (wondering how it will all look crammed into the std content area - may have to open a new page - will see).
I currently have a version that can be called from PostNuke to load up in a new page - it takes the PostNuke username via a cookie - works ok - but clunky (and for some reason cookies are playing up on my machine - is a new RedHat 9 but with older PHP 4.2.2 - will wait for your basedir mods (no hurry - am real busy myself as well :-) ) and then will work on that
Jim
Jim,
I released version 2.12 today which includes the base directory variable $PGV_BASE_DIRECTORY. This is something that has to be manually edited in the config file because the configure.php script needs it in place before it can run.
I don't include it when require'ing the config.php file. So there may be some more changes that need to be made there. Just let me know.
--John
Thanks :-)
will start looking at it this weekend - dont think I can get to it before then but will try :-)
cheers
Jim
Unfortunately that base directive also needs to apply to most of the href= or img directives. The base whgen you are a PostNuke module is the Postnuke base - probably not the same as the gedview one :-(
i will play around and do some updates of the html that is embedded to get it going - I have proven the theory as i have called it as a module and displayed the pedigree page with proof that it recognises that it is pnloggedin - so a good start - will play over next few days and try and make all the changes required to the html
Jim
I was making it harder than it needed to be :-( - wanted the gedview in a diff dir path - caused all sorts of fuss - now have it all in the modules/gedview dir and things are turning much simpler :-)
nearly there - should have something for you to see this weekend - ok if I send it to you via the sourceforge email path (may give you a password to login to check mine out first and dont want to publish that)
Jim
Yes, can just email it to me at yalnifj AT users.sourceforge.net
--John
Jim,
I'm also interested in using phpGedView as a module within postNuke. Do you have it up and running somewhere that I could take a look at?
Many thanks,
Owen
yes - you can see carey.id.au - it's very simplistic. If you are logged on to the postnuke system then you are automatically logged in to gedview when you call it. If not then you stay logged out with no option to login from gedview. pretty simple. I am packaging this up this weekend and passing back to John to put on the site.
see http://www.carey.id.au - sorry but i dont hand out userids to anyone but family so you cant see the difference between logged in or out.
If you are logged in to postnuke the module tests tosee if you have moderator or greater and assigns canedit, if you are defines as admin in postnuke then you become admin in gedview
Jim
Looks excellent!!! I'll definitely be grabbing a copy once it goes up on the site.
Owen
John,
just making sure you got the files over the weekend ok ?
Jim
Sorry Jim,
I haven't received any emails from you recently.
--John
The add-on files to make phpGedView work with PostNuke are now available for download from the phpGedview projects page here:
http://prdownloads.sourceforge.net/phpgedview/postnuke_gedview_v1.zip?download
Thanks to Jim for providing the files and doing all of the work.
--John