[buddypress-trac] [BuddyPress] #2183: buddypress and gravatar conflict using P2, sandbox and many other themes, WPMU

buddypress-trac at lists.automattic.com buddypress-trac at lists.automattic.com
Mon Mar 29 02:40:47 UTC 2010


#2183: buddypress and gravatar conflict using P2, sandbox and many other themes,
WPMU
----------------------------+-----------------------------------------------
 Reporter:  azizpoonawalla  |       Owner:                                
     Type:  defect          |      Status:  new                           
 Priority:  major           |   Milestone:                                
Component:  Core            |    Keywords:  P2, gravatar, buddypress, WPMU
----------------------------+-----------------------------------------------
Changes (by lgedeon):

 * cc: lgedeon (added)


Comment:

 I found a solution for my version of the problem and learned a few things
 along the way that might help with other BuddyPress avatar problems.

 Full text at: <a href="http://luke.gedeon.name/buddypress-wrong-avatar-
 fix.html">http://luke.gedeon.name/buddypress-wrong-avatar-fix.html</a>

 What I found:

 In the file /wp-content/plugins/buddypress/bp-core/bp-core-avatars.php,
 lines 344 and following contain the following code:

 global $authordata;
 if ( is_object( $user ) )
 $id = $user->user_id;
 else if ( is_numeric( $user ) )
 $id = $user;
 else
 $id = $authordata->ID;


 if ( empty( $id ) )
 return $avatar;

 I think that last “if statement” may be there to catch cases where the
 commenter does not have a BuddyPress account (which is the majority on my
 site at this point). However, if you look closely at the block just above
 the “if ( empty( $id))” you will notice $id is never going to be empty at
 this point.

 That suggests two possible solutions.

 Solution 1:

 I have not tested this, but it makes sense that you could move the last
 “if statement” above the first “if statement.” That way you can check for
 “empty( $id )” before it gets set to”$authordata->ID”

 Solution 2:

 I found it works quite well to add these lines just under the last “if
 statement.”

 if ( is_string( $user ) )
 return $avatar;

 This will catch any case where an email is sent as input, which is what
 all (most) non-buddypress themes send. Cases where numbers or objects are
 sent (the BuddyPress method) will be handled normally.

 I am going to spend a little more time getting familiar with BuddyPress
 and then try to get dev access so I can get this fix into a future release
 of BuddyPress. In the mean-time, we will have to just do it as a hack.

-- 
Ticket URL: <http://trac.buddypress.org/ticket/2183#comment:3>
BuddyPress <http://buddypress.org/>
BuddyPress


More information about the buddypress-trac mailing list