[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                |  Resolution:
 Keywords:  has-patch             |
----------------------------------+-----------------------------
Changes (by r-a-y):

 * keywords:   => has-patch


Comment:

 Thanks for opening this ticket, boonebgorges.

 I think for 2.4.0 we can, at the very least, allow `'filter_query'` to
 become independent and not tied to `'scope'` being available.  This was an
 oversight on my part when I originally introduced this into the
 `BP_Activity_Activity:get()` method.

 __tl;dir:__ Making the `'filter_query'` parameter independent should allow
 you to do most of the complex filtering without needing to convert our
 older WHERE conditions over to `BP_Activity_Query` for the most part.

 ----

 __Long reply:__

 As for translating our older activity `WHERE` conditions to funnel through
 `BP_Activity_Query`, this sounded like a decent idea.  I was thinking
 about doing this originally in v2.2.0, but thought the change might be too
 drastic and kind of hard due to the `'bp_activity_where_conditions'`
 filter.

 The `'bp_activity_where_conditions'` filter is an array of where
 conditions that later generates the SQL statement by joining the array
 with the `'AND'` relation.

 By running everything through `BP_Activity_Query` to generate the SQL
 statement, this will potentially break how existing plugins are using that
 filter.

 The other issue about running everything through `BP_Activity_Query` is
 how a plugin dev will filter complex activity queries.

 For example, here's a small example without translating the existing WHERE
 conditions over:

 {{{
 $query_args = array(
         'relation' => 'AND',

         // Get blog activity items or groupblog posts
         array(
                 'relation' => 'OR',

                 // general blog activity items
                 array(
                         'relation' => 'AND',
                         array(
                                 'column' => 'component',
                                 'value'  => buddypress()->blogs->id
                         ),
                         array(
                                 'column'  => 'item_id',
                                 'compare' => 'IN',
                                 'value'   => (array) $blog_ids
                         ),
                 ),

                 // groupblog posts
                 array(
                         'relation' => 'AND',
                         array(
                                 'column' => 'component',
                                 'value'  => buddypress()->groups->id
                         ),
                         array(
                                 'column'  => 'item_id',
                                 'compare' => 'IN',
                                 'value'   => (array) $group_ids
                         ),
                         array(
                                 'column'  => 'type',
                                 'value'   => 'new_groupblog_post'
                         ),
                 ),
         ),

         // Make sure items are public
         array(
                 'column' => 'hide_sitewide',
                 'value'  => 0
         )
 );
 }}}

 In order to filter the query args, a dev would have to loop (or
 recursively loop) through each item in the array to analyze what is being
 queried and to remove or add something.  (Note: This is currently what a
 dev would need to do to filter activity scope arguments.)

 Now add on the converted WHERE condition query args and that means more
 args and logic to loop through.

 This kind of shows off the inelegance of advanced activity filtering
 through a plugin.

 Before it even gets to this stage, I think arguments should be filtered
 through `'bp_after_has_activities_parse_args'` to remove the complexity of
 the query args.

 ----

 I might be overlooking what you are proposing so if I am misunderstanding
 something, please let me know!

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