[buddypress-trac] [BuddyPress] #4938: Logic for friend queries in BP_User_Query

[buddypress-trac]

#4938: Logic for friend queries in BP_User_Query
-------------------------+---------------------------
 Reporter:  dontdream    |       Owner:  boonebgorges
     Type:  enhancement  |      Status:  reopened
 Priority:  normal       |   Milestone:  1.8
Component:  Core         |     Version:  1.7
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |
-------------------------+---------------------------

Comment (by boonebgorges):

 Ok, I've thought about this a bit.

 r-a-y - I think the regressions that you point out are not issues with
 `BP_User_Query`, but with `bp_has_members()`. That is, the user query
 class should be context-agnostic - it should respond only to the
 parameters that are passed into it - which, IMO, is what it's currently
 doing. Context-specific logic should occur in the template function (since
 templates are always loaded in a context). And, in this specific case,
 it's in `bp_has_members()` that the context-sniffing is already happening,
 in the form of the `bp_displayed_user_id()` check.

 So, I'm going to suggest something like 4938.patch. First, it switches the
 tests to use bp_has_members() (they should probably be moved out of the
 core/classes.php file, but whatevs). Then, I've made a change in the way
 that the context-sniffing happens in `bp_has_members()`. Instead of our
 blanket `if ( bp_displayed_user_id() )` check, I've changed it so that the
 `user_id` param only gets set if you're looking at a Friends list (not
 requests) page. This fixes the friend-request issue immediately. It will
 fix the member-loop-on-a-member-page issue for all cases except when that
 loop is appearing on member/friends, but I think best practices should
 probably dictate manually passing a user_id=0 param to `bp_has_members()`
 in those cases anyway. (That's what we do with the Members widget, for
 instance.)

 The only concern here is backpat. Are there plugins and themes that are
 taking advantage of the current behavior, by displaying a list of user
 friends somewhere on that user's page, using `bp_has_members()` but
 *without* passing a user_id? I'm sure *someone* is doing it, but it also
 seems like an edge case.

 If we only risk breaking a small number of things, I think it's probably
 worth it. Using `bp_displayed_user_id()` for this purpose is way too
 broad, if its only purpose is to filter member/friends.

-- 
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/4938#comment:10>
BuddyPress <http://buddypress.org/>
BuddyPress