[buddypress-trac] [BuddyPress Trac] #6645: `BP_Activity_Activity::get()` args should be translated into `BP_Activity_Query`

[buddypress-trac]

#6645: `BP_Activity_Activity::get()` args should be translated into
`BP_Activity_Query`
----------------------------------+----------------------------
 Reporter:  boonebgorges          |      Owner:
     Type:  enhancement           |     Status:  new
 Priority:  normal                |  Milestone:  Future Release
Component:  Component - Activity  |    Version:
 Severity:  normal                |   Keywords:
----------------------------------+----------------------------
 `BP_Activity_Query` is extremely flexible and powerful. But the ability to
 leverage it from a plugin is limited, because of the way that
 `BP_Activity_Activity::get()` parses the arguments it's passed. The
 existing logic looks something like this in pseudo-code:

 {{{
 if ( $scope ) {
     $where[] = WHERE clauses corresponding to 'scope'
 } elseif ( $filter_array ) {
     $where[] = WHERE clauses corresponding to 'filter_query'
 }

 foreach ( array( 'filter', 'spam', 'search_terms', 'show_hidden',
 'include', 'exclude' ) as $arg ) {
     if ( $r[ $arg ] ) {
          $where[] = WHERE clauses corresponding to $arg
     }
 }

 $where = implode( ' AND ', $where );
 }}}

 In other words:
 * 'scope' and 'filter_query' are mutually exclusive
 * all of the various clauses are joined with 'AND'

 This is pretty limiting. It means that there's no single filter point
 where a plugin can interject to add a condition. It also means that the
 conditions are necessarily joined by `AND`, when someone might reasonably
 want to get, say, items that are 'hide_sitewide=0' OR 'user_id=123'.

 I recommend that the logic be reconstructed so that everything is run
 through `BP_Activity_Query` - ideally, a single set of clauses. It'd look
 something like this:

 {{{
 if ( $scope ) {
     $scope_clauses = translate 'scope' into BP_Activity_Query clauses,
 much like `get_scope_query_sql()` already does
 }

 // No longer mutually exclusive with $scope
 if ( $filter_query ) {
     $filter_query_clauses = $filter_query;
 }

 foreach ( $other_relevant_args ) {
      $clause_registry[ $arg ] = list of clauses for $arg
 }

 // Put them all together, assuming `AND`
 $query_args = array_merge(
     array( 'relation' => 'AND' ),
     all the other sets of query clauses
 );

 // Run it through a single filter, either here or after running
 `BP_Activity_Query`
 $query_args = apply_filters( ... );

 // Then get the sql
 $aq = new BP_Activity_Query( $query_args );
 $where = $aq->get_sql();
 }}}

 Now, any plugin - or even BuddyPress itself - has the power to perform any
 modifications on any kind of activity filtering. To take just one example,
 this would allow a privacy plugin to exclude activity matching a set of
 criteria from every stream for a given user.

 @r-a-y - I'm especially interested in your thoughts here, since you
 designed a bunch of this (and especially because you wrote the logic to
 translate 'scope' into a `BP_Activity_Query`).

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