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

[buddypress-trac at lists.automattic.com]

#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):

 Something like:

 {{{
 function bp_core_fetch_avatar( $args ) {
     // parse args

     $user_avatar_type = get_user_meta( $item_id, 'bp_avatar_type', true );

     // Try 'gravatar' first in case it fails
     if ( 'gravatar' == $user_avatar_type ) {
         $avatar = do some stuff to get the gravatar

         if ( we get a bad response from gravatar ) {
             delete_user_meta( $item_id, 'bp_avatar_type' );
             $user_avatar_type = 'default';
         }
     }

     if ( 'local' == $user_avatar_type ) ....

     if ( 'default' == $user_avatar_type ) {
         $avatar = the default avatar;
     }

     return $avatar;
 }
 }}}

 What this *doesn't* cover is the case where someone using the default
 avatar uploads a gravatar. If we're not checking on every page load, we
 won't detect it right away. We could, perhaps, do a daily check for
 'default' users to see if we still get bad results from gravatar, and
 could also add a button to the Change Avatar screen that says "I've got a
 Gravatar", which would bust the cache manually.

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