Profile Values Saving Inconsistancy

Sorry for a second post, but I realized that while this bug is still operating, my website is in maintenance mode, and no one can access it, so I changed the priority to "critical". Please understand that I have customers all over the United States who are paying to be able to use my website, and are quite unhappy with it being down...

Here's some more information (warning, it's quite detailed):

When a user is authenticated upon login, the "$user" object is built by the "user_load()" function, and it actually gets all the information from the profile module, as well as a few other places. However, this is the only time that all the user's data is available. For every other page load and pass through the Drupal code (in this session, however long the cookie lasts), the "$user" object is built in "session.inc", [apparently] _before_ the "user" module is loaded. Because of this, "session.inc" does not have access to the "user_load()" function and simply queries two tables in order to build the "$user" object (it queries the "user" and "sessions" tables), which populates the same global variable, "$user", with insufficient data, thus creating the noted inconsistency, and lots of potential problems.

I have been using the Komodo IDE application to do some in-depth debugging of this issue, and the following is a summary of my results:

• When a user logs in, "$user" is created correctly and contains all predicted user data, this is done through the "user_load()" function
  • This happens on the first "pass" through the Drupal code, unless another module intercepts the page load before the login form is processed and halts or redirects the load process
  • Callstack:
    

    user.module, line 966, in user_authenticate
    "          , line 929, in user_login_validate
    form.inc, line 0, in call_user_func_array
    "       , line 575, in _form_validate
    "       , line 400, in drupal_validate_form
    "       , line 253, in drupal_process_form
    
    [Common Callstack 1]
    
    "       , line 80, in drupal_get_form
    user.module, line 551, in user_block
    module.inc, line 0, in call_user_func_array
    "         , line 386, in module_invoke
    block.module, line 689, in block_list
    theme.inc, line 1013, in theme_blocks
    "        , line 0, in call_user_func_array
    "        , line 170, in theme
    phptemplate.engine, line 171, in phptemplate_page
    theme.inc, line 0, in call_user_func_array
    "        , line 170, in theme
    index.php, line 33, in {main}
    
    [/Common Callstack 1]

• Then "hook_user($type='login')" is invoked
  • This happens on the same "pass" through the code
  • Callstack:
    

    [Common Callstack 2]
    
    user.module, line 955, in user_login_submit
    form.inc, line 0, in call_user_func_array
    "       , line 428, in drupal_submit_form
    "       , line 258, in drupal_process_form
    (Insert Common Callstack 1 from above)
    
    [/Common Callstack 2]

• Then my login code is called/"invoked" by the hook described above
  • Same "pass" still
  • Callstack:
    

    myModule.module, line 12, in myModule_user
    user.module, line 22, in user_module_invoke
    (Insert Common Callstack 2 from above)

• My code (myModule.module, ~line 12) calls "drupal_goto(myModule_myCustomFunction)"
• Begin Second "Pass" through Drupal's code for this logical request (e.g., the page is still loading from the end user's perspective, but Drupal is running through all of its code from the top all over again)
• The variable "$user" is created, but this time not through the "user_load()" function. As described above (before this debugging report), _this_ time, the "$user" object is created in the "session.inc" file, apparently before the "user" module has been loaded; thus, since "user_load()" is not available to call, "session.inc" simply runs a SQL query on the db to get the basic user info, but Drupal doesn't attempt to get the rest of the user data later in the load process. This is the root of the bug this report is making note of.
  • This happens on the second "pass" through the Drupal code during the initial login request, but for _all_ subsequent requests in this session, this happens _first_, and the "$user" variable is never given all the correct data
  • Callstack:
    

    session.inc, line 32, in sess_read
    session.inc, line 0, in session_start
    bootstrap.inc, line 811, in _drupal_bootstrap
    "            , line 771, in drupal_bootstrap
    index.php, line 13, in {main}

Please note that I haven't found a way to copy/paste data out of the Komodo debugger, so all of the above is hand-typed; please excuse any typos.

Anyways, this gives us a much better look at what is going on, and where the problem is (line 32 of session.inc). Possible solutions include, but are obviously not limited to having the Drupal core rebuild the "$user" object later in the load process, or rewriting some of the process to give "session.inc" access to "user_load()". It is obvious that the inconsistency in the value and contents of the "$user" variable, which a significant number of modules (core and contrib) rely on for information, must be corrected. I have changed part of my custom module to run its own "user_load()" in order to work around the bug for now, but this is aweful coding, since "$user" is supposed to already be built for the current user...

Please let me know how I can provide more information or help in getting this bug patched, as it appears to be a part of the general distribution of Drupal 5.1, and thus may result in untold numbers of bugs, and it will likely not always be evident that this is the cause.
Thank you.
Denver Root

Umm, I'm sorry; is someone going to review this? I was under the impression that this is where I should report bugs, and that action would be taken to remedy the issue...

Please correct me if I am handling this the wrong way.

Yes.
Following your prompt, I setup a new site with a new database, logged in (after creating the first user), enabled the profile module, and added a single text-field with the [paraphrased] checkboxes "required" and "on registration form". There are no contrib or custom modules enabled for this site.
I then did some testing, and the exact four things I noted in the creation of the issue (numbered 1-4 above) still behave the exact way in this [clean] installation of Drupal 5.1.

Thoughts? Do you need more info? I could send you a dump of my db (small, since it's empty) and a copy of my drupal installation (minus private code in the sites dirs, since none of this will apply except for one settings.php file). If you'd like a callstack for the code that saves the profile data into the "user" table instead of profile_fields, just let me know.

Thank you!