BP_Groups_Member::get_group_administrator_ids() not cached

[r-a-y]

In the group loop, when the "Leave Group" button is in the process of rendering, groups_get_group_admins() is called.

groups_get_group_admins() therein calls BP_Groups_Member::get_group_administrator_ids(). This DB query is uncached.

If the logged-in user is viewing the group directory and is a member of each group in the loop, this can lead to 20 additional DB queries being run.

Attached patch caches calls to BP_Groups_Member::get_group_administrator_ids() and invalidates the cache whenever a group member is promoted or demoted and when a group is deleted. Let me know if more unit tests are required.

[boonebgorges]

Nice catch. Caching looks good to me.

I know we don't allow it anywhere in the interface (admin status only comes through promotion), but it's possible to create group admins programatically without going through the promotion process. I think it's probably worth busting the cache on changes in group membership for this reason. (Adds very little overhead, since this happens rarely.) What do you think?

[r-a-y]

I think it's probably worth busting the cache on changes in group membership for this reason.

I was thinking about this myself! See 02.patch.

[r-a-y]

Updated to fix notice when using static add_user_to_group() method.

[boonebgorges]

Looks good to me.

[r-a-y]

In 8537:

Groups: Cache calls to BP_Groups_Member::get_group_administrator_ids()

When a logged-in user is viewing the group directory and is a member of
each group in the loop, when rendering the "Leave Group" button, a call
is done to fetch the group admins of each group to determine whether the
user is the sole admin.

Since this query is uncached, this could lead to twenty additional DB
queries being run on the page. Thus, this commit caches this query and
invalidates the cache whenever a group member is promoted / demoted or
saved into the database.

Fixes #5711.