[buddypress-trac] [BuddyPress Trac] #5705: bp_group_is_user_banned() doesn't reference the group loop's "is_banned" value properly

[buddypress-trac]

#5705: bp_group_is_user_banned()  doesn't reference the group loop's "is_banned"
value properly
-------------------------+-----------------------
 Reporter:  r-a-y        |      Owner:
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  2.1
Component:  Groups       |    Version:  1.2
 Severity:  normal       |   Keywords:  has-patch
-------------------------+-----------------------
 More optimization tweaks!

 If you're logged in with regular user rights (not a BP moderator or admin)
 and you're on the group directory, a check is done to see if you are
 banned from each group in the loop using `bp_group_is_user_banned()`
 function when rendering the group join button:
 https://buddypress.trac.wordpress.org/browser/tags/2.0/bp-groups/bp-
 groups-template.php#L1773

 This function does not check the already-queried data from
 `BP_Groups_Group::get_group_extras()` properly.  Some attempts were made
 in the past to address this, but did not take effect.

 This could lead to 20 additional DB queries on the group directory page if
 you are a regular user.

 Attached patch removes these queries.

 Some gotchas:
 * `groups_is_user_banned()` returns a string of the integer when a result
 is matched and null when no match is found.  I found this out when writing
 unit tests.  However, it is possible for `bp_group_is_user_banned()` to
 return a boolean.
 * My question is do we want to force `bp_group_is_user_banned()` to return
 a boolean or a string of the integer at all times?  What about those that
 do strict conditional type checking?

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5705>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac