Skip to:
Content

BuddyPress.org

Opened 12 years ago

Closed 12 years ago

#2183 closed defect (bug) (fixed)

buddypress and gravatar conflict using P2, sandbox and many other themes, WPMU

Reported by: azizpoonawalla's profile azizpoonawalla Owned by:
Milestone: Priority: major
Severity: Version:
Component: Core Keywords: P2, gravatar, buddypress, WPMU
Cc: lgedeon

Description

Buddypress v1.2.1 and 1.2.2
Theme P2 v1.0.4
WPMU v2.9.2

when i activate the Buddypress plugin, gravatars for replies to a post inherit the same gravatar as the original post author.

If the comment is made by a registered user, the gravatar loads correctly. Comments left by unregistered users however do not show the correct gravatar, even though email address is correctly entered.

originally posted to wordpress trac http://core.trac.wordpress.org/ticket/12592, advised to post to BP trac instead

Change History (4)

#1 @lgedeon
12 years ago

  • Summary changed from buddypress and gravatar conflict using P2, WPMU to buddypress and gravatar conflict using P2, sandbox and many other themes, WPMU

Same issue in the sandbox theme.

I tested and sandbox is sending the correct email address. Another site suggested that buddypress requires username not email but email is how gravatar works.

Oh, why have a different system? Gravatars are not going to become global if even the friends of wordpress do not use them.

#2 @azizpoonawalla
12 years ago

possibly related tickets:

http://trac.buddypress.org/ticket/2219

similar issue was reported fixed a few months ago:

http://trac.buddypress.org/ticket/1681

#3 @lgedeon
12 years ago

  • Cc lgedeon added

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.

#4 @johnjamesjacoby
12 years ago

  • Resolution set to fixed
  • Status changed from new to closed

(In [3035]) Fixes #2288, #2183, and #2426.

Note: See TracTickets for help on using tickets.