Improper placement of “field category groups” on new user registration page.

Module: profile.module
Module Description: Supports configurable user profiles.
Profile.Info
Version: version = "5.1"
Project: project = "drupal"
Profile. Module
// $Id: profile.module,v 1.189.2.1 2007/01/23 19:09:58 dries Exp $

Issue: Improper placement of “field category groups” on new user registration page. Order of Groups not as expected.

Test Environment:
Platform: Windows XP, XAMPP, APACHE, PHP 4.4
IDE: NuSphere PhpED Version 4.6.3 Professional
Debugger: Integrated with NuSphere

This issue involves several related issues:
Issue # 124639 – http://drupal.org/node/124639 Table “profile_fields”...
Issue # 124641 – http://drupal.org/node/124641 “Broken Sort Algorithm”

Observed Problem: Order of “category sections” on new user registration page is not correct, and is not controllable under current design and code implementation.

Conditions to Test / Verify Problem exists:
Use the “admin/user/profile” page to create some new “fields” to be included with the user profile, and select the option to be “Visible in user registration form”. Add several fields such that you have several “category” groupings and several fields for each “category”. Apply weights to each field. Also select option for “Public field, content shown on profile page and on member list pages”. Example:

Log out, then click on “Create Account” to display the “../user/register” page. You will see that your “category” ( with contained fields ) are nicely displayed on the page. However, your categories will be “before” the “Account Information” section that is “system generated” for the page. This is not desirable. This also exposes the underlying problem of not being able to control placement.

It also exposes an underlying coding error in the “_user_sort” function of “user.module“ ( see issue http://drupal.org/node/124641 )

Problem Cause:
The “category” ( used for grouping ) does not have user assigned “weight”, so the system, in function “ “, creates a weight for each category based on what appears to be an arbitrary values of “0,1,2”, etc based on order returned in the SQL statement to retrieve the fields / categories from table “profile_fields”.
The function “_user_sort” in module “user.module” is broken and does not work in all cases, which contributes to the problem ( refer to separate issue http://drupal.org/node/124641 ).

Details:
When form elements are being built in the $form array, some elements are added with the “#weight” array item, and some are not. Some are added by the system with a #weight of “0”, and some are added by the system with #weight values of “.0001”, “.0002”.
When “user added” ($extra ) form elements are built (in function “profile_form_profile”), sorted (in function “uasort()” called from function “_user_forms” of user.module), and merged with the $form array ( in function “user_register()” of user.module), there are also array items that have #weight array items with a value of “0” or less.
Therefore, when the “final” sort is done in function ” _element_sort()” called from function “uasort” in drupal_render(), the result is unpredictable ( subject to sort algorithm ) and usually not correct.

Remedy:
Part 1 - This is a workaround that I have created and tested to allow the “user added” category and contained fields to appear AFTER the system generated form elements. It essentially starts the “seed” for generating “user added” category “weights” to be greater than system generated fields. The patch is made to function “profile_form_profile” and is (patch file attached “profile_category_seed.patch”:
- $w = 0;
+ $w = 1; // Seed at > 0 to position custom added groups after system defaulted ( non-weighted) groups

Part 2 – Implement patch shown in issue # http://drupal.org/node/124641

Part 3 ( long term ) – Database structure change, Issue # 124639 – http://drupal.org/node/124639 Table “profile_fields”...

Note: I can provide additional information, including screen prints from debugger sessions and page output if required, but wanted to get this thread going and keep this node short (smile)….