Notes on implementing the Profile Module included with XOOPS 2.3.x and beyond. Also, some notes on migrating from SmartProfile which I previously implemented.

Version: 1.52 (included in XOOPS 2.3.3b) - 1.57 (included in XOOPS 2.4.4)

This module was originally included in the XOOPS 2.2 release that became an abandoned branch for a number of reasons I won't go into and was merged with the 2.0.x branch into 2.3.x for the forward direction. I had been using SmartProfile. Both SmartProfile and the Profile module use the XOOPS 2.2 profile module as the starting point, so migration is fairly easy. And I ran into problems using SmartProfile on the XOOPS 2.3.x branch, so now I migrate all over the the Profile module which is for the best anyways.

Overall the Profile module does the job, although we'll have to update it some. These notes remain incomplete, but can likely help others.

Installation and Configuration

Install and configure like any module.

If using xoRewriteModule in XOOPS 2.4.x (1.53+), you'll want to edit profile/preloads/core.php to point to the proper hard-coded URLs (at least it's all in one place, now); if using 1.52, you'll likely want to edit a few XOOPS core files to fix the hardcoded redirection URLs: edituser.php, lostpass.php, register.php, user.php, and userinfo.php.

If you want user groups to be editable by the Profile administrators, you'll have to give that group those permissions in the system module.

I made a few changes of course

I updated xoops_version.php to only admins would see the Search Users link. I updated search.php so only admins could access it. And I made some change to userinfo.php that I need to diff. Probably need to diff the entire module because I've slept since then.

Migrate From SmartProfile

• Install module
• Create Categories, Registration Steps, Fields, Permissions to match those in SmartProfile
• Migrate _profile table data from SmartProfile to Profile using phpMyAdmin
• Revert changes to edituser.php, lostpass.php, register.php, user.php, userinfo.php, and mainfile
• Merge/Migrate templates as appropriate
• Merge/Migrate language changes (remove root/lang*/eng*/mail_templates/ symlink)

Errors / Bugs / Defects

Some bugs I ran into:

• Should save password and disclaimer info even if error
• users should be able to see their own fields - at least the ones that are configured
• admin, fields page: sorts by categoryid, not weight
• can't edit user groups (can but must change permissions in the system module)
• fields page should show more info/allow same editing thereof

Multi-Step Registration Save

There is an error in 1.52 if you have a multiple-step registration process. To "solve" either upgrade to XOOPS 2.4.x which has a fixed version, use a single-page registration process, or save after every page (but the account is created and thus many will stop the process).

Email Address Duplicates

Users may specify a duplicate email address which can interferes with lost password functionality since XOOPS will only email the first one found.

Activation Resend

activate.php - it's nice that we have the ability to resend the activation code, but there aren't links to it, and the form is untitled in the code. Added instructions, too. Should be able to not allow reactivating of disabled accounts.

Miscellaneous

root/class/xoopsmailer.php added the {IP} tag (should be in the core IMHO) (my rev already had the {X_NAME} for {REALNAME})

$name in templates? Had to put PHP code in the template.

Lost Functionality

SmartProfile Had these and Profile doesn't

• SmartProfile duplicated the preferences for the System User Preferences so that a Profile administrator could make some of those changes without being a System level Administrator.
• Ability to show/not show empty fields in the profile.
• Latest submissions on/off.
• The require disclaimer doesn't show/require if the disclaimer text is empty -- it should still require checking the I agree box.
• Allow/disallow users changing email address.
• Also, it would be nice to make users have to confirm their email address before it is actually changed (since this could allow hijacking of accounts if left accidentally on at a public computer) -- at least it requires a password, but what if it's mistyped and you can't communicate with the user any longer and they don't get notices, etc?

module index.php page sorta circumvents using the user.php page, but then pulls from the system_userform.html template. Easiest fix is to just put the same form in that template. The coded fix would be to redirect to the user.php page or until then, change to the profile_userform.html template in the index.php code.

HTML in Functional Layer

Unfortunately, there is still HTML (including style info) in the code.

A lot of language comes from the main XOOPS language files. Maybe this module should pull them from those constants and/or use their own?

Required Fields Doesn't Work Correctly

Seems to still be a problem with the required_field settings in the module showing correctly. To find the fix as I implemented in SmartProfile, I should check against SmartProfile.