[buddypress-trac] [BuddyPress] #2046: Only admin avatar in comments at blog #1

[buddypress-trac at lists.automattic.com]

#2046: Only admin avatar in comments at blog #1
--------------------+-------------------------------------------------------
 Reporter:  mmeida  |       Owner:     
     Type:  defect  |      Status:  new
 Priority:  major   |   Milestone:  1.3
Component:  Core    |    Keywords:     
--------------------+-------------------------------------------------------
Changes (by lgedeon):

  * component:  => Core


Comment:

 This can happen on any blog not using a BP theme. BP is designed to work
 with other themes so the fact that is does not work qualifies as a defect,
 but I found a solution for one 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: <https://trac.buddypress.org/ticket/2046#comment:4>
BuddyPress <http://buddypress.org/>
BuddyPress