[buddypress-trac] [BuddyPress] #4571: Changes in Gravatar APIs result in failed fallback on default avatars

buddypress-trac at lists.automattic.com buddypress-trac at lists.automattic.com
Mon Oct 1 14:49:40 UTC 2012


#4571: Changes in Gravatar APIs result in failed fallback on default avatars
--------------------------+--------------------
 Reporter:  boonebgorges  |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  1.6.2
Component:  Core          |     Version:
 Severity:  major         |  Resolution:
 Keywords:                |
--------------------------+--------------------

Comment (by boonebgorges):

 But that usermeta tag won't differentiate between users who have legit
 Gravatars and those who don't.

 How about something like this:
 - First time we try to load an avatar for a given user, first check for
 local avatar (we already do this). Then check gravatar, and examine the
 headers. Then set a usermeta key 'bp_avatar_type' with value 'local',
 'gravatar', or 'default' (or we could just leave it empty in the latter
 case, whatever).
 - For each subsequent load of that user's avatar, first fetch
 bp_avatar_type and only pursue the appropriate route: gravatar requests go
 to gravatar.com, local and default are served locally.
 - We bust the bp_avatar_type cache for a user when (a) the user uploads a
 local avatar, (b) we get a bad header back from gravatar.com (the user has
 deleted his gravatar)

 This will save a ton of HTTP requests against gravatar.com.

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


More information about the buddypress-trac mailing list