Pagination is removed when all groups are empty

[dansearle]

If all the groups are empty (they have no members) then the pagination in the WP Admin groups list isn't shown. See /wp-admin/admin.php?page=bp-groups

The way the method BP_Groups_Group->get works means the two queries return inconsistent results, e.g. the query to fetch the list of groups doesn't always join to the members table; however the query to count them does.

Compare

$sqlselect? = "SELECT DISTINCT g.id, g.*, gm1.meta_value AS total_member_count, gm2.meta_value AS last_activity";
$sqlfrom? = " FROM {$bp->groups->table_name_groupmeta} gm1, {$bp->groups->table_name_groupmeta} gm2,";

if ( ! empty( $ruser_id? ) ) {

$sqlmembers_from? = " {$bp->groups->table_name_members} m,";

}

with

$total_sqlselect? = "SELECT COUNT(DISTINCT g.id) FROM {$bp->groups->table_name} g, {$bp->groups->table_name_members} gm1, {$bp->groups->table_name_groupmeta} gm2";

if ( ! empty( $ruser_id? ) ) {

$total_sqlselect? .= ", {$bp->groups->table_name_members} m";

}

[Mamaduka]

Added first pass for unit test here.

Got weird behaviour here, if I specify $user_id as creator_id in group factory tests are failing, otherwise tests are passed.

Any advises here?

Thanks

[boonebgorges]

Got weird behaviour here, if I specify $user_id as creator_id in group factory tests are failing, otherwise tests are passed.

Your get_current_user_id() check is returning 0. So BP_UnitTest_Factory_For_Group is creating a user behind the scenes. That means that your group member deletions are doing nothing.

I've updated the patch so that it fails as expected. The proper fix will be to change the group count query so that it doesn't join the group_members table like this, but first I'd like a bit of research done into why this join was put there in the first place. ("Peatling did it" may end up being a sufficient answer.)

[boonebgorges]

(See #5983 r9120 for more details on the factory issue.)

[Mamaduka]

Boone,

Did some digging in git logs and looks like this was introduced by JJJ in r4064, maybe he can provide some feedback.

[Mamaduka]

Patch fixes the issue 5584.diff​.

Removes joins for $bp->groups->table_name_members and $bp->groups->table_name_groupmeta tables from first select. Unlike global groups query those joins aren't needed here, since we are not sorting based on last activity.

[boonebgorges]

The age of r4064, and the fact that it's not linked to any ticket, lead me to guess it was basically a guess at fixing a problem. I'm OK with removing it based on that. Thanks for doing the digging, Mamaduka.

We're not sorting based on last_activity, but removing this join will mean that we start counting groups that have no last_activity at all. I don't *think* that this natually occurs in BP (unlike the parallel situation with members), but it could use a few minutes' research. I'm tempted to leave that join in there, just to be safe.

[Mamaduka]

Boone,

Updated patch and included last_activity checks.

[boonebgorges]

In 9230:

Don't join against the group members table when fetching total group counts.

The join doesn't take place in the 'paged' count, which leads to inconsistent
query results when groups have no members.

This reverts changes made in [4064].

Props Mamaduka.
Fixes #5584.