In `BP_User_Query`, allow xprofile fields to be toggled when searching

[boonebgorges]

When passing 'search_terms' to BP_User_Query, the following fields are matched: wp_users.user_login, wp_users.user_nicename, and all xprofile_data fields. This is mainly for legacy reasons: when BP_User_Query was first built, I tried to match the behavior of BP_Core_User, which was to match all xprofile fields.

But this behavior is pretty odd in many cases. Often - perhaps usually? - searching for a user ought to mean searching by that user's name.

We might consider changing the default behavior of 'search_terms' in the medium term. In the short term, I'd like to introduce something to BP_User_Query that allows the caller to dictate which field(s) to match - either a param like 'search_fields', or at the very least, a filter.

See #5155, #4821, #6211 for some related issues.

[johnjamesjacoby]

This makes sense to me. A switch that defaults to existing behavior, to maybe later be switched off by default to save the extra JOIN or second query when it's less necessary than "always."

[boonebgorges]

I spent a little more time thinking about this, and, as is often the case, it's not as easy as it sounds.

What would this look like at the API level? In the case of wp_users fields, people would probably want to be able to pass an array of fields to match: array( 'user_login', 'user_nicename' ). What does this look like for xprofile? Do we accept field names, or field IDs, or both? Since xprofile fields can be created at will by the admin, perhaps a more likely use for xprofile is to pass a *blacklist* rather than a whitelist of fields: match all fields *except* for x, y, z. Is this a separate param? Is there any purpose to having an 'exclude' param for wp_users, when the group of available fields is so small?

Gotta think more about this :(

[DJPaul]

We're closing this ticket because it has not received any contribution or comments for at least two years. We have decided that it is better to close tickets that are good ideas, which have not gotten (or are unlikely to get) contributions, rather than keep things open indefinitely. This will help us share a more realistic roadmap for BuddyPress with you.

Everyone very much appreciates the time and effort that you spent sharing your idea with us. On behalf of the entire BuddyPress team, thank you.

If you feel strongly that this enhancement should still be added to BuddyPress, and you are able to contribute effort towards it, we encourage you to re-open the ticket, or start a discussion about it in our Slack channel. Please consider that time has proven that good ideas without contributions do not get built.

For more information, see ​https://bpdevel.wordpress.com/2018/01/21/our-awaiting-contributions-milestone-contains/
or find us on Slack, in the #buddypress channel: ​https://make.wordpress.org/chat/