Wedge

It's on my todo list :P

Yes, but it means doing that treatment everywhere where names are pulled directly. The alternatives are converting everything to a case of loadMemberData (minimal) or doing it in the post-replace phase, either way that's an extra query.

Hmm. I'm thinking that we could do it better by querying and caching the member group colours on a longer term basis, and fetching user+group instead, as querying every user with their group is going to be quite expensive.

It depends how fussy the receiver is. A receiver expecting Atom and gets not-strictly-valid Atom might throw a wobbly. Besides, in XML modes, there's no point running that operation, might as well save a few CPU cycles...

Works for me. Just something I wanted to be careful of, really.

It works like any other nesting, and for the most part it's pretty transparent.

Quote

Well, we could simply turn these into sub-functions and call them all from ob_sessrewrite...

That would work and would probably be faster than using true buffers to pass back and forth.

Quote

Or 'custom', in my mind.

If you're sending out a feed of new members, there's really only so much you can put into it before you break Atom format, no?

Memberlist is definitely a custom candidate. We need to decide what columns are actually needed.

Quote

I think that's the only place you get it apart from the info center... A real bummer.

Yup, it either should be throughout or not at all.

Quote

You know, you COULD revert this and no one would blame you for that...

I could but it would feel wrong. The whole solution seems hacky and I don't like it but I just don't know a better one.

Also, why would you want to pass in parameters not related to the query itself, exactly?

It wouldn't be too bad to provide somewhere that that value can be reset through a hook, and optionally a hook in the validatePassword subsystem to allow authentication plugins to safely handle admin-type security checks.

That looks familiar... :whistle:

72585

They can all go as far as I'm concerned. Even as a plugin I don't see OpenID as *replacing* the current login, but working alongside it. If FB Connect can be done as a plugin, so can OpenID, and FBC doesn't need the auth method setup AFAIK.

Quote

Yes/no. I have no idea, this hasn't been discussed in a while AFAIK.

Well, for the most part I was pretty happy to use it, and I was curious to know what you thought of it because it would require rewriting the more important queries to make them hookable directly.

What, exactly, is it for? That's the question to ask. If it's for pushing things into $user_profile, it shouldn't be needed because $user_profile just gets the entire row as-is so providing it's in the query, it's pulled into PHP-land.

I understand the logic of why it was done that way, it's primarily to avoid an extra query when that query (probably) isn't necessary,

but it doesn't make it flexible. I'd almost be inclined to add an option in the admin panel for 'use member group colours', and make everything actually use that (doing the relevant join(s) to the membergroups table as appropriate). If nothing else, it's one more that's highly desirable that really, to me, should be in core.

Now, if it were done thematically, you could really tighten up what's loaded when, though it would make bolting things into that query a lot more complicated.

I think figuring out where minimal and profile are used would be the first step,

and making minimal a shade bigger to allow for things like member-group colour (and then making it used consistently!) would help

I try to go through them, but I still miss stuff occasionally. Before our gold release, I'd like us to go through the language strings - at a minimum - to look for stray things that should have been removed.

Quote

Done in 1115, but what about %p..? We can't really transform AM to am magically... Unless we specifically try to do so...

Hrm. This smells like a partial reversion to me :/ If the format contains %p, I think we'll have to reinject am/pm instead.

Odd, I searched for 'authenticate' and 'auth_method' but I guess I somehow missed those :/

I thought we were going to use something like Dragooon's wesqlQuery structure to make those hookable?

Quote

I'm thinking we should be adding a param to the function, telling Wedge not to bother with the 'heavy' processing and just fill in the blanks. I mean, if you have 50 users in the Memberlist, that means we potentially parse 50 signatures... for nothing!

Hmm. What I'd rather do is do the minimal stuff (user name/profile/group) and optionally then add extra stuff if needed, e.g. array('avatar', 'signature', 'custom fields'). Then I'd feel more comfortable extending loadMemberContext into general use (see in a moment).

I've been wanting to add group colours for a while, just never got around to it. The real problem is that a surprising number of places do not reference loadMemberData/loadMemberContext for getting things like names, but do a raw join from whatever table into the members table to get the name. PMs is by far the worst offender for this from memory.

As I said above, it seems to me that making loadMemberContext more generally used would be advantageous, but at the same time that comes with an overhead in performance and memory.

If it were better able to be segmented (both in lMC and lMD), as to what information you're looking for, that can be avoided.

Works for me. Is there anywhere $txt['profile_of'] is used as a link description where it wouldn't have the name available to it (and so wouldn't make sense if used that way)?

Crap, I thought I'd nailed all instances, guess I didn't search so thoroughly :/

'am' and 'pm' is probably nicer looking and more consistent with what everyone else seems to use.

Quote

I've written a more 'accurate' hack for the year removal. Please review it and tell me if that's okay. ($year_shortcut is a static array, while $format is simply =& $user_info['time_format'])

Looks fine to me.