Skip to:

surprising avatar behavior

  • danbpfr


    bp 1.1 RC (rev 1984)

    wpmu 2.8.4a

    i use a custom avatar on my site.

    Surprisingly, the output is weird since i updated from 1.0.3 to 1.1

    The small image shows now an old picture of me and the big image is a more recent picture i uploaded 4 mounth ago.

    Both picture file are in blogs.dir/1/files/avatars/1/

    More surprisingly is that when i delete my avatar, a message tells me that the avatar was successfully deleted, but he still shows up.

    In the wp-usermeta table, there is no reference to the avatar, so i suppose the link beetween my avatar and my account is deleted. It seems that the picture is never deleted from the blog.dir directory

    Anyway, I found no other reference to my avatars somewhere else in the DB, but the two different avatars are already online !!!

    Is there a hidden cache somewhere that i don’t know about ?

    Despite of this, i tried to use my gravatar account to view something different. No chance, it didn’t work. This gravatar is correctly working here and on 4 other buddypressed sites.

    When i upload ONE image for my avatar, there are FOUR avatar reference who are stored in the DB.

    A couple called v1 and v1_path and a couple called v2 and v2_path. Each couple has a relative path and a absolute path.

    Is this right or is this an older version routine ?

    Can somebody explain to me how avatars are working and where they are stored in the DB ?

Viewing 16 replies - 1 through 16 (of 16 total)

  • jugoretz


    Similar strange problems with avatars (with 1.1 and 2.8.4a). Sometimes uploading a new avatar just keeps the old one, sometimes it takes the new one for the large size and the old one for the small thumbnail. More often it just crashes the browser (firefox or safari).

    Very strange. A full (or simple) explanation of how these avatars work would probably help to troubleshoot.

    Or is there a way to just use gravatars instead?

    Andy Peatling


    So – in 1.1 BuddyPress does not query the database to fetch avatars, it expects them to be in specific folders and with specific names.

    Likely what it happening is the permissions on the folders denied BuddyPress the access it needed to move avatars around and into the format/location needed for 1.1. Most of the problems will be related to group avatars mixing up with user avatars, as they were in the same folder for 1.0.

    The quickest option is to remove the /wp-content/blogs.dir/1/files/avatars/ directory and let BuddyPress rebuild your avatars as people upload again. Anyone who has a Gravatar will revert back to that image, so not all will be lost.

    Other than that, you can use this code below to place group avatars in the correct place, so they don’t conflict with user avatars (this normally runs on upgrade). Make sure the permissions on the avatar folder allow for BuddyPress to move files around.

    function move_group_avatars() {
    /* On upgrade, handle moving of old group avatars */
    $groups = groups_get_all();

    foreach ( $groups as $group ) {
    /* Don't fetch and move gravs, default images or empties */
    if ( empty($group->avatar_thumb) || strpos( $group->avatar_thumb, '' ) || strpos( $group->avatar_thumb, 'identicon' ) || strpos( $group->avatar_thumb, 'none-thumbnail' ) )

    $start = strpos( $group->avatar_thumb, 'blogs.dir' );

    if ( false !== $start ) {
    $avatar_thumb = WP_CONTENT_DIR . '/' . substr( $group->avatar_thumb, $start, strlen( $group->avatar_thumb ) );
    $avatar_full = WP_CONTENT_DIR . '/' . substr( $group->avatar_full, $start, strlen( $group->avatar_full ) );

    if ( !file_exists( $avatar_thumb ) || !file_exists( $avatar_full ) )

    $upload_dir = groups_avatar_upload_dir( $group->id );

    copy( $avatar_thumb, $upload_dir['path'] . '/' . basename($avatar_thumb) );
    copy( $avatar_full, $upload_dir['path'] . '/' . basename($avatar_full) );

    unlink( $avatar_thumb );
    unlink( $avatar_full );
    add_action( 'plugins_loaded', 'move_group_avatars' );

    Put that somewhere so it can run, maybe temporarily paste it at the top of bp-core.php, then remove it when you are done.



    Thanks, Andy. I will try fiddling with this when I have more time. The permissions looked OK, I did think of that–but maybe I’m not looking carefully. The blogs.dir/1/files/avatars/ should be writeable by the webserver, right? (there are over 1000 subdirectories in there–one for each user, I assume?)

    But the really troubling thing was the browser crashes. Those were hard to accept.

    This is really a big upgrade, I can see–change in the way themes work, avatars, forums. My own fault for trying to push it right away on a live install.

    For now I’ve dropped back to 1.0–I have 200 students coming in on Sunday to start playing with the system. Best to play it safe until that’s over with.

    Andy Peatling


    Jugoretz: I would definitely play more on a development server, get things up to speed then push it on the live site. If you’ve made a lot of modifications and customizations then with this version you will unfortunately have a more difficult upgrade path.

    The way things work in 1.1 are much more solid moving forward, but they may cause some people who are heavily invested in 1.0 a bit more work.



    I also have a strange problem. All my users have their avatars showing except for one member who has nothing at all and just the alt attribute displaces. When I check the page source to see what BP is spitting out I see for this one particular user the src attribute of the img tag for the image is null (” “).

    I presume this user tried uploading their own avatar and it failed somehow. I am trying to get the users avatar to defualt to mystery man but I can’t seem to find where to do it.

    Any suggestions

    Hmmmm – what should that code do for me? The missing avatars in groups are still missing… But maybe I am missing the point here. Can someone point me in the right direction?



    Not sure what I’m missing here, but that code does not seem to do the trick.

    So if I delete the avatars will folder, will I lose some of the avatars?



    I managed to retrieve the old avatars from 1.0 by copying previous directory but new members cannot change avatar, same behavior: upload OK but avatar not changed.

    John James Jacoby


    georgef101, do you still have the bp-themes folder located in wp-content? If so, BuddyPress will think you’re using the old theme style and look for the 1.0 avatars. If not, make sure your folder permissions are set (I put mine to 777 to make sure it works, but you may want to do 755 depending) and then run the code above. It should rename all of your avatars accordingly and put them where they belong. Once that’s done, you shouldn’t need to delete or change anything.


    John, can you give us the directory where the avatars are supposed to be? It can help me a lot to understand. Because I not only migrated from 1.0 to 1.1, I also change blog organisation by adding a blog to take care of all Buddypress stuff.

    Before 1.1:

    – only one blog :, with buddypress page on the same base

    After 1.1:

    – the previous blog is still but without any access so buddypress pages, all BP is on (a sub blog using buddypress theme)


    I digged a little and I found this:

    When a new user try to upload an avatar, the file goes in:

    /www/wp-content/blogs.dir/1/avatars (the root blog)

    But the profile page displays avatars from:

    /www/wp-content/blogs.dir/3/files/avatars (the sub-second we use for all buddypress pages)

    I’m wondering if it’s not a buddypress bug when there is an hybrid use of themes.


    Any help? I have dozens of new users every days… none of them can change the avatar :-(

    hmmm . strange – i just found out, that I have the same problem. I cannot change my own avatar… :-( I there a ticket on track? I didn’t find it (it is kind of hard :-))


    @Michel: no idea for the ticket. If you have same issue, it seems to be a reproducible bug on some blogs. Hope some BP coders will read us.

    I think I saw a ticket referring to something similar:


    My technical team resolved the issue using a symbolic link:


    is now a symbolic link to /www/wp-content/blogs.dir/1/avatars/

    It’s not working for the groups, but for users it is OK!

Viewing 16 replies - 1 through 16 (of 16 total)
  • The topic ‘surprising avatar behavior’ is closed to new replies.
Skip to toolbar