I'm seeing a strange thing where user-uploaded Avatars disappear IF something else changes with the profile. I know this is not the issue discussed in
http://drupal.org/node/186379
because I can upload and see the new avatar just fine. Here are two typical scenarios:

Scenario A)
1. Edit user's account page
2. Make some changes to account settings.
3. Upload a new Avatar
4. Save the account page
5. Everything works fine, and the new avatar shows up for ever where it's supposed to.

Scenario B)
1. Edit that same user's account page
2. Self-uploaded Avatar show up fine at the profile page and during editing process.
3. Edit any other option in the account page.
4. Save the account page.
5. The Avatar disappears completely, right after saving. It pretends there is no avatar selected, and it does not show up in the profile page or anywhere else.
6. Scenario B does not occur with gallary based avatars, the ones chosen through the settings page. Only occurs when user (or admin) uploads a new avatar, and only if the account page changes after ward.

IMPORTANT: the file is actually there in the correct spot. It's just that the module doesn't recognize it when editing and pretends there is no existing uploaded avatar.

Please help! My existing avatars are disappearing at a fast rate as people are mistakenly replacing them.

Files: 
CommentFileSizeAuthor
#5 avatar_selection_239918.patch886 bytesstella

Comments

Priority:Critical» Normal

Some further investigation:

I think this may have something to do with the "random Avatar" selection option. When I turn this off, I don't see the issue anymore. But I have only tried it with one account.

Unfortunately the problem is still there. I just looked at about 10 accounts. The problem persists exactly as I described in the bug, the "random" option did not change anything.

I have found a temporary work around. This works for me, but it still needs to be rolled in for other people.
I think the problem is this: I have one directory "files/avatar_selection" which stores my select-able avatars. But I have another directory "files/user_pictures" which stores the user-uploaded avatars. When the user pics a new picture, it gets loaded fine and uploaded into the "user_pictures" directory. This directory is what is correctly inserted into the "picture" field of the user's entry in "users" table in Drupal.

But when any user changes their profile but DOES NOT make a change to their avatar selection, a "default" value is still loaded into the users table. This default assumes the existing avatar (in the code stored in "$current_avatar") is in the "files/avatar_selection" directory which is wrong. It is only right by accident if the two directories are the same. I suspect this is why more people haven't seen this.

If you look at the code, it only pics up the "basename" from the existing avatar and prepends the (wrong) directory name to it.

It seems to me, there is no need to overwrite the picture field in "users" table if there has been no change. Why keep overwriting it with the "default" value every time? My solution was to remove the default assertion which means commenting out line 164 of avatar_selection.module. This line says '#default_value' => $current_avatar,

<?php
   
// Show selection options.
   
$selects = _avatar_selection_image_list($user);
    if (
count($selects['avatars'])) {
     
$user_form = drupal_retrieve_form($form_id);
     
$current_avatar = basename($user_form['_account']['#value']->picture);
     
$form['picture']['select_avatar'] = array(
       
'#type' => 'radios',
       
'#title' => $disable_upload ? t('Select an avatar') : t('Or simply select an icon'),
       
'#options' => $selects['avatars'],
//        '#default_value' => $current_avatar,
       
'#required' => $force_choose ? TRUE : FALSE,
       
'#attributes' => array('class' => 'user_avatar_select'),
      );
    }
?>

Note that I only added the php tags for highlighting purposes.

Priority:Normal» Critical

I can confirm this bug, I've just looked into it before finding this posted issue. I'm using the 6.x-1.2 version and indeed when someone alters their profile, their user picture path is altered to 'avatar_selection' eg. sites/default/files/avatar_selection/picture-1.gif instead of the path for user pictures I'm actually using which would be sites/default/files/pictures/picture-1.gif - I'm changing this to critical as I've users moaning that their user pics are vanishing and anything which causes users to moan is critical in my opinion...

I don't think I agree with your 'fix' though, it's nice to have the current avatar pre-selected on the form if indeed the user *is* using an avatar and not one of their own pictures. How about something like this instead;

        '#default_value' => array_key_exists($current_avatar, $selects['avatars']) ? $current_avatar : '',

It's not tested and I guess having something in validation would be preferrable as well? Just a thought more than anything...

Pobster

Status:Active» Fixed
StatusFileSize
new886 bytes

Sorry for the lateness in replying, I've been away for the last month. I've applied and tested pobster suggested patch and it seems to fix the issue alright. I've checked in the fix, so it will be available in the next dev release (available later today) and the next official release. I've also created a proper patch for the fix and attached it here.

Cheers,
Stella

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

Released in 5.x-2.5 and 6.x-1.3.

Cheers,
Stella

Version:5.x-2.4» 5.x-2.5

I have the latest version 5.x-2.5 but the problem is not fixed, again when I edit user account users avatar goes to default one, anybody else having this problem?

Status:Closed (fixed)» Active

No it works for me. Ensure that you're using the latest version of the code - perhaps an upgrade wasn't applied successfully? It's probably also a good idea to run update.php to clear the cache.

Cheers,
Stella

Status:Active» Postponed (maintainer needs more info)

Try one of the new releases: Avatar Selection 5.x-2.6 and 6.x-1.4. Note, the 5.x-2.6 version is dependant on jQuery Update.

Cheers,
Stella

Status:Postponed (maintainer needs more info)» Closed (fixed)

Please open a separate issue if this is still a problem with the latest release.

Cheers,
Stella