[buddypress-trac] [BuddyPress] #4237: Adding avatar file names to db

[buddypress-trac at lists.automattic.com]

#4237: Adding avatar file names to db
-------------------------+-----------------------------
 Reporter:  modemlooper  |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Future Release
Component:  Core         |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  2nd-opinion  |
-------------------------+-----------------------------
Changes (by boonebgorges):

 * keywords:  reporter-feedback => 2nd-opinion
 * milestone:  Awaiting Review => Future Release


Comment:

 In the short term, r-a-y is right that some sort of intelligent caching in
 your app is probably the best solution. In fact, good client-side caching
 is going to go a lot further in terms of speeding up your app than single
 enhancement that BP could handle server-side.

 However, there are a couple of reasons, aside from modemlooper's immediate
 concern (which is totally valid btw), for rethinking our current avatar
 scheme:

 - On the default setup, it requires a zillion requests to Gravatar on
 every page load. This causes problems with strict browser settings for
 cross-domain requests, with strict SSL enforcement, with latency, with
 specifying a reliable fallback for users who have not uploaded local
 avatars, etc. In recent versions of BP it's possible to disable Gravatar
 at a global level, but most admins will not do so.
 - The current setup is designed to perform, but it involves crawling the
 avatar directory structure many times during each page load. I haven't
 done benchmarking, but I'd be willing to bet that it's not as superior to
 a (properly cacheable) db-based method as it may seem at first blush.
 - Not storing avatar data in the db means that it's impossible to handle
 avatar data programatically in a variety of interesting ways. For
 instance, you can't tell with a single query what percentage of your users
 have local vs Gravatar avatars. I'm sure there's lots of interesting
 metadata about avatars that could be used to interesting effect by devs if
 it were only available.

 I propose that, in the medium term, we move toward storing avatar
 information in usermeta. In the past, we have avoided this, because of the
 problems of joining against huge, unindexed tables. But the refactor
 discussed in #4060 will make it much more feasible. In particular,
 converting member queries to use WP_User_Query will mean that we can
 leverage usermeta-slurping and caching that, in theory, will add no
 overhead at all.

 There will be a lot of work involved in building avatar logic that does
 the following:
 a) determines the proper order of precedence when searching for avatars
 (local > gravatar > local default)
 b) decides when to store/refresh avatar metadata (when a new avatar is
 uploaded, when an avatar is deleted, when an avatar has been detected at
 Gravatar)
 c) handles group avatars in a similarly performant manner

 But I think that most of this work can and should wait until #4060 is
 fixed (fwiw, it's my first priority in the 1.7 cycle). In the meantime,
 thoughts welcome.

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