[buddypress-trac] [BuddyPress] #4482: Better member type support in bp_group_has_members()

[buddypress-trac]

#4482: Better member type support in bp_group_has_members()
--------------------------+---------------------------
 Reporter:  boonebgorges  |       Owner:  boonebgorges
     Type:  enhancement   |      Status:  assigned
 Priority:  high          |   Milestone:  1.8
Component:  Groups        |     Version:
 Severity:  major         |  Resolution:
 Keywords:  needs-patch   |
--------------------------+---------------------------

Comment (by boonebgorges):

 Thanks, r-a-y. This is similar to the idea floated above about using
 `BP_User_Query`. The thing about using `bp_has_members()` is that it acts
 sorta like a black box from the point of view of the Groups component. So,
 while it's easy enough to pass an 'include' parameter, there are a couple
 of limitations:

 1) It'll make the include param of `bp_has_members()` unavailable for
 other, concurrent uses (like showing a subset of users in a group). We
 could probably do some parsing to work around this, but it's a bit clunky.
 2) `bp_has_members()` has support for *limiting the results by user id*
 but not for other kinds of filtering/sorting that might be relevant for
 group queries (and other queries down the road - like friends). Eg, if we
 want to sort by the date the user joined the group, it won't be possible
 using this method.
 3) I'm not sure that the template global `$members_template` created by
 `bp_has_members()` is structured the same as that created by
 `bp_group_has_members()`, so we may break backward compatibility.

 I think that we should definitely aim to consolidate here, but my gut
 feeling is that we should do it using `BP_User_Query`. Ideally, what I'd
 like is for `BP_User_Query` to be flexible enough that it could be
 extended using actual OOP techniques for specific components. So, from the
 appropriate procedural wrapper, you'd invoke a new
 `BP_Group_Member_Query`, which might look like something like

 {{{
 class BP_User_Query {
     // ...
     public function get_include_ids() {
         return wp_parse_id_list( $this->query_vars['include'] );
     }
 }

 // and then the extending class
 class BP_Group_Member_Query extends BP_User_Query {
     public function get_include_ids() {
         // Passed to 'include'
         $include = wp_parse_id_list( $this->query_vars['include'] );

         // Figure out what user type is currently being requested
         if ( isset( $this->query_vars['group_id'] ) && isset(
 $this->query_vars['group_role'] ) ) {
             $group_members = $this->get_group_members_by_role(
 $this->query_vars['group_id'], $this->query_vars['group_role'] );
         }

         // Put them together
         return array_intersect( $include, $group_members );
     }

     protected function get_group_members_by_role( $group_id, $group_role )
 {
         // Do some SQL to get the users
     }
 }
 }}}

 `BP_User_Query` would then use `get_include_ids()` when building the
 master SQL query.

 This model seems to be very flexible, and one that we could implement
 little by little (by abstracting different clauses of the main query into
 methods as needed). The downside is that it's not terribly WPish - we
 could do something similar using the `bp_pre_user_query` hook, though it's
 far less elegant.

 So, that's sorta the shape of what I'm imagining, having mulled it over
 for a few weeks. It adds a bit more overhead than what r-a-y is
 suggesting, but it keeps things more organized, and it provides an
 excellent template for future enhancements (such as BP_Friend_Query, and
 other relevant kinds of user queries). I'm anxious to see how this meshes
 with some of the work that trishasalas has been doing.

-- 
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/4482#comment:9>
BuddyPress <http://buddypress.org/>
BuddyPress