Wedge

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.By calling updateMemberData, going through a redirect and reloads the page.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.All bug reports are useful, even if they might not seem like bugs.*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.

See, the whole nature of doing that would never have occurred to me. I'd have just used a regular select.

Mind you, if that's styleable (e.g. to put an image next to the item text)... I can think of many good uses for that.

I'd assume that newlines should be stripped before sending to preparsecode, but that's the only gotcha as far as I'm concerned.I had a horrible discovery on that note the other day. I put a thought reply of 'I made him say <odd item> though... ' in and I was more than a shade bothered when I found it didn't protect the tag on the inline save (but of course it is when it's held on the backend, and reloading the page is of course fine)Really? Fairly sure I've put links in footnotes before and it worked as expected. In other news I've been quietly wondering if the footnotes couldn't be made even more awesome: if you have two footnotes with the same contents, I feel that only one entry should be put at the bottom and the same number used in both cases. The main reason this came into my head was because for one thing I want to do, I want to be able to do Wikipedia like citations by reusing footnotes instead of having to roll my own (because I have a project in mind that I would rather use a customised Wedge, or even a customised SMF,[1] for than MediaWiki)I know the feeling. I'm currently tackling moving the calendar into its own plugin. It's... interesting.Side note: I seem to recall the bbcode parser will chew through uppercase bbcode e.g. [WHITE] but tags like that won't be converted, because the regular expression just replaces white|blue|black|red|green with color=$1 without any callback or inline eval to strtolower it. (Since this is at preparsecode time rather than display time there's no reason why it couldn't be rewritten to use a case-insensitive match and strtolower it once found)Chrome doesn't like it for some reason. This was off a totally fresh install, too.

1.	As much as developing on Wedge is awesome, for a project that is a one-off codebase, I'd rather build it once and leave it without having to do regular patching and updates, if that makes sense.

That's Brighton Pier. (It's in The Snowman, as is the Taj Mahal-styled 'Brighton Pavilion')I must have missed that somewhere.Hogwarts is implied in the books to be in Scotland, and principle filming of the castle in the films is at Alnwick Castle which is not far from the Scottish border.It doesn't have the 'weak' feeling I was getting at before, nor the 'falling off the wall' feeling... I don't particularly like it but I can't tell you why :/

If you're paying attention, they fly from somewhere just north of Brighton (and fly directly over Brighton)... which is virtually where I live...The British do strange things, but awesome ones :)Other than that episode of DW, I don't tend to cry much at TV.I like the font on the 'petal' logo most, while I like the square logo most. The petal part itself makes me think as though the lower part seems more floppy and unable to support the upper part, while the middle logo looks like the pieces have fallen off the wall, as it were.

OK, open time. Each year we watch The Snowman. Each year, I feel myself shedding a tear. Oh, and one almost got shed when Tennant regenerated. ALMOST.

I know why it's complex, but if you turn it round a bit, it makes sense.

The core attachment system has two principle weaknesses, in my book: firstly, it's not extensible, and secondly its management capabilities are limited.

Really, all an attachment is is a file uploaded to the system... Post attachments are restricted by the topic permissions, album attachments by the album permissions. The more you look, the clearer it is that they have an awful lot in common, probably more than is realised.

And I'm not really seeing the problems with doing it, other than the fear of doing it. All the issues related to how I think it can be made extensible aren't really issues at all, I already covered off how that would likely work, at least in my head, by giving each item a source to have originated from (both a place and a contextual id, such as album+1 for an item in album 1 or help desk+2 for an item attached to a helpdesk ticket, etc.)

Blog support might need tidying up, but that's it really. Just need to remember board access UI doesn't work if more boards are created.