If you wish to use an existing member database, such as one from a forum, you can usually do that. Go to Admin -> Members -> Integration and check the list of pre-supplied integration files. If the script you need to integrate with is on the list, select it there. If it's not in the list, you'll need to use the integration generator on the same page.

Mapping Usergroups

By default, only the basic usergroups are handled: guests, members, administrators. All other groups are considered as members. You can change this to map more of the other script's groups onto WSN groups. Open the integration file (in the /integration/ subdirectory) in a text editor. You can map groups by adding lines in 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.

For Advanced Users

Continue reading this manual entry only if you have problems with the integration generator not fully supporting what you want to do, 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/setup/ 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 yourprefix_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.

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.

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/setup/mambo.php file as an example.

When dealing with session cookies, you can use $cookietype = 'session'; and add a

$sessionquery = "SELECT x FROM y WHERE id='{SESSIONID}'";

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.

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 for WSN scripts.

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['queryadditionalfields'] = "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['usergroupquery'] = "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 yourprefix_settings SET content='' WHERE name='integration';

Change yourprefix_ in that query to whatever tables prefix you selected to use during setup. 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).