Wedge

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.

Do you want to remove them, or me?

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

Still, I'd like to know where I'm going to put the post-query hook

Not a big problem, I mean, we can always update them later... Or just don't bother.

PM example: the PM sender's name is specified with the group color. The PM recipient list isn't. Hmm...

Oh, and PT Sans + red for admin group = terribly ugly. Need to do something about that... Red is suitable for small Verdana fonts, but as soon as you make it a big font, it tends to catch attention too much.

You mean, like specifying the list of fields we want...? Or maybe a 'thematic' load or something? Like, $set is too restrictive... It'd probably benefit from being turned into one big array where items are added individually after tests are performed (if (isset($set['sig']) $select_columns[] = 'mem.signature'...?)
And then in lMC we test whether said field is present before we process it.

I'd tend to say that lMD and lMC are two of the most important functions in Wedge, and they should be handled with special care.

Removed in 1116.

Don't sweat it, that's what I'm here for...! It may take me a long time to go through your code changes but I always try to catch this kind of stuff... And I hope you do the same for me

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

I think I'm gonna go with the $txt solution where I provide the full year shortcut in the language files, and then if user doesn't use the default txt, we'll fall back to that test.

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.

Yeah... Makes sense. But considering the user won't have to choose a password (because all of this will be handled by OpenID or Facebook...), there are a few things that will still need to be added or removed... e.g. the password reminder won't work.

That's indeed a very important point. there is the password reminder, the admin-center password verification

and the profile page (account settings: password verification while changing important account data & password change in general)

I have some plans for a universal bridge  (webserver authentication, LDAP, external databases), thus I'd need a proper solution for these things...

Yeah... Makes sense. But considering the user won't have to choose a password (because all of this will be handled by OpenID or Facebook...), there are a few things that will still need to be added or removed... e.g. the password reminder won't work.

My opinion...? Too complicated. I read through the topic and then I forgot it all.
I suppose that given we won't use this in all queries, it's okay to use it. But I'm not the one who'll implement it

An extra query are you sure? I have a feeling everything can be done with a LEFT JOIN on the membergroups table...

I was thinking... Maybe, *maybe* we could 'simply' have ob_sessrewrite look through the list of links and color them accordingly... i.e. it gets the profile ID from the link, then fetches a list of users and groups. We'd just need to get a (cacheable!) list of membergroups and associated IDs. Then we can build a list of colors associated with member IDs. And voilà. We simply inject the needed CSS at rewrite time...

- profile: used in PersonalMessages.php when editing PM settings in the profile area, for use in the subsequently called saveProfileFields(), and in Profile and Profile-Modify, as expected.

* used in SSI (ssi_queryMembers), Display (load post authors), Feed (getXmlProfile), Memberlist (load member list -- serious candidate for 'minimal'), PersonalMessage (used in MessageFolder to load PM authors, MessageSearch2 for the same, MessagePost, and drafts. Used in Aeva Media's admin page to list moderators (strong candidate for deletion.)

* Used in Search2 to get authors for found posts. Used in Who.php for the Who's Online list. Another candidate for 'minimal'...

I think there will be some, yeah... It's bound to happen. But I'd rather have too many strings than not enough

I'm not sure I understand. AFAIK SMF has always used %p to show the am/pm bit... Even Wedge uses %H:%I %p everywhere (in English). Maybe you mixed it up with %P, which shows a *lowercase* version, but isn't Mac OS-compatible... (I would have used that instead, otherwise. Heck...)

On another note. I'm looking into loadMemberData() and it reminds me of the discussions about queries and making them hookable.
How about turning the stuff into something like this...?

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

That looks familiar...

I suspect that no one in their right mind would use Facebook to register/log into a forum they're administrating...

Ah, LDAP... I've never understood what this is about ;)

Heh, that's really why I wanted your input since it would require converting queries and 'big' queries would need this treatment later.

That's precisely my point. There are two routes: bolt on the left join on top of everything, every single place where member names are pulled directly (and trust me, there's a lot), or route it through loadMemberData which is an extra query.

Works for me. But note that it's essentially the same query that I mentioned above, just run at a different time.

There are some interesting side-effects to doing that in the replace hook to beware of. Firstly, we'd have to disengage it if XML output is being used.

Secondly, if there's a link in the middle of a post or something to someone's profile, that's going to be hit too.

Also, I'm wondering whether it wouldn't be cleaner[1] to put the different replace processes in their own buffer, to be called at the appropriate time.

1.	It won't be faster, and it probably will use more memory, though.

Just for the sake of putting code together and making it easier to follow (as opposed to one monolith function that makes it harder to understand, especially since its original purpose is slowly being outweighed by all its extra work)

Feed - should be minimal, right?

Memberlist - it sort of depends what we put in the memberlist, and whether we add things like custom profile fields and avatars. (I've been meaning to add an option to CPFs to display in the memberlist, but I keep also meaning to think about doing something with its layout and making it less sterile)

PM - it uses lMD? I'm surprised, I'd actually thought there wasn't a use within PMs to do so, especially given how many other places within the PMs *don't* use it.

I once wrote a 'slash through banned members' mod, which naturally means extending the places where a user's name is used to pull is_activated, plus obviously changing the displayed name. I recall there being 20+ changes I had to make to PersonalMessage to achieve this.

Post I can understand for displaying the form back to users, but I don't remember it in drafts. There must have been a reason, very likely to find usernames, but I don't remember.

Yup, though it's nice having the member's name in the right colour there as it should currently be.

Hmm. The point I was getting at is that I didn't realise there was a %P for lowercase,

and that I assumed %p was the only one out there, so that if it were found and we wanted to use lowercase, we'd have to manually replace - as was originally done by SMF...