New to the community? Start here

Avatars plugin just stopped working!

Our Avatars plugin just stopped working! Every user avatar is displaying the default avatar across the network...all of a sudden.

i have confirmed proper permissions on the /avatars directory and confirmed it exists with all its sub-folders.

However, the functionality is still there on the profile page to upload avatars, and that works, replacing the default...

  • Luís
    • Support

    Hi jcnjr ,

    Hope you're doing well today!

    I flagged the SLS team (our code experts :slight_smile: ) to investigate further and get their valuable feedback.

    Since this team deals with more advanced threads it may take them longer to reply.

    Also, I will mention the other topic about Pro Sites to check if could have any relationship.

    Cheers, Luís

  • jcnjr
    • HummingBird

    Thank you for the prompt support Luís !

    Since our chat I have confirmed once again that allow_url_fopen is indeed On even thought the errors like that below indicate allow_url_fopen=0.

    [19-Oct-2017 18:23:59 UTC] PHP Warning: getimagesize(): http:// wrapper is disabled in the server configuration by allow_url_fopen=0 in /home/tripawds/public_html/wp-content/plugins/avatars/avatars-files/avatar.php on line 41

    I completely understand about response time on this, as my pro Sites thread is definitely more advanced (and more important) than this! :slight_smile:

  • jcnjr
    • HummingBird

    FYI: Results from further investigation...

    phpinfo indicates that allow_url_fopen is indeed ON in php.ini (see screenshot):

    PHP Version 7.0.24
    Directive Local Value Master Value
    allow_url_fopen On On
    allow_url_include On On

    However, adding some debug code in the footer of the site results in:

    <!-- TESTING PHP: allow_url_fopen is OFF --><!-- Current PHP version: 7.0.24 -->

    Code used to display that (wrapped in php tags of course):

    echo '<!--TESTING PHP: ';
if (ini_get("allow_url_fopen") == 'On') {
echo "allow_url_fopen is ON";
} else {
echo "allow_url_fopen is OFF";
}
echo '-->';
echo '<!--';
echo 'Current PHP version: ' . phpversion();
echo '-->';

    So, it's on but the site (and plugin) think it is off. :-\

    I used that code in various different themes with the same results. I have also confirmed proper permissions on the /uploads and /avatars directories.

    Is this value (allow_url_fopen=0) stored anywhere in the database that I check?

    I do understand response time may be delayed. Thanks in advance for any feedback.

  • Lindeni Mahlalela
    • Recruit

    Hello jcnjr,

    I hope you are doing great today. Thank you for your feedback and patience on this issue.

    Every user avatar is displaying the default avatar across the network...all of a sudden.

    Were this avatars customized in the past? I have noticed that some profiles are showing custom avatars. Is this because some users have replaced the default or was it always a few who had custom avatars?

    I have created myself an account on the main site to see how the avatar behaves and in my case the proper avatar was displayed for my account on the /members page. I am not sure if I am missing anything here, my avatar is the gravatar linked to my email on gravatar.com.

    I have also checked the settings on cPanel and noticed that cPanel says allow_url_fopen is On. I have checked the php.ini file and found that it shows the following line:

    allow_url_fopen On

    Then I copied and modified your debug code above, I placed the modified code in a php file in 'wp-content/mu-plugins/is_allow_url_fopen_on.php', then I activated debug logging in wp-config.php. After that I saw the output of this code in the debug.log is as follows:

    [20-Oct-2017 21:31:15 UTC] <!--TESTING PHP:
[20-Oct-2017 21:31:15 UTC] allow_url_fopen is OFF : 1
[20-Oct-2017 21:31:15 UTC] Current PHP version: 7.0.24
[20-Oct-2017 21:31:15 UTC] END TESTING PHP -->

    Please note that the value of 1 is the value of 'ini_get("allow_url_fopen")'. The debug log reported in the second post suggests that '0' means OFF which means 1 = On, but the debug code says its off because we are checking against "On" and not "1".

    Further research have shown that the value is supposed to be Boolean (true / false) which is usually represented by 0 for false and 1 for true. But in the forums they use On and Off to allow or disallow url_fopen.

    I have then tried to modify the php.ini to reflect On with 1 as follows:

    allow_url_fopen = 1

    This causes cPanel to say allow_url_fopen is OFF because it expects one but on the other hand PHP thinks allow_url_fopen is ON because it expects 0 to mean OFF and 1 to mean ON.

    Is this value (allow_url_fopen=0) stored anywhere in the database that I check?

    No, this value is defined in PHP's default config in the file php.ini and can also be overridden by defining it in a custom php.ini or .user.ini file located in the root of your website. you can set the allow_url_fopen value by adding the following line in wp_config.php:

    ini_set('allow_url_fopen', '1'); //enable allow_url_fopen

    And

    php_value allow_url_fopen On

    In .htaccess file in the root of the folder you want to allow_url_fopen.

    Could you please confirm why some accounts are showing custom avatar and some are not. Is this because they have recently changed them after the issue occurred or it has always been like that.

    I hope to hear from you soon. We will continue to troubleshoot and find the root cause of this issue.

    Have a nice day.
    Mahlamusa

  • jcnjr
    • HummingBird

    Mahlamusa said:

    Were this avatars customized in the past?

    Yes, the majority of users had uploaded custom avatars which were all displaying properly until two days ago. The default avatar is now displaying for nearly every user. The issue first appeared after our site recovered from an apparent DDoS attack which resulted in a prolonged database connection error.

    I have noticed that some profiles are showing custom avatars. Is this because some users have replaced the default or was it always a few who had custom avatars?

    Yes, our members like their avatars. (And they want them back.) Some have uploaded new avatar photos since this started happening. Other avatars – in our forums for instance – are reverting to their respective Gravatars.

    I have created myself an account on the main site to see how the avatar behaves and in my case the proper avatar was displayed for my account on the /members page. I am not sure if I am missing anything here...

    I noticed that, thank you. The site will display Avatars in this order:
    1. The user-uploaded avatar,
    2. If no custom avatar has been uploaded, It will show a users Gravatar,
    3. If no Gravatar exists, the site Default avatar is shown.

    Please Note: Uploads of new Avatars (via the plugin) display properly. Only all previously uploaded Avatars are now displaying the Default (unless the user has a Gravatar).

    Could you please confirm why some accounts are showing custom avatar and some are not.

    Hopefully my explanation above (in this post) are clear. Since the issue started ocurring the other day, 1. I have uploaded a couple user avatars for testing purposes (e.g.; Admin & Betaman user accounts).
    2. Other users have uploaded their own new custom avatars.
    3. Gravatars are displaying for users who have them.
    4. The vast majority of users now have the Default Avatar showing, when they had custom uploaded Avatars the other day.

    Thank you for your prompt support and replies!

  • jcnjr
    • HummingBird

    Mahlamusa Please Also Note...

    And
    php_value allow_url_fopen On
    In .htaccess file

    Adding this line to the .htaccess file breaks the site, resulting in the error:
    Internal Server Error
    The server encountered an internal error or misconfiguration and was unable to complete your request.

    you can set the allow_url_fopen value by adding the following line in wp_config.php:
    ini_set('allow_url_fopen', '1'); //enable allow_url_fopen

    Adding this alone without the .htaccess edit did not affect the sate of allow_url_fopen.

  • jcnjr
    • HummingBird

    I am now also seeing many errors like this in the root error_log file, which doesn't even look like an "error" to me since I don't know the meaning of "type: 3".

    [20-Oct-2017 21:11:58 UTC] Image: /home/tripawds/public_html/wp-content/plugins/avatars/avatars-files/images/default-avatar-96.png, w: 96, height: 96, type: 3

    I found no errors related to the .htaccess edit. :-\

  • jcnjr
    • HummingBird

    Mahlamusa
    Have you been making edits to the Avatars plugin or any pages on our Tripawds site???

    I woke up this morning to discover the styling for all the Avatars in Recent Posts widgets throughout the main site are all messed up. They are displaying much larger and differently than expected. I had to remove these from our Forums and Chat page since their display was just ridiculous and wrong.

    The attached screenshot shows how they are appearing on the home page, again WAY too big! What happened?

    Please provide an update ASAP.

  • Lindeni Mahlalela
    • Recruit

    Hello jcnjr

    I hope you are doing great today. Thank you so much for your feedback and additional information.

    Yes, the majority of users had uploaded custom avatars which were all displaying properly until two days ago.

    The issue first appeared after our site recovered from an apparent DDoS attack which resulted in a prolonged database connection error.

    I still see many avatars in the uploads folder that possibly means the plugin is failing to read the correct urls or the DDoS attack caused issues in the database which resulted in the url's being changed. If this is the case we need to find out what is going on in the database, maybe the urls can't be found there for each avatar. If the defaults are already showing, this is likely the case because if they are properly linked, then they must be linking to the correct avatar for each user.

    I am afraid to say that it seems that DDoS attach has caused some damage on your site. If it is possible to restore a backup of your files by merging your current 'wp-content/uploads/avatars' folder with one from your backups then use the following script to rewrite the avatar url to point to the correct file:

    add_filter( 'get_avatar', 'try_to_fix_avatar', 10, 5 );
function try_to_fix_avatar( $avatar, $id_or_email, $size, $default, $alt ){
	if ( is_ssl() ) $scheme = 'https://';
	else $scheme = 'http://';

	if ( is_numeric ( $id_or_email ) ) {
		$user_id = $id_or_email;
	}else{
		$user = get_user_by( 'email', $id_or_email ) ;
		$user_id = $user->ID;
	}

	$avatar_url = $scheme . 'tripawds.com/avatar/user-' . $user_id .'-96.png';
	$avatar = '<img class="aligncenter" src="' . esc_url( $avatar_url ) . '" alt="'.esc_attr( $alt ).'" height="96" width="96">';
	return $avatar;
}

    I have placed this code for you in 'wp-content/mu-plugins/try-fix-avatar-url.php' but you can remove this file and paste the code in your theme's functions.php file, but the mu-plugin is better option to prevent any issues that might occur when updating your theme. The code seems to do nothing for now because it returns either the new avatar or the default, this is because most of the user avatars have been changed to the default and the 'uploads/avatars/user' folder contain mostly empty folders instead of having avatars in those folders. I think if you have a backup you can just restore all sub folders in ' 'uploads/avatars/user' and after that the code should start to show the correct avatars that were shown before the attack.

    Other avatars – in our forums for instance – are reverting to their respective Gravatars.

    This is expected if the user does not have a custom avatar defined, this will be the case for most users as the avatars seems to be have lost during the attack.

    Adding this line to the .htaccess file breaks the site, resulting in the error: Internal Server Error

    This is possible if the host does not allow .htaccess to override directives. Your host can help with this as most of the time it can only be changed by your host in vhost configuration on the server.

    This line:
    ini_set('allow_url_fopen', '1');
    Must be added to wp-config.php

    I am now also seeing many errors like this in the root error_log file, which doesn't even look like an "error" to me since I don't know the meaning of "type: 3".

    Do not worry about this, these are not errors but debug logs I logged using code to show some info about the avatar before being output, I needed the info to see the results of the getimagesize() function that was previously reported to have issue with allow_url_fopen. I have disabled the logging for this so it should not come again unless I activate it to get more info.

    You will also notice from the latest logs that there are new entries prefixed with any of the following two lines:

    Avatar Test by Mahlamusa:
[Mahlamusa] New Avatar:

    Again you should not worry about these lines because I was using 'error_log()' function on the code to add these lines so I can get more information about the avatars being displayed. I have now disabled these as well because I have the information I need for now.

    For now, it seems the website was impacted by the DDoS attack you mentioned and it's either some data was lost in the database or some uploaded files were lost. So what I suggest is that you check the files and database against a backup taken before the attack and if there is evidence of the files in the backup then please restore them so that you can get the previously uploaded avatars. Please advise if you did any database or file restore after the attack.

    I hope this helps, thank you.

    Have a nice day.
    Mahlamusa

  • jcnjr
    • HummingBird

    Mahlamusa Thank you for the update, and your continued help!

    If it is possible to restore a backup of your files by merging your current 'wp-content/uploads/avatars' folder with one from your backups then use the following script

    Please explain:
    1. What do you mean by "merge"?     Replace contents of /avatars directory? Combine the contents of both /avatars directories???
    2. Use the script how? Will I always need to keep this mu-plugin? Or run it once somehow then delete it?

    The code seems to do nothing for now...

    I think it may doing quite a bit...please see my most recent issue reports and screenshots!

  • jcnjr
    • HummingBird

    Mahlamusa said:

    check the files and database against a backup...

    Are you suggesting I also restore the database!? This would remove users and sites registered during the last couple days, and affect Pro Sites that have recently renewed too. Our database is multi-gigabytes so this is no easy task either.

    Please advise if you did any database or file restore after the attack.

    I did not.

  • jcnjr
    • HummingBird

    Mahlamusa
    My cPanel account backu is 23+ GB, the active /avatars directory alone is 1.5+ GB.
    I cannot download and comb through all the files. What other options do I have?

    Earlier I asked if any information regarding this Avatars issue was stored in the database and you said no. Perhaps I mis-communicated...are there any specific tables in the database I can check for corruption or errors pertaining to this issue?

  • jcnjr
    • HummingBird

    Mahlamusa
    I just confirmed that the try-fix-avatar-url mu-plugin is indeed causing problems on the Comment moderation admin pages. I temporarily compressed the php file and was able to approve comments on the previously broken moderation page. I unzipped the file, and the problem returned. For now, I have left that mu-plugin activated while you troubleshoot further and report back.

    I also confirmed the mu-plugin was causing improper display of avatars on the home page, in the dashboard, blogs and members directory, and recent posts widgets throughout the site. I will eventually need to deactivate that plugin if those issues cannot be addressed.
    Thank you!

  • Lindeni Mahlalela
    • Recruit

    Hello jcnjr

    Thanks for your feedback and thank you for your patience.

    Have you been making edits to the Avatars plugin or any pages on our Tripawds site???

    No. I only added the mu-plugin to try and fix the url of the avatar.

    AND: Our Comment Moderation page is now broken all of a sudden!

    I have checked the code and fixed it. The Comments moderation seems fine now.

    FYI: All avatars (user and blog) are also now displaying huge in the network dashboard.

    I corrected the size to 32 instead of the 96. I am sorry I took the size from the "Meet The Tripawds Pack:" on the home page and didn't realize it was affecting all other pages. My sincerest apology for that.

    Please explain:

    1. I meant COMBINE the contents of both /avatars directories.
    2. The script need to stay in place if you are able to restore the files and not the database.

    Are you suggesting I also restore the database!?

    It seems too much to do if there has been many changes in the database. So as you say some new data will be lost, please DO NOT do this.

    My cPanel account backu is 23+ GB, the active /avatars directory alone is 1.5+ GB.
    I cannot download and comb through all the files. What other options do I have?

    If the backup is on the same server and you have enough disk space to extract the backup, then you do not need to download it. In this case you will have to copy it to a sub folder and extract it inside that sub folder then check a few of the sub folders of the /avatars folder, if you see that they are not empty then you can copy the previously uploaded avatars into the new folder.

    Please evaluate your options before doing so. I say so because I cannot make any guarantees that this will fix the issue but, also make sure you zip the current /avatars folder to make sure the process does not result in further damage.

    Earlier I asked if any information regarding this Avatars issue was stored in the database and you said no. Perhaps I mis-communicated...

    You asked if the value for "allow_url_fopen=0" is stored somewhere in the database and I said No. This is because the settings for the "allow_url_fopen" are managed by cPanel and stored in a file called php.in in the server's files, this is not stored in the database and it is not defined in the plugin. The plugin is only affected by what value is stored but it does not manage or store this in the database.

    are there any specific tables in the database I can check for corruption or errors pertaining to this issue?

    From the code, I have seen that the avatar is stored as a user meta in the wp_usermeta table. The meta key used is 'user_avatar'. I have looked at the code and have seen that this meta key does not exist for all the users I checked.

    I just confirmed that the try-fix-avatar-url mu-plugin is indeed causing problems on the Comment moderation admin pages.

    Your confirmation is valid. I have fixed the code and it should now work properly. I can also deactivate it if it is currently not being used.

    I hope this answers all your questions. Please do not hesitate to ask if you have any further questions.

    Have a nice day.
    Mahlamusa

  • jcnjr
    • HummingBird

    Mahlamusa said:

    I have seen that the avatar is stored as a user meta in the wp_usermeta table.

    Where!? I searched the wp_usermeta table and found very few mentions of any %avatar% data. Please see the attached screenshots...
    1. "usermeta-metakey" shows only one entry in the meta_key column.
    2. "usermeta-metavalue" shows only three users, with the word avatar in their profile description.

    ALSO: While I further investigate your suggested /avatars directory restoration, do you have any feedback regarding why allow_url_fopen would be indicated as OFF with the theme footer snippet code I used, when the function is clearly turned ON in php.ini?

    As a reminder, here is the code I placed in the footer of our site (wrapped in PHP tags of course):

    echo '<!--TESTING PHP: ';
if (ini_get("allow_url_fopen") == 'On') {
echo "allow_url_fopen is ON";
} else {
echo "allow_url_fopen is OFF";
}
echo '-->';

echo '<!--';
echo 'Current PHP version: ' . phpversion();
echo '-->';

    "View Page Source" on any page to see the results at the bottom, near /footer.

    <!--TESTING PHP: allow_url_fopen is OFF--><!--Current PHP version: 7.0.24-->

    I placed this same code on various sites with the same results to determine it is not a Theme issue.

    NOTE: We did an extensive search for all .ini files with allow_url_fopen and all instances found it equals On:

    root@<servername> [/]# grep -rnw --include=*.ini allow_url_fopen
home/tripawds/public_html/php.ini:6:allow_url_fopen = On
home/tripawds/public_html/.user.ini:7:allow_url_fopen = On
home/tripawds/php.ini:6:allow_url_fopen = On
home/virtfs/tripawds/home/tripawds/public_html/php.ini:6:allow_url_fopen = On
home/virtfs/tripawds/home/tripawds/public_html/.user.ini:7:allow_url_fopen = On
home/virtfs/tripawds/home/tripawds/php.ini:6:allow_url_fopen = On
home/virtfs/tripawds/usr/local/lib/php.ini:498:allow_url_fopen = On
home/virtfs/tripawds/usr/local/cpanel/scripts/php.ini:483:allow_url_fopen = On
home/virtfs/tripawds/usr/local/cpanel/3rdparty/php/54/etc/roundcube/php.ini:818:allow_url_fopen = On
home/virtfs/tripawds/usr/local/cpanel/3rdparty/php/54/etc/horde/php.ini:819:allow_url_fopen = On
home/virtfs/tripawds/usr/local/cpanel/3rdparty/php/54/etc/phppgadmin/php.ini:818:allow_url_fopen = On
home/virtfs/tripawds/usr/local/cpanel/3rdparty/php/54/etc/phpmyadmin/php.ini:818:allow_url_fopen = On
home/virtfs/tripawds/usr/local/cpanel/3rdparty/php/56/etc/roundcube/php.ini:818:allow_url_fopen = On
home/virtfs/tripawds/usr/local/cpanel/3rdparty/php/56/etc/php.ini:818:allow_url_fopen = On
home/virtfs/tripawds/usr/local/cpanel/3rdparty/php/56/etc/horde/php.ini:819:allow_url_fopen = On
home/virtfs/tripawds/usr/local/cpanel/3rdparty/php/56/etc/phppgadmin/php.ini:818:allow_url_fopen = On
home/virtfs/tripawds/usr/local/cpanel/3rdparty/php/56/etc/phpmyadmin/php.ini:818:allow_url_fopen = On
home/virtfs/tripawds/usr/src/conf_2015_08_03/usr/local/lib/php.ini:484:allow_url_fopen = On
home/virtfs/tripawds/usr/src/conf_2015_09_01/usr/local/lib/php.ini:494:allow_url_fopen = On
home/virtfs/tripawds/opt/cpanel/ea-php71/root/etc/php.ini:816:allow_url_fopen = On
home/virtfs/tripawds/opt/cpanel/ea-php56/root/etc/php.ini:820:allow_url_fopen = On
home/virtfs/tripawds/opt/cpanel/ea-php70/root/etc/php.ini:816:allow_url_fopen = On
home/virtfs/tripawds/opt/cpanel/ea-php55/root/etc/php.ini:820:allow_url_fopen = On
home/virtfs/tripawds/opt/cpanel/ea-php54/root/etc/php.ini:816:allow_url_fopen = On
usr/local/lib/php.ini:498:allow_url_fopen = On
usr/local/cpanel/scripts/php.ini:483:allow_url_fopen = On
usr/local/cpanel/3rdparty/php/54/etc/roundcube/php.ini:818:allow_url_fopen = On
usr/local/cpanel/3rdparty/php/54/etc/horde/php.ini:819:allow_url_fopen = On
usr/local/cpanel/3rdparty/php/54/etc/phppgadmin/php.ini:818:allow_url_fopen = On
usr/local/cpanel/3rdparty/php/54/etc/phpmyadmin/php.ini:818:allow_url_fopen = On
usr/local/cpanel/3rdparty/php/56/etc/roundcube/php.ini:818:allow_url_fopen = On
usr/local/cpanel/3rdparty/php/56/etc/php.ini:818:allow_url_fopen = On
usr/local/cpanel/3rdparty/php/56/etc/horde/php.ini:819:allow_url_fopen = On
usr/local/cpanel/3rdparty/php/56/etc/phppgadmin/php.ini:818:allow_url_fopen = On
usr/local/cpanel/3rdparty/php/56/etc/phpmyadmin/php.ini:818:allow_url_fopen = On
usr/src/conf_2015_08_03/usr/local/lib/php.ini:484:allow_url_fopen = On
usr/src/conf_2015_09_01/usr/local/lib/php.ini:494:allow_url_fopen = On
opt/cpanel/ea-php71/root/etc/php.ini:816:allow_url_fopen = On
opt/cpanel/ea-php56/root/etc/php.ini:820:allow_url_fopen = On
opt/cpanel/ea-php70/root/etc/php.ini:816:allow_url_fopen = On
opt/cpanel/ea-php55/root/etc/php.ini:820:allow_url_fopen = On
opt/cpanel/ea-php54/root/etc/php.ini:816:allow_url_fopen = On

    Thanks again for your help and feedback!

  • jcnjr
    • HummingBird

    One more thing...searching the database further, I found a couple references to %avatar% in the wp_sitemeta table. Please review the attached screenshots and advise if you notice anything odd.

    1. "sitemeta-metakey" shows there are two rows for the avatars_plugin_version. Could this duplicate be causing an issue? Can one row be deleted? Which one?

    2. "sitemeta-metavalue" shows all rows including %avatar% in the meta_value column. Could that transient be safely deleted? Anything else peculiar here?

    Thanks again Mahlamusa !

  • jcnjr
    • HummingBird

    jcnjr said:

    While I further investigate your suggested /avatars directory restoration, do you have any feedback regarding why allow_url_fopen would be indicated as OFF

    Mahlamusa
    Please disregard this request for feedback about "allow_url_fopen".

    I have finally had a chance to review and restore a backup of our avatars/user/ files. Many of the avatar images (e.g.; user-1234-96.png, user-1234-128.png, etc) were indeed missing from the current /avatars/user folders.

    I am pretty certain now that this issue was caused by the plugin removing the files. Perhaps something misfired during a recent plugin update.

    I also remembered that this happened (avatars disappearing) before a couple years ago, when the plugin code changed to move the location of the /avatars folders. In this topic from 2014, the discussion includes suggestions for deleting avatars of deleted users.

    At that time, Vaughan prepared this script to do exactly this, but according to the thread, Ignacio mentioned that the functionality was implemented into the plugin.

    Why am I so certain this is what happened? When I compared the /avatars/user folders before and after I restored our recent backup, I discovered:
    1. The /users/ folders were all present, but empty, prior to restoring the files. (Just like Ignacio explained.)
    2. Only the cropped avatar images were deleted (e.g.; user-1234-96.png, user-1234-128.png, etc).
    3. Original images uploaded by users (e.g.; image.jpg) remained in the folders.
    4. I confirmed that the delete.php script Vaughn provided, was NOT present in the folder.
    5. After restoring the /user folder backup, avatars appear to be displaying again for users that showed the Default when I reported this issue.

    So... how can we ensure this does NOT happen again!?

  • Kasia Swiderska
    • Support nomad

    Hello jcnjr,

    It seems that links to thread you mentioned are missing, can you paste them again? You are suspecting that issue was related to plugin update - do you maybe remember from what previous version you updated (or maybe you can check that from backup files)?
    If we have this info we can try to replicate issue.

    kind regards,
    Kasia

  • jcnjr
    • HummingBird

    Kasia Swiderska said:

    links to thread you mentioned are missing

    Interesting...

    September, 2013 Avatars Support Topic:
    https://premium.wpmudev.org/forums/topic/default-avatars-display-for-all-after-update
    (Discussion of Avatars directory location changes.)

    April, 2014 Avatars Support Topic:
    https://premium.wpmudev.org/forums/topic/default-avatars-showing-again-after-update
    (Discussion includes subject of deleting old avatars from deleted user accounts.)

    Where Ignacio mentions...

    I just released a new version that is working better when deleting avatars ( it does not delete folders now, just files)...

    Here: https://premium.wpmudev.org/forums/topic/default-avatars-showing-again-after-update#post-671301

    And Vaughn discusses delete.php script here:
    https://premium.wpmudev.org/forums/topic/default-avatars-showing-again-after-update#post-683078
    And here:
    https://premium.wpmudev.org/forums/topic/default-avatars-showing-again-after-update#post-683250

    Kasia Swiderska also said:

    do you maybe remember from what previous version you updated

    We are currently running Avatars v. 4.1.8.

    I don't know when the last version update was, but it appears we've been running this version since July, 2017±. So it was likely not an update that triggered the deletion of avatar files. :-\ I just have no other explanation why only the user avatar files (e.g.;user-1234-96.png, user-1234-128.png, etc.) would suddenly go missing.

    Thanks again!

  • Lindeni Mahlalela
    • Recruit

    Hello jcnjr

    I hope you are doing great today. I am so sorry for the delayed response from our side and I am sorry for all the inconveniences that may have been caused by the delay.

    So... how can we ensure this does NOT happen again!?

    You should first test new updates on your test/sandbox environment before pushing them to your live server. In order for this to be helpful, you must have your staging site on the same server as the live site to make sure that the environment for both the staging and live site is identical, in which case if a new version works fine in the test website then it should also work fine in the live website.

    We are currently running Avatars v. 4.1.8

    This version was published on June 29, 2017 and the only documented change was related to Membership plugin integration. So I think if the Membership Pro plugin was not active on any site/blog on your network then it should not cause any trouble. The version before that was published on April 6, 2017. If the avatars were working fine immediately after these updates then the update was not a result.

    Unfortunately, it is very hard to trace this issue as it is hard to reproduce and we are not sure when exactly did this happen.

    So it was likely not an update that triggered the deletion of avatar files. :-\ I just have no other explanation why only the user avatar files

    I totally agree with you on this. There is no traceable reason why this have happened and the error_log file does not have information we can use to trace this.

    For now, I advice you to always keep the current working version, if there is a new update please test it first on your test site and see if it works. This applies not only to the Avatars plugin but also WordPress core, Theme and all other Plugin updates as well. You'll never know what could go wrong so it is always good to be on the safe side.

    I am sorry we do not have anything much we can do to get to find why this happened, but we are always willing to help in anyway possible if you have any further questions.

    Have a nice day.
    Mahlamusa

Thank NAME, for their help.

1 Point
5 Points
15 Points
Other

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.