dorje

  • Krabi krabong: the wedge of martial arts. :P
  • Posts: 97
Re: Once upon a time...
« Reply #30, on November 10th, 2011, 02:58 PM »
Quote from Arantor on November 10th, 2011, 12:15 PM
updateMemberData is supposed to update the row, and it should then kick in on the next page load (if you want it to be active in the current page load, update $user_info yourself)
So there is no function to reload data?

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?
Quote from Arantor on November 10th, 2011, 12:15 PM
Note that not everything in $user_info is taken directly from the members table, so it would be interesting to know exactly what you're trying to update and how.
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. :)
Quote from Arantor on November 10th, 2011, 12:15 PM
As for asking questions, for the most part they will be relevant to Wedge as well, so there's no real harm in asking, and it has been known to prompt me to fix things I'd known were broken but never got around to fixing.
Ok, happy to read this. :)

I'll do my best in smf-bugfinding and I'll pass you informations! :eheh:
Quote from Arantor on November 10th, 2011, 12:15 PM
(The reason it doesn't update the current member is because it's a general purpose function for addressing any and all members, not just the current user.)
Right. I forgot that admins can change user profiles of other users! :whistle:
Quote from Arantor on November 10th, 2011, 12:15 PM
(I should note it doesn't bother me that people are asking questions. What bothers me is that I can still answer questions for SMF, and still do a better job of it than the bulk of their support team *put together*. That's not me blowing my own trumpet, it's the fact that I'm not going to fob you off with some 'I'll reply if and when I know the answer' crap. If you don't know the answer, fine. But stop fucking about with telling people how you don't know the answer, and go and find out. I'm sure more people will appreciate having an answer that's useful after 10 minutes instead of being fobbed off after 5. Here endeth the rant -_-)
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... :)

Thank you. ;)
Krabi Krabong & programming :D

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Once upon a time...
« Reply #31, on November 10th, 2011, 03:15 PM »
Quote
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.
Quote
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.
Quote
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.
Quote
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.
Quote
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.[1]

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.
 1. I learned this the hard way. Took me a while to realise it, too.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

dorje

  • Krabi krabong: the wedge of martial arts. :P
  • Posts: 97
Re: Once upon a time...
« Reply #32, on November 10th, 2011, 04:25 PM »
Well, I've got an intresting answer @sm.org, that solves my question

And the answer demonstrates that my question was not well posted...

It'll be intresting to consider why a user posts a question in wrong way (as I did). The english knowledge is an impediment for sure, but maybe we can find also other reasons (and consider them in the future for support). :)


Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Once upon a time...
« Reply #33, on November 10th, 2011, 04:31 PM »
An interesting answer, yes. I'd forgotten about $user_profile, since you were talking about $user_info, I figured it was letting the user update their own settings rather than someone else's. (Though, intriguingly, virtually everything else stays the same; $user_profile just holds the same details for every user, $user_info holds a bunch of stuff for the current user, but all arguments about whether you reuse the information on the page hold true either way.)

On the whole, it's a pretty good answer from AngelinaBelle, there, the only thing that would have made it perfect is understanding what the cache level parameter is doing. Specifically, that ties into the cache level settings in the cache subsystem.

Level 0 is off, level 1 is the basic level of caching, and occurs on files if necessary or if a proper cache backend (XCache, APC, memcached) is specified. Level 2 and above physically require a proper cache backend, and don't really apply to file caching, and unless you have a really good reason you won't be using level 2+ anyway because you likely end up with more stale data than you really want, meaning that loadMemberData doesn't really ever fetch from cache for most users.

Dismal Shadow

  • Madman in a Box
  • Me: Who is Arantor? Cleverbot: It stands for time and relative dimensions in space.
  • Posts: 1,185
“I will stand on my ground as an atheist until your god shows up...If my irreligious bothers you much, and if you think everything I do is heresy to your god I don't care. Heresy is for those who believe, I don't. So, it isn't heresy at all!


   Jack in, Wedge,
   EXECUTE!

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278