« Changes to banning
Badges and the displaying thereof
Something really strange just occurred to me »

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Badges and the displaying thereof
« Reply #60, on June 3rd, 2012, 07:43 PM »
You could just as easily do all that extra processing when fetching it all, making that determination based on other settings, and it wouldn't be an extra query depending on how it was set up.

lMC does no requests itself, it's part of lMD to get the data, but that's no big deal really.
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

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Badges and the displaying thereof
« Reply #61, on June 4th, 2012, 12:28 AM »
We'd need to do that in LMD then, but it's a tad harder to determine whether it's being called for userboxes or not. Well, could always add a flag for that too...

Hmm there's an impressive amount of calls to LMD with the default param, 'normal', sometimes I'm wondering if we shouldn't be able to specify just a list of fields we want to retrieve and parse... :P
Would be easier for hooks as well, wouldn't it..?

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Badges and the displaying thereof
« Reply #62, on June 4th, 2012, 12:32 AM »
It would be better if the calls to lMD didn't indicate what they wanted per se, but indicated what they were calling for, and let lMD deal with that. Right now we have 'minimal', 'normal' and 'profile', but only the latter is really expressive of what you're actually doing there.

We have talked about it before, actually, to do exactly that - indicate what purpose the data is being called for.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Badges and the displaying thereof
« Reply #63, on June 4th, 2012, 02:11 PM »
So... I was trying to find inspiration, so I looked into sm.org and found a very old mod (multiple badges) that did a similar thing. I was wondering how it could 'optimize' the database request for these.
Well, it doesn't... It's even worse than what I had in mind -- it does a query per badge, lol.

At this point, I have only two solutions:
- either I insert a FIND_IN_SET(additional_groups) in the LMD function when it comes to the 'mg' table, and then I turn the group entry into an array with membergroup settings for each...
- or I simply give up, and use the code I wrote weeks ago and that I always stop myself from committing. i.e. the global setting in the membergroup settings page, determining whether to show the main group badge, the post group badge, or both, or none.

I'm wary of using FIND_IN_SET(), but OTOH it's also likely that we'll rewrite the additional_groups field to only contain 'public' groups, meaning we'll need to join with a new table to get a proper list of all groups one belongs to, so that would be less of an issue in this case.. (Except that I don't know that there's a point in offering users the ability to create a badge for a user group....?!)

'm a bit lost -- as usual... Hard to get back into the game after this hectic week.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Badges and the displaying thereof
« Reply #64, on June 4th, 2012, 04:53 PM »
Well, here's the thing, if you load all the groups as I indicated (using 0 to indicate a group whose badge will not be displayed), you do a single query, then fetch the additional_groups and do the processing PHP-side without extra queries or effort, and then when member-created groups get done, they also get a badge-position of 0 which means to exclude it.

Then you're done in all respects and don't even have to tackle FIND_IN_SET.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Badges and the displaying thereof
« Reply #65, on June 4th, 2012, 05:19 PM »
Hmmm... That's doable I suppose.
Maybe we could even mix the cache for membergroup colors (used in username links) with the one for badge stars...?

Arantor

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

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Badges and the displaying thereof
« Reply #67, on June 4th, 2012, 06:45 PM »
One of my concerns is that user groups *could* use custom colors and badges, but only in boards belonging to the user group owner. perhaps we should also cache a membergroup list per board...?

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Badges and the displaying thereof
« Reply #68, on June 4th, 2012, 06:47 PM »
I wasn't going to get into that. I see little reason for user-created groups to have custom badges, honestly. Setting badges should be up to the admin, and only the admin IMO.

Nao

  • Dadman with a boy
  • Posts: 16,082

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Badges and the displaying thereof
« Reply #70, on June 4th, 2012, 06:58 PM »
Yup. User created groups would tend towards being secondary groups where the colour wouldn't inherit anyway.

Also, note to self: need to migrate the list of who likes a post to a proper popup rather than a tooltip, it doesn't work properly with people who have funny symbols in their names as the font Windows uses for tooltips does not include all fancy characters.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Badges and the displaying thereof
« Reply #71, on June 4th, 2012, 10:48 PM »
There's plenty of work left to do on likes... If anything: (1) add a permission to like own posts, (2) add the mini-menu I painstakingly rewrote to help with deploying on like buttons... (Heck, it still needs quite some work.)

Re: membergroup caching, I just realized that only groups with an actual color are cached -- I don't know if it's best to just cache all of them, making the coloring possibly slower, or just have two group caches: one for groups that have colors, and one for groups that have a badge to be shown.
Hmm... Probably two separate cache files... :-/

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Badges and the displaying thereof
« Reply #72, on June 4th, 2012, 10:52 PM »
Re likes: I already outlined a bit back what configuration items are still outstanding, I just haven't gotten round to implementing them yet :P

Re caching, might as well make one cache with everything else. Post-count groups will have a badge (or badges) but probably no colour, non-post-groups will almost certainly have both a badge and a colour. And if we're ever looking at displaying both a badge for group and the stars for post groups (which would be neat, actually), we will need both anyway.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: Badges and the displaying thereof
« Reply #73, on June 4th, 2012, 11:10 PM »
I don't know, I've thought it over and basically -- the badge stuff is not used in a lot of places. I might as well add a sub function that loads the membergroups where show_when (or whatever name the field will have) is !=0. This will/would save extra bytes being loaded on every page when we're on a page where only the membergroup colors are required.

I've already started implementing it that way, but I don't know, maybe I'm wrong...?

Here's the sample...

Code: [Select]
// Load cached membergroup badges (or rank images) and when to show them.
if (($member_badges = cache_get_data('member-badges', 5000)) === null)
{
$member_badges = array();
$request = wesql::query('
SELECT g.id_group, g.stars, g.show_when
FROM {db_prefix}membergroups AS g ON g.show_when != {int:never}',
array(
'never' => 0,
)
);
while ($row = wesql::fetch_assoc($request))
$member_badges[$row['id_group']] = array($row['show_when'], $row['stars']);
wesql::free_result($request);
cache_put_data('member-badges', $member_badges, 5000);
}

An array_diff can then be pushed to $user_info['groups'] (or the equivalent thing loaded through LMD or LMC or whatever), to build a list of badges that could be shown. Then we can go iteratively over the group list and keep the badge if show_when is set to 'always show', and delete it if set to 'only show when nothing else is shown' and there's at least one badge already being shown in the list. (Primary group being first priority in the list...)
Well, that's how I'm seeing it done at least. But I'm tired and may be wrong on all accounts.

Going to bed, so you can take time to think about this and tell me what you think is best...

Maybe cache_put_data should be a singleton... wecac::put() :P
Too bad that 'cac' sounds odd in French... (Our equivalent to the Dow Jones.)
« Changes to banning
Something really strange just occurred to me »