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.
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):
// 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');
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.
RSS feed for comments on this post. TrackBack URL
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;
}
Best,
John
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.
aljuk says…
Hi, did you ever get to the bottom of this behaviour?
I’m having a similar experience.
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 ;/
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.
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.
iMiAir says…
Great Fix.. Thanks !
Haider says…
Can you repost the txt file please. The link is dead. Cheers.