The global $user variable should always contain the data for the currently logged in user. If you're not using any custom modules that affect users, this is what happens. However, when the node API is used by another module, $user isn't always filled in completely. Immediately after login, when the $user variable is updated a second time, after the session is loaded, things work fine. However, in situations where the session loads the variable, the node API is not called. Any data added to $user by a custom 'load' function will be missing.
Specifically, the sess_read() function located in session.inc loads users from the database without calling user_module_invoke('load',...). The obvious fix for the bug, adding in the user_module_invoke(), doesn't work because sessions are initialized before modules.
I marked this bug as "normal priority" because it doesn't affect end users, but it's "critical priority" for Drupal developers. Bugs like this make the platform seem unstable, which makes developers move to other platforms that may not be as feature rich, but feel more stable.
Comments
Comment #1
moshe weitzman commentedi'm not too familar with when this bug shows up. are you referring to cached pages? those are deliberately invisible to most modules. we want these pages to be fast.
if you are referring to non cached pages, then it sounds like we need to load up $user after module_init().
Bugs like this make the platform seem unstable, which makes developers move to other platforms that may not be as feature rich, but feel more stable.
is this sort of comment necessary? isn't there a more polite way to make your point. i think politeness is the least you can offer to drupal developers who donated this application to you for free. please email me privately if anyone wants to discuss this further.
Comment #2
Jerk Face commentedI have only tested this with the cache turned off.
Sorry if the comment about this being a "critical priority" for developers seemed derogatory. I only meant it to be a clarification of the priority of this bug beyond what I was able to codify in the bug tracker. In general, I think it's worthwhile to include this sort of higher level discussion about what the social effects of a bug will be.
Comment #3
killes@www.drop.org commenteduser_load is simply not called on every page load for performance reasons.