Member system integration
By Paul
By Paul
If you wish to use an existing member database, such as one from a forum, it's simplest to install WSN Knowledge Base in the same database as the script whose member system you will be using. (It's possible to integrate still while in a different database, by editing the integration file to change the table name to databasename.tablename, but using a different database will prevent you from being able to use the integration generator -- you'll be forcing yourself to write the file manually. Of course, there's absolutely no reason why you ever need a separate database -- no script will ever have a problem sharing its database since the table prefixes are different.)
First go to Admin -> Members -> Settings and check the list of pre-supplied integration files. If the script you need to integrate with is on the list and you have standard prefixes, you can just select it there and you're done.
Please note that you will need to remove the 'register' links from your templates if integrating. When you're using the foreign member database, it's up to that script whose member database you're using to handle registrations. See your wrapper.tpl template, or for multilingual the footer_ language items.
Note an exception to the above rule: If you're integrating with another WSN script (WSN Forum, WSN Gallery, etc.) then registration will work seemlessly just as if it were the natural members table.
If the script you wish to integrate with isn't already supplied, and you're using a version which includes the integration generator, login to your admin panel and click 'Integration Generator' on the customizations menu. This will lead you through the process of integrating.
Continue reading this manual entry only if you have problems with the integration generator, don't have a version with the integration generator, you need to edit an existing integration file, or you or just want to learn more about how integration works.
To get an idea of what you're trying to do, have a look at the pre-made integration scripts in your 'integration' subdirectory. You may adapt these files to integrate with other scripts. Any .php file you save to the integration directory will automatically become a selectable option in your settings (except ones named with 'encoder' in the title, as will be explained in a moment).
If the script you're integrating with uses a method other than md5 to encode passwords, you will need to make an encoder file similar to the one for vBulletin which has been provided. You must name this with the same name as your main integration file plus 'encoder', the same naming style as used with the vbulletin example. For advanced users: if for some reason you need to change the $actual database value calculation which the $password result is compared with, you can set global $settings; $settings->getactualquery = 'SELECT blah FROM blah WHERE id={ID}'; in the encoder file.
The format of the integration files is simple. First you specify the name of the database table, as $memberstable = 'otherscriptstable';
Look at otherscriptstable in phpmyadmin, write down the field names listed for it and be sure you have a general idea of what each field contains or is for. Then specify in the integration file each field in that table which does NOT have the same name as the corresponding item in the WSN Links members table (compare with wsnlinks_members in phpmyadmin). The format for this specification consists of putting $new in front of the WSN Knowledge Base field name, and then = "the other script's field name we should use";
For example:
$newname = 'username';
$newid = 'userid';
Fields which are named the same as in WSN Links do not have to be specified.
All WSN Knowledge Base member fields which do not exist in the script you're integrating with will be automatically added as soon as you load any page on your site with that integration script selected.
Note: Do not drop the WSN Knowledge Base members table when done, because it is still used for field comparisons, upgrades, etc.
Mapping Usergroups
You may handle extra usergroups by adding lines to the integration file of the form
$group4 = '6';
This example specifies that everyone in group #6 of the member system you're integrating with will be treated as being in WSN Knowledge Base group #4. Create a group #4 in your WSN Knowledge Base admin panel and give it the permissions you want members in group 6 of your other database to have.
This can be continued for multiple groups by adding more lines, like
$group5 = '10';
to set group 10 to work as WSN Knowledge Base usergroup #5.
If for some reason the administrator is identified using something other than the usergroup field, you can set $adminfield = 'fieldname'; and $adminfieldvalue = 'whateverthefieldhasforanadmin';... you could do this with a username field to set just one member as admin for example.
Cookies
If your script uses an array for the user/password cookies, just supply the name (without an index) as the cookie name and password, and then add this to your integration file:
$cookietype = 'array';
$idindex = 'userid';
$passwordindex = 'password';
Of course replacing userid and password with the actual index names for the array cookie. If it uses a member username instead of an id, add:
$cookieidtype = 'name';
See the integration/mambo.php file as an example.
When dealing with session cookies, you can use $cookietype = 'session'; and add a
Miscellanea
If you set $registrationurl = 'http://hostscript/register.php'; then people will be automatically directed to the registration page of the host script, and avatars will be automatically shared.
Sometimes you may run into a member system which doesn't keep all the member data in the same table. As of 5.0.0, you can handle this by manually specifying the additional fields ($newsomething = 'something' as above) and then adding this line:
You need to alter the query to specify how to get data out of the particular table you're dealing with. Note that this method will get the data out of the fields, but won't allow updating the values of the fields by editing a WSN profile.
Additionally, if you need to get the member usergroup out of another table with a custom query, you can specify that like this:
Helper Functions
Helper functions can be used for the registration and cookie setting/unsetting processes. The easiest way to understand them is to look at integration/smf.php as an example, copy that and modify to your needs.
integratedregistration - If you want to allow registering through the WSN interface instead of redirecing to the other script's registration page, you can do that and put cleanup code here to make the database correct for the other script's use.
setlogincookies - If cookies needs to be set in some unique way, or a database session needs to be added to the database in the process, do that here.
unsetlogincookies - In case you need a special way to clear the cookies on logout (perhaps deleting a database session).
comparecookiepassword - If your script has a special way of deciding whether the value in a password cookie is authentic, you can specify it here.
Troubleshooting
If you choose an integration option and it does not function, run this query in phpmyadmin to go back to the native member system so that you can login again:
UPDATE wsnkb_settings SET content='' WHERE name='integration';
Change wsnkb_ in that query to whatever tables prefix you selected to use during setup, if different. You will then need to visit upgrade.php (no need to run the upgrade, just view the page) to get the field list reset.
After you set or unset the integration, note that you will likely need to go to Settings -> General Appearance and re-select a member list sort order (this is so that it sorts by a field which exists in your new members table). Also select a valid member sort order for member searches under Settings -> Search & SEO.
Integrating With Other WSN Scripts
When the script you're integrating with is another WSN script, there are a couple things to consider. The albumid field of the members table, which is used for tracking the location of the member's personal link list, personal album or saved articles, needs to be made unique for each script to keep the saved items working in them all. Add a new field, for example kbalbumid to handle WSN KB's if you're integrating WSN KB with WSN Links, and then modify your integration file to reference it:
$newalbumid = 'kbalbumid';
The exceptions to this are WSN Forum and WSN Guest, which don't use the albumid field.
Also, integrating WSN scripts gives you the opportunity to integrate the online user lists, private messaging and instant messaging systems. This is done automatically in the current standard integration files, or you can add it in yourself with a
$wsnintegration = true;
line. Be sure you're using reasonably up to date versions of all the WSN scripts so that the database fields are the same.
When integrated with another WSN script, it will use the other WSN Script's template set name and language name. Thus you should either make sure your template and language names are the same in both scripts or make a new field to handle those settings for your integration (and add $newtemplate = 'fieldijustcreated'; to the integration file).
First go to Admin -> Members -> Settings and check the list of pre-supplied integration files. If the script you need to integrate with is on the list and you have standard prefixes, you can just select it there and you're done.
Please note that you will need to remove the 'register' links from your templates if integrating. When you're using the foreign member database, it's up to that script whose member database you're using to handle registrations. See your wrapper.tpl template, or for multilingual the footer_ language items.
Note an exception to the above rule: If you're integrating with another WSN script (WSN Forum, WSN Gallery, etc.) then registration will work seemlessly just as if it were the natural members table.
If the script you wish to integrate with isn't already supplied, and you're using a version which includes the integration generator, login to your admin panel and click 'Integration Generator' on the customizations menu. This will lead you through the process of integrating.
Continue reading this manual entry only if you have problems with the integration generator, don't have a version with the integration generator, you need to edit an existing integration file, or you or just want to learn more about how integration works.
To get an idea of what you're trying to do, have a look at the pre-made integration scripts in your 'integration' subdirectory. You may adapt these files to integrate with other scripts. Any .php file you save to the integration directory will automatically become a selectable option in your settings (except ones named with 'encoder' in the title, as will be explained in a moment).
If the script you're integrating with uses a method other than md5 to encode passwords, you will need to make an encoder file similar to the one for vBulletin which has been provided. You must name this with the same name as your main integration file plus 'encoder', the same naming style as used with the vbulletin example. For advanced users: if for some reason you need to change the $actual database value calculation which the $password result is compared with, you can set global $settings; $settings->getactualquery = 'SELECT blah FROM blah WHERE id={ID}'; in the encoder file.
The format of the integration files is simple. First you specify the name of the database table, as $memberstable = 'otherscriptstable';
Look at otherscriptstable in phpmyadmin, write down the field names listed for it and be sure you have a general idea of what each field contains or is for. Then specify in the integration file each field in that table which does NOT have the same name as the corresponding item in the WSN Links members table (compare with wsnlinks_members in phpmyadmin). The format for this specification consists of putting $new in front of the WSN Knowledge Base field name, and then = "the other script's field name we should use";
For example:
$newname = 'username';
$newid = 'userid';
Fields which are named the same as in WSN Links do not have to be specified.
All WSN Knowledge Base member fields which do not exist in the script you're integrating with will be automatically added as soon as you load any page on your site with that integration script selected.
Note: Do not drop the WSN Knowledge Base members table when done, because it is still used for field comparisons, upgrades, etc.
Mapping Usergroups
You may handle extra usergroups by adding lines to the integration file of the form
$group4 = '6';
This example specifies that everyone in group #6 of the member system you're integrating with will be treated as being in WSN Knowledge Base group #4. Create a group #4 in your WSN Knowledge Base admin panel and give it the permissions you want members in group 6 of your other database to have.
This can be continued for multiple groups by adding more lines, like
$group5 = '10';
to set group 10 to work as WSN Knowledge Base usergroup #5.
If for some reason the administrator is identified using something other than the usergroup field, you can set $adminfield = 'fieldname'; and $adminfieldvalue = 'whateverthefieldhasforanadmin';... you could do this with a username field to set just one member as admin for example.
Cookies
If your script uses an array for the user/password cookies, just supply the name (without an index) as the cookie name and password, and then add this to your integration file:
$cookietype = 'array';
$idindex = 'userid';
$passwordindex = 'password';
Of course replacing userid and password with the actual index names for the array cookie. If it uses a member username instead of an id, add:
$cookieidtype = 'name';
See the integration/mambo.php file as an example.
When dealing with session cookies, you can use $cookietype = 'session'; and add a
line to specify the query needed to get the member id when given the session id. Put the session cookie name in the $idcookiename spot.$sessionquery = "SELECT x FROM y WHERE id='{SESSIONID}'";
Miscellanea
If you set $registrationurl = 'http://hostscript/register.php'; then people will be automatically directed to the registration page of the host script, and avatars will be automatically shared.
Sometimes you may run into a member system which doesn't keep all the member data in the same table. As of 5.0.0, you can handle this by manually specifying the additional fields ($newsomething = 'something' as above) and then adding this line:
$integrationoptions['queryadditio nalfields'] = "SELECT field1,field2,field3 FROM othertable WHERE id='{ID}'";
You need to alter the query to specify how to get data out of the particular table you're dealing with. Note that this method will get the data out of the fields, but won't allow updating the values of the fields by editing a WSN profile.
Additionally, if you need to get the member usergroup out of another table with a custom query, you can specify that like this:
$integrationoptions['usergroupque ry'] = "SELECT group FROM othertable WHERE id='{ID}'";
Helper Functions
Helper functions can be used for the registration and cookie setting/unsetting processes. The easiest way to understand them is to look at integration/smf.php as an example, copy that and modify to your needs.
integratedregistration - If you want to allow registering through the WSN interface instead of redirecing to the other script's registration page, you can do that and put cleanup code here to make the database correct for the other script's use.
setlogincookies - If cookies needs to be set in some unique way, or a database session needs to be added to the database in the process, do that here.
unsetlogincookies - In case you need a special way to clear the cookies on logout (perhaps deleting a database session).
comparecookiepassword - If your script has a special way of deciding whether the value in a password cookie is authentic, you can specify it here.
Troubleshooting
If you choose an integration option and it does not function, run this query in phpmyadmin to go back to the native member system so that you can login again:
UPDATE wsnkb_settings SET content='' WHERE name='integration';
Change wsnkb_ in that query to whatever tables prefix you selected to use during setup, if different. You will then need to visit upgrade.php (no need to run the upgrade, just view the page) to get the field list reset.
After you set or unset the integration, note that you will likely need to go to Settings -> General Appearance and re-select a member list sort order (this is so that it sorts by a field which exists in your new members table). Also select a valid member sort order for member searches under Settings -> Search & SEO.
Integrating With Other WSN Scripts
When the script you're integrating with is another WSN script, there are a couple things to consider. The albumid field of the members table, which is used for tracking the location of the member's personal link list, personal album or saved articles, needs to be made unique for each script to keep the saved items working in them all. Add a new field, for example kbalbumid to handle WSN KB's if you're integrating WSN KB with WSN Links, and then modify your integration file to reference it:
$newalbumid = 'kbalbumid';
The exceptions to this are WSN Forum and WSN Guest, which don't use the albumid field.
Also, integrating WSN scripts gives you the opportunity to integrate the online user lists, private messaging and instant messaging systems. This is done automatically in the current standard integration files, or you can add it in yourself with a
$wsnintegration = true;
line. Be sure you're using reasonably up to date versions of all the WSN scripts so that the database fields are the same.
When integrated with another WSN script, it will use the other WSN Script's template set name and language name. Thus you should either make sure your template and language names are the same in both scripts or make a new field to handle those settings for your integration (and add $newtemplate = 'fieldijustcreated'; to the integration file).
Rating:




3.5/5 based on 14 votes. The median rating is 4.
Rate this article:
Submitted: 10/18/03 (Edited 06/22/08)
Description: Using WSN Knowledge Base with a preexisting member base.
Views:
7594 views. Averaging 4 per day.
In the most recent 30 day period, there've been 1 views.

Print
E-Mail