Okay, well I have been using profile since it game out. I have a friend who is switching back from SMF to XOOPS 2.5.
I was pointing out some of the things that I have used profile for, but was looking for information on what it can be used for.
All I have found so far in the way of usage/documentation of this module so far is:
-----------Profile Module
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.
http://mark.boyden.name/modules/smartsection/item.php?itemid=100&keywords=profile=====================
I did find this:
As a part of the 2.3.0 merge release of the two branches of XOOPS (2.0.X and 2.2.X), I've been asked to work on the Profiles module. This will enhance the XOOPSUser capabilities ala what was provided in 2.2.x branch and similar to what SmartProfile brings to the 2.0.x branch. Initially, we'll just do the merge with any simple enhancements that make sense. Then for 3.0, or for future 2.3.x releases, we'll work on the rest of these enhancements.
What we need:
* Your feedback and comments, suggestions, enhancement requests, etc. (Discuss in the forums, synopsis info captured here).
While I won't guarantee everything makes it into this module for this version, we will strive to bring appropriate enhancements. I've started on the various requirements below. Please let us know of any other aspects you wish to see. I'll keep this updated as we move on this development. Thanks!
Functional Requirements:
Red part is added by irmtfan
mboyden: please evaluate red parts and edit what you like to be remain
1. Backwards Compatible (all the old standard calls work as before)
1. Standard XOOPS Fields
2. Custom Field Attributes
1. FieldName (for Database)
2. Title (Display) - Text
(255 max)
3. Description - Text (255 max)
This is too low for multibytes languages
1.
1. Category - Select from Categories
2. Weight (Sort Order is a better nomenclature for English speakers and more understood by clients) (int >=0)
3. Type - Select from Field Types
4. Required - bool
5. Registration Step (Any or none) - Select from Reg Steps
6. Default Value - (dependent upon Field Type)
7. Possible Values (dependent upon Field Type)
8. Permissions
1. View
1. System (bool)
2. User May Decide
Users from group XXX can View fileds from group YYY
XXX can be equal to YYYY
1.
1.
1. Edit
1. Admin Groups
2. User Groups
Users from group XXX can Edit fileds from group YYY
XXX can be equal to YYY
1.
1.
1. Search
Users from group XXX can Search fileds from group YYY
XXX can be equal to YYY
1. Categories
1. Title
2. Description
3. Sort Order (aka Weight)
2. Registration Pages
1. Title
2. Description
3. Sort Order
4. Final Step?
3. Fields Types
1. Generic
1. Checkbox
2. Radio Buttons
3. Boolean (essentially a Yes/No Radio Buttons prefill)
4. Select (Drop Down or Multi)
5. Text
1. Max Field Length
2. Display Length
6. Text Area (with ability to select XOOPSeditors)
7. Date/Time (configurable display using PHP format;)
1. Date Only
2. Time Only
3. DateTime
8. File
9. Image
1. Min/max height/width - Auto resizing
2. Image upload (smart mimetypes?)
3. Multiple images (blob or file, most likely file)
2. System
1. System Groups Select (one or Multi)
2. System Language Select (one or Multi, prioritized)
3. TimeZone Select
4. Registration Process
1. Multiple Page Registration
5. Administration
1. User Management
1. Admin Area User Edit (Super-Users Only)
2. User Edit in Front End per Group Permissions
3. Enable Account
4. Disable Account (disables activation)
5. Delete (Terminate) Account (look for any posts, comments, etc.?)
2. Category Management
1. View Categories
3. Field Management
1. Display/Basic Edit
1. Field Title, Short Descip, Type, View Perm (Sys), Req'd, Category, Reg Step, Sort Order
2. Edit/Delete/Duplicate
4. Registration Step Management
6. User Edit
1. Admin Edit per Group Permissions
2. User Edit per System Permission Control
3. Password Change (requires old password, new twice)
Users from group XXX can Edit fileds from group YYY
XXX can be equal to YYY
1. Permission Control on each field
1. System (view: reg/anon; edit)
2. User (view: reg/anon)
2. Presentation Layer (via Smarty Templates)
1. Not XOOPS Forms (to allow for better control over display/formatting)
3. Preferences
1. Standard XOOPS Configuration (Link to and/or allow edit from Profiles prefs page admin)
1. Min/Max Login Name - no change (text, int)
Change is needed because some value are hardcoded and now the maximum is 25 characters for English and 12 characters for 2-bytes languages
1.
1.
1. Login Name Strictness Level - no change (select)
2. Min Password - no change (text, int)
3. Allow New Accounts - no change (bool)
4. Allow User Delete Own Accounts - no change (bool)
5. Allow User Change E-mail - no change (bool)
6. Site Policy - text area (DHTML and/or WYSIWYG from XOOPSeditors?)
7. Display Site Policy - no change (bool)
8. Bad Login Names - no change (textarea)
9. Bad E-mails - no change (textarea)
10. Reg Notify - drop down select, add new User and Admin
1. Instant (Not-Recommended)
2. User Confirmation (Default, Recommended)
3. User and Admin Confirmation
4. Admin Confirmation
11. Reg Notify Group(s) - change to Multi-Select
2. Max Password - needed (probably not)?
3. Password Strictness - select ala SmartProfiles, maybe done via Javascript per cPanel, etc.?
4. Show Empty Fields - bool (should this maybe be per field?)
2. Notifications
1. User
1. Registration Submitted
2. Lost Password
Current process really confuses newbie members. It should send just one email. When user click on the link it should transfer to a page in the site in which request from user to input the new password.
1.
1.
1. User Activation Request
2. Admin
1. Registration Submitted
2. User Confirmed (note about Admin Activation if nec)
3. User Activated (by User or by Admin User or by Admin)
4. User De-activated
5. User Deleted
2. Activation
1. Send Activation Code (only if not activated)
2. Re-send Activation Code (only if not activated)
3. Account Disable
1. No longer allows activation code to be sent
4. Miscellaneous
1. XOOPS files for old functionality
1. register.php
2. userinfo.php, etc.
2. Defaults
1. User Fields
1. Login Name (XOOPS username) - Text, Private
2. Password - Text, Private (requires twice; strength indicator via Javascript)
3. First Name - Text, Private
4. Middle Name (or Initial) - Private
5. Last Name - Private
6. Display Name (XOOPS RealName) - Public
Can be Enabled by admin – if not enable it should be same as login name.
1.
1.
1.
1. Birth Date - Private
2. Organization (XOOPS OrgName) - Private
3. Street Address
4. Signature Field
1. enable/disable text, images, html, etc.
2.
set max and min size of image in signature
3.
set the max number of allowed links in signature
5.
sex
2. Avatar - use current XOOPS functionality
1. expand to have min/max automated resizing for clueless uploaders
3. Help
2. Pre-Register with Validation Code
1. Codes are single-use
2. Have expiration date
3. Able to add to 1+ (multiple) groups
4. Able to send e-mail to users when uploading
5. Bulk upload capability
3. Auto-Login (with security risk disclaimer)
1. Can turn on and off in system preferences
2. Can turn on/off per user
4. Groups
1. Groups can have groups as members (inheriting rights)
Enhancement Requests
1. Make XoopsUser useful info available in the Smarty Templates
2.
Security:
1.
Hidden field: only robots are fool enough to fill a hidden field so we can check and if this hidden field is filled then it should be a robot (Madfish Idea)
2. CAPTCHA
1. Allow usage (enable/disable) of CAPTCHA in registration form
3.
register insert js check (Gijoe – plugin in protector)
4.
salt password:
1.
change the hash algorithm to prevent dictionary attacks being run against captured hashes: for example: new pass = SHA-256(salt password + md5(current password)) (DaveL and Mithrandir idea)
5.
sessions: ability to delete a user session. currently when you assign a user to "banned group" it doesnt take effect until he logout
3. View Profile
1. Preference to turn this on/off (with redirect)
2. On - Users see basic info (display name, on-line status, etc.) minimum
3. Registered users may send message (if enabled)
4. If per admin/user prefs, e-mail address visible, along with other fields (show empty if enabled) (maybe show e-mail as image, not text -- altho problem with sight-disabled persons)
5. Updated display of last login date/time (e.g., 2 days ago, 2 hours ago)
6. Additional display/page for user posts (instead of at bottom of page)
4. Comments - Use XOOPS Comments
5. Ratings - maybe 1-10 in a few areas
irmtfan
there should be 2 part in the profiles. part 1:(base Profile) login name , pass , email these fields should be remained in XOOPS Core and not Profile module. so everybody can uninstall Profile module and still all users base information are remains in the database.
part 2: extensible profile system.
* display name that can be enabled from admin by yes/no
* all other fields should be flexible ( you describe it in detail)
* rating system so users from group XX can vote for users from group YY
describe: can we extend it by define a calculate system? you see all other fields can just get one entry not multi entry. can we name it a "Multi Entry" field?
* scrapbook
* my blog and my page
* my gallery
(mboyden responds...) I agree, and both parts 1 and 2 are incorporated into the design. As to the rating system, yes, that could be done, and I'll add it into the wishlist. I'd like to see a XOOPS-wide rating capability similar to what is done with comments and such. Per discussion in the forums, scrapbook, myblog, mypage, mygallery belong in other modules. .
[stefan88]
* ) multilevel groups - for example "Group 1" with subgroups "Group 1.1", "Group 1.2" ...
* ) Plugins for the user page. The admin adds a file in some plug-in folder, that will give some extra info in user profile. For example that will give a horoscope/biorithm based on users birthday...
