The only problem Finner is that nobody at SMF (that I'm aware of) knows enough about XOOPS to develop such a bridge. I am wondering what happened now. I thought it was a sure thing after I mentioned all the great built-in integration stuff in 1.1, but haven't heard anything about the project since then...

Quote:

The API will define a variable called $smf_user_info, which you can then use to get SMF's user information. As far as creating, updating and deleting users, I've been taking a good look at SMF 1.1 lately (currently in beta), and there are numerous checks throughout the files to call various integration functions that can be defined in the settings table, as well as an optional SMF_INTEGRATION_SETTINGS constant that can contain any additional integration-related settings needed that will be added to SMF's settings array ($modSettings):

SMF_INTEGRATION_SETTINGS (constant, not in the table)
integrate_buffer (output buffer from integration) [Subs.php, line 2444]
integrate_pre_include - name of a file to include prior to integration [Load.php, line 175]

Functions:
integrate_activate(username) [ManageMembers.php, Profile.php, Register.php] - activates the user account in the CMS/portal
integrate_change_email(username, new email) [Profile.php, Register.php] - changes the email address in the CMS/portal
integrate_delete_member(user ID) [Subs-Members.php] - deletes the member in the CMS/portal
integrate_exit(whether or not to show the footer) [Subs.php] - sends output to the portal and ends execution
integrate_login(username, hashed password [if set], session length in minutes) [LogInOut.php] - logs the user in
integrate_logout(username) - logs the user out
integrate_redirect(location, whether or not to send a refresh header) [Subs.php] - redirect user to someplace in portal/CMS following posting of form data
integrate_register(username, registration variables, theme variables)
integrate_reset_pass(username, username [for password salt], new password [unhashed]) [Profile.php]
integrate_validate_login(username, hashed password [if set], session length in minutes) [LogInOut.php] - validates the current login (makes sure everything is correct)
integrate_verify_password(username, current (un-hashed) password, false) [Profile.php] - verifys that the password entered is correct (not sure what the third parameter is for...)
integrate_verify_user - makes sure the user is who they actually say they are

There aren't any functions to actually update the user in the CMS/portal, but this could be added pretty easily if needed.

Quote:

Did you forget about our API?

I'm not even going to bother commenting on why so many people want SMF over IPB, phpBB and newBB/CBB because that has nothing to do with integrating XOOPS and SMF. The simple fact that people want it should be enough to at least look into the option. I am going to continue to monitor this topic, and the project, and hopefully someone will get things done, even if you don't want any part of it.

I would be willing to donate some money towards the project as well. I am currently busy working on integrating Gallery 2 with SMF (and it's coming along quite nicely), but would love to help out with a XOOPS/SMF bridge as well. I spent some time the other day playing around with XOOPS at Opensourcecms.com and think it has a ton of great features that many SMF members would love. So why are so many developers against working with SMF to come up with a bridge?