Skip to:
Content

BuddyPress.org

Opened 13 years ago

Closed 11 years ago

Last modified 11 years ago

#3521 closed enhancement (fixed)

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

Reported by: sboisvert's profile sboisvert Owned by: boonebgorges's profile boonebgorges
Milestone: 1.8 Priority: high
Severity: major Version:
Component: Activity Keywords:
Cc: sboisvert, eric.andrew.lewis@…

Description

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)

Attachments (2)

bp_activity_get_filters.patch (1.0 KB) - added by sboisvert 13 years ago.
3521.patch (4.3 KB) - added by ericlewis 11 years ago.
basic implementation; makes use of WP's built-in WP_Meta_Query class.

Download all attachments as: .zip

Change History (17)

#1 @r-a-y
13 years ago

  • Keywords close added

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.

#2 @sboisvert
13 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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.

#3 @sboisvert
13 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.)

#4 follow-up: @boonebgorges
13 years ago

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.

#5 @sboisvert
13 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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.

#6 @boonebgorges
13 years ago

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

#7 @johnjamesjacoby
13 years ago

  • Milestone changed from Awaiting Review to 1.5

Moving closed ticket out of Awaiting Review.

#8 in reply to: ↑ 4 ; follow-up: @ericlewis
11 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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( 'activity_meta_query' => array( array( 'key' => 'key_name', 'value' => 'value', 'compare' => '=' ) ) );

Last edited 11 years ago by ericlewis (previous) (diff)

#9 in reply to: ↑ 8 @boonebgorges
11 years ago

  • Keywords close removed
  • Milestone changed from 1.5 to Future Release

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
11 years ago

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

#10 @ericlewis
11 years ago

  • Cc eric.andrew.lewis@… added

#11 @ericlewis
11 years ago

Think we can do this for 1.7?

#12 @boonebgorges
11 years ago

  • Milestone changed from Future Release to 1.8
  • Priority changed from normal to high
  • Severity changed from minor to major
  • Summary changed from Activity results that incorporate activity_meta and others to meta_query parameter for template loops (bp_has_activities(), etc)

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.

#13 @boonebgorges
11 years ago

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

#14 @boonebgorges
11 years ago

  • Owner set to boonebgorges
  • Resolution set to fixed
  • Status changed from reopened to closed

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

#15 @boonebgorges
11 years ago

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!

Note: See TracTickets for help on using tickets.