MyBB Community Forums

Full Version: Admincp Advanced Stats & Usergroup Cache Improvement
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
1. I'd like to see advanced stats in admin control panel.


2. Would be a benefit imho if the usergroups table had a column for "members" for the quantity of members in the group.

That would be helpful in reducing the query time for big boards with lots of members and lots of groups. A limit could be added to queries for results. Also in admincp when viewing the index.php?module=user-groups the query to grab all members in all groups is not optimal.

Food for thought. Thanks for consideration.
Advanced stats?

If we added a 'hard coded' static count, do we include those who have it set as an additional group? As a display group even?
I think it should include anybody who is in any way a member of that group. That would make the most sense.
The &debug=1 that is on front end for admins. Sorry, wrong description.

Quote:If we added a 'hard coded' static count, do we include those who have it set as an additional group?

The code already does grab the amount of users with it as an additional group.

Example is on the usercp.php?action=usergroups

You'll see this query exists:

SELECT g.title, g.gid, g.type, COUNT(DISTINCT u.uid) AS users, COUNT(DISTINCT j.rid) AS joinrequests, l.canmanagerequests, l.canmanagemembers FROM mybb_groupleaders l LEFT JOIN mybb_usergroups g ON(g.gid=l.gid) LEFT JOIN mybb_users u ON(((CONCAT(',', u.additionalgroups, ',') LIKE CONCAT('%,', g.gid, ',%')) OR u.usergroup = g.gid)) LEFT JOIN mybb_joinrequests j ON(j.gid=g.gid AND j.uid != 0) WHERE l.uid='1' GROUP BY l.gid

My query time on that is 1.6 seconds. That query would be eliminated by simply having that data in the usergroup cache. The amount of users in the group whether it's an additional, displayed, or primary does not matter. That query doesn't count for that anyways.

Adjustments to +1/-1 the cache when adding and removing people from group should be easy enough to execute.

Probably a long shot to get this optimization but I did want to request the debug for admincp so through this in as well.
It would have a lot of use also.
In the past I've added the advanced debug to the ACP. The only thing that doesn't work is the templates statistics because, of course, the ACP doesn't use a templating system. Toungue

+1 for that.
(2012-05-17, 01:22 AM)Nathan Malcolm Wrote: [ -> ]In the past I've added the advanced debug to the ACP.

Nice of you to volunteer Nathan. Shy

I'm not entirely convinced that the cache is to be used for this; in your example, it would be easy to +/-1 whenever we add/remove a post in a forum. It is dynamic data and should be queried as such.

I'm wondering if we can split it up into sectional queries. I'll take a look at it.
FYI I have about 30 groups and about 250k members many of which are in multiple groups.

To me though part of the problem is that if I want to do any query to see who is in a group I have to run a similar query. Just doesn't seem very optimal on a good sized table to run that query.

I see the function leave_usergroup() and join_usergroup() which imho means it would be easy to add this cache if it's consistently used everywhere.

I certainly would like to see more efficiency with groups. They are a growing aspect I believe on forums and yet MyBB imho hasn't done much for them. Example is leaders can't mass PM the group members, there are no logs for the adding/removing of members. You can't place a member into a rejected place and ignore them. They can apply again immediately and bug you over it.

Tip: Ditch the calendar and focus on the groups. Does ANYONE use it?

Oh and Tomm. A bug exists when removing members from moderation of a forum. They are not placed properly into their old group under certain circumstances. I been meaning to investigate and report it but haven't bothered. It's existed for a while now.