[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