So there is no function to reload data?
No, because of the nature of updateMemberData. It is designed specifically for updating multiple members at once, not just the current member. Consequently it's more work to update the current member's data, especially since virtually every single time it's used, it's then pushed through a redirect and so it will be reloaded on the next page load.
You could, I guess, call loadUserSettings() but I really wouldn't recommend it, especially if you already have the data handy, having just validated it, you could just update $user_info there and then.
How does it work when I change my forum profile in the default profile form in smf? It sends data, executes the update and then reloads the page?
By calling updateMemberData, going through a redirect and reloads the page.
Well, only email and password fields at the moment... So I'll update the array in the update script. It really isn't a problem, I only wanted to know if there is a way to do it using existing functions.
Unless you're going to be using right there and then to do something (i.e. in the scope of the current page load), there's no need to reload $user_info. Even if you *are* using it in the same page load, you have it available to work with.
I'll do my best in smf-bugfinding and I'll pass you informations!
All bug reports are useful, even if they might not seem like bugs.
That's the point. For example: I don't require that smf has a function to update members data. There can be tons of simple "workarounds" for doing that. But a simple answer like yours can really route a user in the right direction, without wasting time in looking at something that simple doesn't exist...
*nods* This is one reason I actually don't like doing support. People ask a question and they expect their question answered, except that very often I find they're asking the wrong question. Sometimes intentionally, often not.
In this case, for example, you're asking about reloading $user_info after a change. The real question isn't how to update $user_info, but whether you actually need to or not. If you're not using that information for anything for the rest of the page view, there's no need for a reload. Even if you are using it in the exact same page load, as you seem to be, and you're just using $user_info as convenience, you can trivially update $user_info there and then anyway once you have it. Don't forget there's also $context['user'] to consider.
Or you can do what SMF does and leave page flow to force it to be reloaded anyway. Depending on what else you're changing on that page it might be advisable to just do that.
Incidentally, email and password are tricky things to deal with. Not so much password, assuming you get the hashing right and make sure the other fields are left alone, but email is, because normally it's supposed to retrigger email validation (assuming that's turned on) which is a raft of other changes that updateMemberData doesn't automatically deal with. (Most importantly, it's going to reset is_activated from 1 to another number, though off hand I can't remember what that number is, because I don't think it's 0. There are something like 9 different legal values for is_activated, too.)
Getting back on point, I realise that not everyone knows SMF/Wedge's code like I or Nao or others do. What I would hope and expect to see is how volunteer support boards that are worth a damn should work: those who know the general stuff (which is, to be fair, what the majority of topics really are) can answer the general questions. Anyone can answer them and most questions do not require intimate knowledge of the system.
Then for anything more complex, the quantity should be lower but so too is the quantity of people who can answer them. But it's in this field where people have the real chance to shine; it doesn't take that much knowledge to follow through the bulk of SMF, no matter how huge it seems, and it often doesn't take more than a minute or two to scan through the source for the area that controls something. I learned a lot of the specifics about SMF by doing just this, and I really think some of the team would *really* benefit from this approach. Kicking back questions doesn't help anyone, it's just ego stroking for the person doing it.
But in most cases, the total time spent kicking someone's post back (followed by the inevitable apology and further kick back) could have been used to find the real answer.