Apparently I never looked too deep into SMF's code (or not deep enough).
What's the difference between the two?
As far as I can understand $user_settings contains the almost untouched dump of the members table plus some goodies, while $user_info contains 95% of the same things plus more goodies.
Why do we need both in global?
Can't we live with just one of the two?
I know it's a noob question... :-[
Yes.
I totally agree.
/me imitates Ema talking about CSS :D
idea:
$user = array_merge($user_settings, $user_info)
global $user, $scripturl, ...;
I know someone is going to say "do it" but I am not getting in to that now... I would just recommend that if you are going to go down that route, $user should be a class so you can control who/how the properties can be edited and either pass that in to the controller (and then wherever you need it) or use something like was done with db() where you use $user = getCurrentUser() or something instead of using another global. You can even do the later without making any substantial changes and still have backwards compatibility.
$user_settings is the db dump. $user_info is a collection of choice variables from the aforementioned array , formatted for general use.
Doesn't seem like a bright idea....
I simply offered :)
it is less than code and it is more convenient for perception
and the dumping of data base can be inserted into a separate key
Global style:...
global $user, ..., ...;
$user = $user_info;
$user['db_fields'] = $user_settings;
...
Function style:...
$full_user_data = user();
$user_id = user('id');
$user_name = user('name');
...
Ultimate style:if you don't like short names, it is possible to make the name of function more detailed:
...
getSmfElkarteCurrentMyUserData ('', false)
...
joke
trick
That was mainly my perception.
Though there are some uses of $user_settings that seem odd to me.
For example the one in ManageServer.php or in ModerationCenter.controller.php or PersonalMessage.controller.php, etc.
/me is tempted to just replace those I think should not be around and see what happens. O:-)
Convenient for perception of the code *matters*.
I think this is a good idea. I've played in the past with a current_user() function, to get the user data and hide from the caller how you get it (from $user_info, from a class, from other $user vars).
The advantage of doing this, is not only the simple removal of the global. (at the price of an extra-call, but that's always the price.) It's also that, if we make a function, then the result is: we'd store in one place the creation and updates of $user_info. Which will be very useful later (anytime later) when we make a class of it, since only the backend would change. I mean by backend in this context, the implementation of the function/s.
// retrieve
$user_name = user('real_name');
// update
user('real_name', 'another name');
However, I can't tell if currently, this would involve more changes with a benefit not close in time. So I kept these as they are, (and I won't go for this) as long as they're not standing in the way.
You might find you can't... For example, password_salt is a low-level info which is in $user_settings, and not supposed to be carried around too much. But, the more replaced where possible, the better, IMHO. There might be inconsistent uses... and if we go through them and knock them down, it can help. Just a thought.
"can't" is a bit too much. :P
The point is that they are brought around any way: $user_settings is a global, so is around for use anywhere you can globalize something.
Now, at that step, maybe something in between the two options could be a possibility: use a function to set/retrieve/alter values of $user_settings, while continue to use $user_info.
LOL, point taken!
Of course, as long as they're globals sure they're ... blessing us with their globality all around us. :P
Sounds good to me. There are far less uses for $user_settings, and they're supposed to be low-level (in the sense of directly coming from db storage). But will it really help with the potential confusion on their usage?
Other question: would be acceptable something like:
$user_info = $user_settings;
unset($user_info['passwd'], $user_info['salt']);
The query that loads $user_settings is one of the few that loads all the fields in {db_prefix}members, and something like the code above would allow to have in $user_info any new field added by addons by default.
Yes, it may be that an addon adds a field that should not show up in $user_info, but it's unlikely as far as I can imagine, much more frequent that people add fields to members and then want to use it somewhere else.