BP_XProfile_Query - filtering user query results by xprofile field matches

[boonebgorges]

It's not currently possible, without jumping through hoops, to get a list of users who match a given set of xprofile terms. This limits BP's use as, for instance, a membership directory, since a common use case is to do a query like "Show me all the users who live in Chicago and have more than 3 sisters".

BP_XProfile_Query is inspired by WP_Meta_Query. It enables you to pass an xprofile_query parameter to BP_User_Query, of the following format:

'xprofile_query' => array(
    'relation' => 'AND',
    array(
        'field_id' => 12,
        'value' => 'Chicago',
        'compare' => 'LIKE',
    ),
    array(
        'field_name' => 'Number of Sisters',
        'value' => '3',
        'compare' => '>',
        'type' => 'NUMERIC',
    ),
),

This example shows a couple features:

• multiple 'compare' possibilities (inherited from WP_Meta_Query)
• ability to have multiple clauses, separated by an AND or OR 'relation'
• pass 'field_name' if you don't know 'field_id', and BP_XProfile_Query will look it up for you

The fields that generated a match are also put into the BP_User_Query->results array, so that if you want to display the matched content in the loop, you don't have to query for it (BP_User_Query->results[ user_id ]->xprofile_matched_fields)

BP_XProfile_Query is totally abstracted into the bp-xprofile component, and hooks into BP_User_Query using the 'bp_pre_user_query' and 'bp_user_query_populate_extras' hooks. This means (a) no need for bp_is_active() checks, and (b) I can use the class as a plugin until it's rolled into BP core :)

For the time being, I'm not proposing to expose any of this new functionality in a UI in BP core. I am going to work on my existing plugin bp-better-directories ​http://wordpress.org/extend/plugins/bp-better-directories/ to use this new functionality. We can decide at a later date whether it's possible or feasible to build a UI that is general enough to include in core. In the meantime, I'm sure that this API-level stuff will be of great use to developers. See #4796 for a related discussion.

Feedback welcome.

[boonebgorges]

Whoops

[boonebgorges]

Oops, generated the wrong patch in 5839.patch. See 5839.2.patch.

[boonebgorges]

Gah

[boonebgorges]

Ah, fat fingers. .3.patch is the real one.

[r-a-y]

You know it's possible to delete attachments right? :)

[boonebgorges]

Replying to r-a-y:

You know it's possible to delete attachments right? :)

Bah. I was looking forward to comments on my awesome patch, and all I get is heckling!

[r-a-y]

This is a comment reflecting your awesome patch. Satisfied? :)

Looks good though!

I'm especially a fan of this:

The fields that generated a match are also put into the BP_User_Query->results array, so that if you want to display the matched content in the loop, you don't have to query for it (BP_User_Query->results[ user_id ]->xprofile_matched_fields)

Just got to patch up xprofile_get_field_data() to look for this data when in the member loop because I hate extra queries :)

[boonebgorges]

That doesn't make sense. Forget I said anything!

It does sorta! I thought about ways to roll this request into the original query, but decided that it'd be too much work. It might be possible to check the cache for at least some of the data being queried here, but it won't be straightforward - all of the logic of the xprofile_query (which could be (BETWEEN OR LIKE OR REGEXP or any number of complicated things) would have to be reproduced in the cached query.

All of this being said, it's just a single single-table query, so not too big a deal to have to do it here :)

[boonebgorges]

See ​https://core.trac.wordpress.org/ticket/29642. WP 4.1 is going to introduce nested syntax for WP_Meta_Query, and I think we should adopt it here too. Depending on how things go, WP 4.1 may also include a WP_Recursive_Query abstract class that'll contain the necessary recursive logic; we won't be able to use this in BP for backward compatibility reasons, but it will also be something to look out for. I'm going to hold off on this ticket until the WP syntax is settled for the next release (though I think we'll still be able to make 2.2).

[johnjamesjacoby]

Related to #787.

[boonebgorges]

5839.4.patch​ is a rewrite that borrows heavily from the WP_Meta_Query rewrite that will debut in WP 4.1 (without depending on it). Notably, 4.patch greatly reduces the number of table joins required for many types of queries, and introduces nested syntax for these queries.

My proposal for 2.2 is to include this developer-facing API, and think in future versions about whether and how we might create user-facing features (like sophisticated directory filters) that take advantage of the new functionality.

[boonebgorges]

In 9178:

Introduce BP_XProfile_Query.

Based on WP_Meta_Query, BP_XProfile_Query is a helper class for generating
queries against users' XProfile data. It allows developers to filter user
queries to those users who have profile data matching a wide range of
comparisons, from simple equality ("city=Chicago") to complex combinations of
various comparison operators.

An 'xprofile_query' argument has been introduced to BP_User_Query to
support use of BP_XProfile_Query inside of bp_has_members() loops.

See #5839.

[boonebgorges]

In 9179:

Use bp_esc_like() in BP_XProfile_Query.

$wpdb->esc_like was introduced in WP 4.0.0, and our wrapper provides backward
compatibility for earlier versions of WordPress.

See #5839.

[DJPaul]

Is there more to be done on this ticket before we close it?

[boonebgorges]

I was leaving it open in case further cleanup tasks were discovered, but if you'd rather have it closed now and then reopened for any such tasks, that's OK with me.