That looks familiar... :whistle:
The former is one place where I can see the logic, though surely all that's needed in that case is to turn over authentication over to the separate backend and if authenticated through that method, silently turn on 'disable admin security' (but only for the life of that page)?
Well, if you and Dragooon are into it, then you should do it... I don't have the perfect answer to everything
Or, as I said: select m.id_member, g.online_color from members as m, membergroups as g where m.id_group = g.id_group
Something like that... (?)
Then get the entire list of people, push it into the cache for a few minutes, and use that cache internally to associate people with a color. It might represent a large cache file but if we ensure the option can be disabled, it's okay I guess... (?)
Why? I can't think of an example where adding a class to an anchor would be detrimental to XML functionality...?
Hmm yeah, I suppose... Although it's unlikely to happen.
But we could look through the entire anchor tag and reject it if it has bbc_ in it or something...
Definitely cleaner. But easier to understand? I don't know, I've never been much into 'nested' output buffers, they never made much of a sense to me, I'd rather have it all in the same place...
Well, we could simply turn these into sub-functions and call them all from ob_sessrewrite...
Or 'custom', in my mind.
Definitely a 'custom' candidate then...
It only uses lMD when you're setting PM options in your profile...
I'll let you check the files independently... Yeah IIRC it's to find usernames for recipients that didn't go through the auto-suggest.
I think that's the only place you get it apart from the info center... A real bummer.
It's technically valid only in Linux. It doesn't work in Windows and Mac OS.
You know, you COULD revert this and no one would blame you for that...
I suspect that means something you offered before, sorry I can't remember.
I just looked at the huge query, remembered the hassle it was to plug some of AeMe's code into it (one of the biggest incompatibility generators out there), and wanted it gone, like, now.
Also, btw, I'm not sure wesqlQuery allows passing extra parameters not related to the query itself...?
Like, new wesqlQuery('hook_name', (query stuff), array($set, &$users, &$is_name))...?
yep, that's a perfect solution regarding admin security but there would still be an issue with the profile account data (can't be updated because I don't know my password). Maybe I can set that field as a hidden form field with a pre-filled password or something similar.. I currently have no clue to work around that issue with a proper solution.. Any ideas?
I suspect that means something you offered before, sorry I can't remember..
Also, btw, I'm not sure wesqlQuery allows passing extra parameters not related to the query itself...?
Like, new wesqlQuery('hook_name', (query stuff), array($set, &$users, &$is_name))...?
Also, why would you want to pass in parameters not related to the query itself, exactly?
 | The way it's meant to be |
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.
That would work and would probably be faster than using true buffers to pass back and forth.Quote Well, we could simply turn these into sub-functions and call them all from ob_sessrewrite...
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?Quote Or 'custom', in my mind.
Memberlist is definitely a custom candidate. We need to decide what columns are actually needed.
Yup, it either should be throughout or not at all.Quote I think that's the only place you get it apart from the info center... A real bummer.
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.Quote You know, you COULD revert this and no one would blame you for that...
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.
Then should I revert my changes...? Just to be sure. What about passing params? (I suspect you discuss it below...)
Can you elaborate on this...?
I've rewritten my code to store members+groups followed with a list of colors per group, to avoid repetition and thus generate a smaller cache file for bigger arrays. But I'm not sure what you're suggesting...?
Sorry, I don't mean that I don't understand them, I just mean that I don't get the point. To me, output buffers are nice if you're trying to 'catch' data output by something else, etc, but if you know the exact execution order, it's best to just put everything into the same OB...
For instance, link replacements have to happen after <URL> is transformed, but before pretty URLs are applied. I was thinking of using my replacement code right inside the purl filter file, to be able to both transform profile URLs and add a color at the same time, but... Err, one millisecond...? Who cares. Might as well make the code clearer and put everything in the same place.
Sure.......................... Who's up for it?
What do you mean?
(With the technicality of big user names (e.g. userbox authors) being potentially a problem. I'm thinking of fixing it by changing the default colors to pastel ones, like the group colors on wedge.org... #d2653a is definitely nicer than red for admins!)
Looking at the SMF2 code, it only checks for %p (lowercase), which generates uppercase AM and PM, and manually transforms them to time_am and time_pm, but they're not dealing with %P... Just so you know-- if you add a %P on a server that doesn't support it, it'll return an empty string... Not an empty am/pm; but an entirely empty string. (At least under Windows.) I don't think 'wrong' values are being filtered out if the user enters a custom time format...
(Heck, if it wasn't for the custom time format thing, I wouldn't have had to do the whole preg_match stuff to find the year.)
<evil grin> "I don't know, but it's going to be a lot of fun finding out!"
| 1. | But I'd code it from scratch anyway, not only to avoid claims of copying but simply because we'd have to do it differently. |
I figured we might as well cache the membergroups and their colours generally (including post count groups),
and in places we already do a join to the members table to get the member's name, add the id_group and id_post_group parameters from there into the query.
The idea is to save either the extra join or the extra query, since if we're already doing the join to members, there's no need to do any further joining or querying if we already have the list of membergroups and their colours available to us.
The argument I'm suggesting - but not that heavily - is encapsulating functionality. Right now the post-replace phase is pretty complex, and is made up of a series of stages. Wouldn't it be better to make each stage a separate function, so that if ever you need to alter behaviour, firstly it's localised into a single function, and secondly if you need to rearrange them, you're rearranging a few lines rather than bulk copy/paste?
I kind of like the columns on here/Noisen actually, it's an improvement over the default.
I also hear that what Antechinus made for the 'dynamic memberlist' isn't too bad either, might be worth looking at the visual side to see if it isn't hideous
Atom is XML. If you add an attribute to that XML, it's still valid XML - but it stops being a valid Atom file. Remember, XML formats aren't just randomly extensible, they have schemas to direct what elements there are and what the valid list of attributes is.
Actually, Dragooon answered that one, and wesqlQuery provides for it.
Oh, I forgot about post count groups... I never enable colors for these.
I also managed to catch the place where postgroups are updated so I can clear the cache, but I wouldn't mind some help spotting other areas where regular groups are updated.
Also, looked into rev 1118, just a note: there are plenty of multiple spaces (not tabs) in the file, most notably several distinct lines often find themselves on the same line separated by many spaces... Odd!
And the ManagePlugins template -- you committed an empty function, is this as intended?
Oh, and before I forget... There are dozens (hundreds?) of " in the language files. Shouldn't we remove them...? I don't think they serve a point these days?
$txt['string'] = 'line 1' . "\n\n" . 'line 2';I think it's better (for now) to harmonize the queries, so I started removing online_color when not required by something else...
Well, I'm a bit lost in the amount of changes I made today so I'll just commit what I have now and you can look into it.
I haven't been moving a lot of code honestly, only recently to straighten it up but I don't see myself adding to that function on a daily basis anyway..... :^^;:
I just took out what I didn't care about, and added the stuff I wanted to have (avatars and last login)...
Isn't there a 'super memberlist' mod around? The one where members are listed in boxes -avatar, then some info below... I'm not a big fan of the way it's shown, but it's probably a way to do it that's logical to most people.
Hmm... I see. Well, now that the code is committed (I wanted to post this before, but I had a browser crash -- thank you for drafts! -- and committed while waiting for my tab list to reload), you can look into it and test the XML maybe...?
And please generally tell me what you think about the overall building of the feature ;)
Then all is good... Just promise me that wesqlQuery will be in Wedge before we release an alpha :P
We might not but I know sites that do.
Profile area is the main one, but it's not the only one. Group management (Groups.php) is the other main one for assigned groups. Theory says updateMemberData() should be called.
Class-SFTP's formatting is... special. I thought I'd fixed the worst offenders.
Be very careful with those. There are cases where mismatching goes on - when I created the Birthdays plugin out of the email templates, I made use of a little known quirk of SMF's language editor.
Harmonisation is good :)
Well, I'll take a look but we might as well not run that particular process if we're outputting XML, I can't see any case in XML (valid or otherwise) where we'd want the colour to be added.
I'm looking at Settings.template.php and only one question comes to mind... Why this? I can understand some themes might wanna add options, but... This makes it very hard to actually find them (they're neither accessible from Profile > Look & Layout, not from the regular admin area... You have to go to Admin > Current Theme, which I don't find very intuitive.)
Even things like show_group_key... Why would we need to offer to ability to disable it...? To save space?! Why is it a theme option only? It should be in Admin > Membergroups > Settings...
I've been changing show_group_key btw. Now it will also show postgroups, if they have a custom color. Is this okay with everyone? I couldn't think of any strong reason not to do that.
Which is why I added a default color for the highest post group in Wedge...
Uncaching on updateMemberData() means doing it on many, many user actions... Might as well not cache anything
It only matters if you're not going to update the file in the future.
Well, we still have a lot of " in the language files, which we used naturally this year AFAIK. So it's pretty much a mixup...
Oh, there's a bug in the current version btw. It's related to createList() and the creation of the menu... Anyway... Just go to the info center, click one of the membergroups in the group key, and see the errors in the menu. Worked on it for 15 minutes and didn't find anything strange (except for a wetem::load() that can safely go in Groups.php...)
In that case, hmmm... How do we do that? Just a simple if (isset($_GET['xml'])) will do...?
! Provide a hook for altering the list of posts to be retrieved, as suggested by live627. (ManagePlugins.php, Display.php)