[buddypress-trac] [BuddyPress Trac] #6577: friends_check_friendship_status() problem when using legacy user query

[buddypress-trac]

#6577: friends_check_friendship_status() problem when using legacy user query
---------------------------------+-----------------------
 Reporter:  r-a-y                |       Owner:  r-a-y
     Type:  defect (bug)         |      Status:  reopened
 Priority:  normal               |   Milestone:  2.4
Component:  Component - Friends  |     Version:  2.1
 Severity:  normal               |  Resolution:
 Keywords:  has-patch            |
---------------------------------+-----------------------
Changes (by boonebgorges):

 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 After [10037], I noticed PHP notices being thrown in the Members widgets
 on one of my installs. It turns out that one of the users identified in
 `$user_query->user_ids` had been deleted from the installation. As a
 result, the ID showed up in the `user_ids` array, but not in `results`;
 and so the ID showed up as a false positive in the `array_diff()` added in
 [10037], which means "creating default object from empty value" notices on
 the line `$user_query->results[ $nf ]->friendship_status = 'not_friends'`.

 A quick look suggests that this issue may not be reproducible through
 normal means. Under normal circumstances, deleted users will have their
 last_activity deleted as well, so that they shouldn't show up in the
 `user_ids` array in the first place. On my dev installation, it must be
 the case that the user was deleted manually, perhaps via SQL query.

 Reopening this ticket to get your opinion, r-a-y: should we be doing one
 of the following?
 a. checking `isset( $user_query->results[ $nf ] )` - or, better still,
 using `array_keys( $user_query->results )` instead of
 `$user_query->user_ids`) - when adding the 'not_friends' flag
 b. In `BP_User_Query`, after performing the `WP_User_Query` in
 `do_wp_user_query()`, unset any IDs in `user_ids` that are not found in
 the `WP_User_Query` object?
 c. Do nothing, because the PHP notice in this case is a helpful reminder
 to developers that their data is somehow corrupted?

 Option b seems the most elegant somehow, but it's also the farthest
 reaching (and is perhaps outside the scope of the current ticket - your
 commit only made it visible). I could be sold on any of these three
 options, though.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/6577#comment:3>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac