Skip to main content
Topic: $user_settings VS $user_info (Read 3461 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

$user_settings VS $user_info

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... :-[
Bugs creator.
Features destroyer.
Template killer.

Re: $user_settings VS $user_info

Reply #1
Yes.

I totally agree.

 Antechinus imitates Ema talking about CSS :D
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: $user_settings VS $user_info

Reply #2
idea:
$user = array_merge($user_settings, $user_info)
Code: [Select]
global $user, $scripturl, ...;
Sorry for my English

Re: $user_settings VS $user_info

Reply #3
idea:
$user = array_merge($user_settings + $user_info)
Code: [Select]
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.
I am currently doing freelance work. If you need coding help, forum help, or server maintenance, shoot me a PM and let me know.

Re: $user_settings VS $user_info

Reply #4
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... :-[
$user_settings is the db dump. $user_info is a collection of choice variables from the aforementioned array , formatted for general use.

idea:
$user = array_merge($user_settings, $user_info)
Code: [Select]
global $user, $scripturl, ...;
Doesn't seem like a bright idea....

Re: $user_settings VS $user_info

Reply #5
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:
Code: [Select]
...
global $user, ..., ...;
$user = $user_info;
$user['db_fields'] = $user_settings;
...

Function style:

Code: [Select]
...
$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:

Code: [Select]
...
getSmfElkarteCurrentMyUserData ('', false)
...

 joke
trick
Sorry for my English

Re: $user_settings VS $user_info

Reply #6
$user_settings is the db dump. $user_info is a collection of choice variables from the aforementioned array , formatted for general use.
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.

 emanuele is tempted to just replace those I think should not be around and see what happens. O:-)
Bugs creator.
Features destroyer.
Template killer.

Re: $user_settings VS $user_info

Reply #7
it is less than code and it is more convenient for perception

Convenient for perception of the code *matters*.

Quote
Function style:

Code: [Select]
...
$full_user_data = user();

$user_id = user('id');
$user_name = user('name');
...

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.
Code: [Select]
// 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.

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.

 emanuele is tempted to just replace those I think should not be around and see what happens. O:-)

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.
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: $user_settings VS $user_info

Reply #8
You might find you can't...
"can't" is a bit too much. :P

For example, password_salt is a low-level info which is in $user_settings, and not supposed to be carried around too much.
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.
Bugs creator.
Features destroyer.
Template killer.

Re: $user_settings VS $user_info

Reply #9
You might find you can't...
"can't" is a bit too much. :P
LOL, point taken!

Quote
For example, password_salt is a low-level info which is in $user_settings, and not supposed to be carried around too much.
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.
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?
The best moment for testing your PR is right after you merge it. Can't miss with that one.

 

Re: $user_settings VS $user_info

Reply #10
Other question: would be acceptable something like:
Code: [Select]
$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.
Bugs creator.
Features destroyer.
Template killer.