meta_query parameter for template loops (bp_has_activities(), etc)

[sboisvert]

From what I've gathered from the support forums most methods of showing results that would be either based on an activity_meta or on a taxonomy would be to rewrite the query to pass the wanted ids in the $in for the 'bp_ajax_querystring' filter.
I was wondering if there was appetite to allow filtering of
$select_sql, $from_sql and $where_sql in BP_Activity_Activity::get(); which would allow to manipulate the query in such a way as to allow a much greater degree of flexibility, without having to basically do 2 sets of Queries (By this I refer to the first query that would pass the $in to the 'bp_ajax_querystring' filter for the real query)

(also let me know if I have created the patch correctly)

[r-a-y]

In the forthcoming BP 1.5, there are already filters lower down in the ::get() function:
​http://buddypress.trac.wordpress.org/browser/trunk/bp-activity/bp-activity-classes.php#L152
​http://buddypress.trac.wordpress.org/browser/trunk/bp-activity/bp-activity-classes.php#L157

I believe those filters should allow you to do what you want.

[sboisvert]

Thank you r-a-y, my apologies, you are indeed correct they do exactly what I need. It had not occurred to me that they would be all in one.

[sboisvert]

r-a-y, I've gone thru this and found a slight problem. It may again be because I am not seeing the right way of doing it, and if so I thank you in advance for your insight.

While the one filter for all 3 does do the trick if one is only attempting to modify the query once, It quickly breaks down if you try to add a second component to the query.
Here is my use case:
First rewrite adds a join on activity_meta to filter only the activities that were posted in the language that the user has selected (or no filter)
Second rewrite joins on a term for a taxonomy (if on a tagged activity aggregation page).
Now I can always write this as one function, but I am currently building both these functions as partial rewrites of buddypress-multilingual and activity-stream-hashtag. Keeping them separate would make it easier to release the code and would allow other plugins the possibility to add to the query in a non destructive way. (Without having to go around doing some parsing and string replace of the original sql query.)

[boonebgorges]

I am wary of littering these classes with additional filters. They will all be deprecated when we move to custom post types. There more of them there are, and the more sophisticated the plugins that are built to take advantage of them, the more difficult the transition will be.

[sboisvert]

That is a valid concern and as I mentioned for my use case I can bundle everything into one rewrite, it just makes the code less modular and less shareable, less future proof, but if that future is custom post types then I am fine with this problem being solved later on by a transition to custom post types.

[boonebgorges]

Thanks for your understanding, sboisvert. Don't let this stop you from asking for more filters and hooks elsewhere :)

[johnjamesjacoby]

Moving closed ticket out of Awaiting Review.

[ericlewis]

Replying to boonebgorges:

I am wary of littering these classes with additional filters.

Thoughts on building an activity_meta_query option into the API? I'm imagining something that's a replication of meta_query in WP_Query, but for BP activity.

$activity = bp_activity_get( array( array( 'key' => 'key_name', 'value' => 'value', 'compare' => '=' ) );

[boonebgorges]

Thoughts on building an activity_meta_query option into the API? I'm imagining something that's a replication of meta_query in WP_Query, but for BP activity.

I think it's a great idea. Patches welcome :)

[ericlewis]

basic implementation; makes use of WP's built-in WP_Meta_Query class.

[ericlewis]

Think we can do this for 1.7?

[boonebgorges]

I'm moving this to the 1.8 milestone, and expanding its scope to the Groups component as well, where we should be able to do something very similar. We'll test to see whether it's feasible for Members as well.

[boonebgorges]

In 6948:

Introduces meta_query paramater for bp_has_activities() stack

This will allow plugin and theme authors to filter the contents of the activity
stream based on information stored in the activitymeta table, using the
powerful meta_query syntax familiar from the 'meta_query' WP_Query param.

Also adds unit test for 'meta_query' in BP_Activity_Activity::get(), and
integration test for bp_has_activities(). These tests are primarily designed
to ensure that our param gets passed properly down the stack; we rely on WP
to get the meta_query logic right.

See #3521

Props ericlewis

[boonebgorges]

In 6950:

Introduces a 'meta_query' parameter for the bp_has_groups() stack

This will allow plugin and theme authors to customize their group directories
based on data stored in the groupmeta table, using a powerful syntax familiar
from WP_Query.

Also adds unit tests for BP_Groups_Group::get() for the meta_query parameter,
as well as an integration test for the entire bp_has_groups() chain of
functions.

Fixes #3521

[boonebgorges]

Marking resolved. I think it's unwise to move forward with Members at the moment, because (a) it'll be harder to reconcile with the meta_value/meta_key params of WP_User_Query, and (b) it's likely to create confusion that it's possible to filter based on usermeta but *not* based on xprofile data. This is an area for future enhancement.

Thanks for your initial patch, ericlewis!