[buddypress-trac] [BuddyPress] #1681: avatar in comment is wrong (new theme)

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


#1681: avatar in comment is wrong (new theme)
----------------------+-----------------------------------------------------
 Reporter:  arturo84  |        Owner:        
     Type:  defect    |       Status:  closed
 Priority:  major     |    Milestone:  1.2   
Component:  Core      |   Resolution:  fixed 
 Keywords:            |  
----------------------+-----------------------------------------------------
Changes (by lgedeon):

  * component:  => Core


Comment:

 A very similar problem still occurs, but I found a solution 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/1681#comment:3>
BuddyPress <http://buddypress.org/>
BuddyPress


More information about the buddypress-trac mailing list