BuddyPress Avatars Not Displaying with WordPress 3.0

I don’t work with BuddyPress much if at all, but have been doing a lot more of it lately. Recently, we had an issue where avatars were not displaying on pages using the built-in template tags, like bp_member_avatar() and others.

We thought this was a weird environment issue at first, but then I found this post that showed me it’s a common issue that’s been reported to their development team.

I continued searching for a solution and got some direction from a solution by @foralien on the BuddyPress forums. Her solution did not work for, but I created my own version and had success.

What was happening?

Our BuddyPress installation was trying to get avatars from /blogs.dir/1/files/avatars/{$user_id}/{$filename} – which did not eve exist, this was referencing a files directory for the root blog and it didn’t even exist.

As per @foralien’s solution, I created 2 filters (one for the avatar path, the other for the avatar public URL):

Download the Code

// Custom filters to clean up issues in WP 3.0 with avatar paths.
// Written by @theandystratton
function sizeable_bp_core_avatar_folder_dir( $path ) {
	$items = explode('/', $path);
	$path = ABSPATH . 'wp-content/uploads/avatars/' . end($items);
	return $path;
add_filter('bp_core_avatar_folder_dir', 'sizeable_bp_core_avatar_folder_dir');
function sizeable_bp_core_avatar_folder_url( $url ) {
	$items = explode('/', $url);
	$url = 'http://' . $items[2] . '/wp-content/uploads/avatars/' . end($items);
	return $url;
add_filter('bp_core_avatar_folder_url', 'sizeable_bp_core_avatar_folder_url');

What it’s doing

We’re filtering the path and the url for avatars to ensure it’s using the WP 3.0 location, which is the upload_path for the root site followed by /avatars/{$user_id}. This is not a forever fix. I’d use it as duct tape until they release a BuddyPress update for WP 3.0 fixing the issue.

Hope this helps you guys and saves you some time and frustration.


  1. John Adigue says…

    Hi, thank you for this post. It helps me a lot. Btw, I’ve modified the function sizeable_bp_core_avatar_folder_url() to fixed if wordpress installation is in sub directory.

    function sizeable_bp_core_avatar_folder_url( $url ) {

    $items = explode(‘/’, $url);
    global $blog_id;
    $url = ” . get_blog_option($blog_id,’siteurl’) . ‘/wp-content/uploads/avatars/’ . end($items);
    return $url;


  2. andy says…

    @John thanks, man. Somehow we removed these and things mysteriously started working. I’m still a bit confused. Overall I think BP + WP 3.0.x is a gray area.

  3. aljuk says…

    Hi, did you ever get to the bottom of this behaviour?

    I’m having a similar experience.

  4. andy says…

    No, the code I posted here was a band-aid and then things mysteriously started working. Not the answer you’re looking for I’m sure but the project ended after that ;/

  5. aljuk says…

    Ok, thanks, that’s odd. Anyhow your fix has got me going again, cheers for that. What’s strange is that it affects my production install, but not my local dev install, which is an exact mirror. My server plan recently got shifted to a new box, so all I can think is that there may be some assumption made in BP core re. addressing root that is proving a ‘gotcha’ for some installs. I deactivated plugins, resaved permalinks, went through all my permissions etc. Weird.

  6. aljuk says…

    Doh. It was a permissions issue. Somehow the user avatar directory and its subs had acquired 755 (pilot error, obviously)

    Anyway, the point is, if BP custom avatar directories aren’t set to write-enable, the avatars won’t display. Who would know.

  7. iMiAir says…

    Great Fix.. Thanks !

  8. Haider says…

    Can you repost the txt file please. The link is dead. Cheers.

RSS feed for comments on this post. TrackBack URL

Leave a Comment

September 9, 2010

Filed in Development, Plugins, Wordpress

There are 8 comments »

« Back to the Blog