[buddypress-trac] [BuddyPress Trac] #8179: Improved default value for site avatar

[buddypress-trac]

#8179: Improved default value for site avatar
--------------------------+-----------------------------
 Reporter:  boonebgorges  |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Blogs         |    Version:
 Severity:  normal        |   Keywords:  2nd-opinion
--------------------------+-----------------------------
 Related: #192, #8150, #6544.

 Since BP 2.7 [11150] the WP site icon (Customizer > Site Identity) is used
 as the site avatar in listings throughout BP (/sites/,
 /members/[member]/sites). This is cool.

 When no site icon is available, the "admin_user_id" avatar is used. This
 is OK in theory, but the logic we use to decide this is pretty bad:
 https://buddypress.trac.wordpress.org/browser/tags/5.0.0/src/bp-
 blogs/classes/class-bp-blogs-blog.php?marks=227,234#L219 We join against
 `wp_bp_user_blogs` to get a `user_id`, which is then assumed to be the
 admin user. The problem is that `wp_bp_user_blogs` contains one entry for
 each user of the site. The default logic of the JOIN means that the record
 with the lowest `id` is selected. Often this is OK. But (a) the site
 creator may no longer be a member of the specific site, in which case the
 lowest `id` will belong to a different (non-admin) user. Or (b) the site
 admin may have changed in some other way. Or (c) the site creator's
 account may have been deleted. Etc. When any of these happen, you get the
 avatar of a random site user.

 A couple possible ways forward:

 a. Fall back on Gravatar instead, and never use a user avatar. (This is a
 big change - this behavior has always been a part of BP.)
 b. Use the site's `admin_email` option to decide on the `admin_user_id`.
 We could probably sync this to `blogmeta`, and then join against that in
 `BP_Blogs_Blog::get()`
 c. Since `admin_email` to blogmeta and use it as the default avatar
 fallback, but leave `admin_user_id` logic as-is.
 d. Something else I haven't thought of.

 Option b seems like the safest, since this specific bug (avatar of the
 wrong user) could manifest itself in other ways if you're relying on
 `admin_user_id` to be correct.

-- 
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/8179>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac