FV Gravatar Cache

Comments

1. sOliver 6 November 2010 at 10:36 pm

   Thanks a lot. I will add this to my list of “must-have” wordpress plugins!It will speed up my site quite a bit.

   I was surprised to see that even the default gravatar is loaded directly from gravatar.com, what a nonsense!

   I am wondering why they do not store the gravatars as image files (instead it’s something like 00c88182ec23fe1da17b92d33de65618)

   How am I supposed to add an expiry date as recommended by Google to the files then?

2. sOliver 6 November 2010 at 11:43 pm

   Ok, looks like all non-gravatars avatars are now broken, I get 404 links.

   All users without gravatar (filesize 13 byte) have 404 avatars, but people who actually use gravatars are working just fine.

   So.. it must be a problem with the “default” avatars that are created. How do you create/cache those?

3. sOliver 7 November 2010 at 1:13 am

   The problem might be this: // check if gravatar exists $headers = @get_headers( $out ); if( stripos( $headers[0], '404' ) !== FALSE ) { return $this->GetCacheURL()."default.png"; }

   My default (empty) gravatars are all loaded from gravatar.com and your plugin creates files for them. Then your plugin checks for a 404, but the file exists (13 byte).

   When I access the file directly it says “404 File does not exist” thou.

   Ok this doesn’t make any sense, I need a nap now will try to look into it tomorrow.

4. alec 7 November 2010 at 5:58 am

   Thanks for the feedback Oliver. We use FV Gravatar Cache on a lot of our busy sites, so we’d like to keep it running smoothly. FV Gravatar Cache does speed load times considerably.

   If you find the issue tomorrow, let us know and we’ll update the code right away.

5. sOliver 7 November 2010 at 12:07 pm

   I have tried it on two different servers now and on one it works properly so it won’t actually create empty gravatar files for people without gravatars.

   On the other it creates a gravatar (empty 13 bytes file) for all comments for some reason.

   I suppose it’s because I disabled fopen on one server and it checks via fopen if it’s a default avatar (compare line 437)

   Since fopen is a major security risk I would have to rewrite this check.

6. alec 7 November 2010 at 12:20 pm

   Thanks for isolating that issue Oliver.

   With what would you suggest we replace fopen for our gravatar checks?

7. Martin 8 November 2010 at 9:35 am

   Hi Oliver,

   My default (empty) gravatars are all loaded from gravatar.com and your plugin creates files for them. Then your plugin checks for a 404, but the file exists (13 byte).

   I’m sending you a tweaked main PHP file of the plugin. Can you test it to see if it solves the problem?

   I basically added another check for the 404. But I’m not sure if it will solve your problem. Can you provide the email address of some comment which has this bad 404 13B gravatar so I can see it? Or send me one of these 13B files?

   I have tried it on two different servers now and on one it works properly so it won’t actually create empty gravatar files for people without gravatars. On the other it creates a gravatar (empty 13 bytes file) for all comments for some reason.

   I suppose it’s because I disabled fopen on one server and it checks via fopen if it’s a default avatar (compare line 437) Since fopen is a major security risk I would have to rewrite this check.

   That’s a different part of code and has nothing to do with the default gravatars. But if you disabled the fopen function, that might be the reason why none of the gravatars are cached properly. The files are probably containing only some warning instead of the content. Can you check it out?

   Anyway, fopen is a standard function and is required to write the cached gravatar files. The more dangerous function is the remote fopen, but we are not using that. Have you any suggestion what we should be using instead of fopen and fwrite to write the cached files?

   Can you check if there are any warnings on plugin settings page? It should be wp-admin/options-general.php?page=fv-gravatar-cache on your site. It checks if the directory is writable. If you disabled just the writing permissions, it should display a warning.

   If you just disabled the fopen and fwrite functions, the plugin just can’t work, unless there is any other safer function which you think is better and we could use it.

   Thanks, Martin

8. sOliver 8 November 2010 at 12:00 pm

   Hi Martin,

   It’ working! At first it was stuck processing the very first gravatars and did not run the SQL Update to default.png. After cleaning out the cache folder including the log file, it’s now working just fine (maybe add this to readme.txt for troubleshooting)

   I suppose this did the trick: stripos( $gravatar, ‘404 File does not exist’ ).. when I accessed one of the empty gravatars this was exactly what I received as a message.

   I’m not that good at programming, but I think there are some alternatives to fwrite and fopen: fwrite alternative: file_put_contents() fopen alternative: file_get_contents() possibly even curl (more resource hungry thou) I disabled fopen in my php.ini, I am wondering why it’s working… will double-check that.

   Thank you for taking the time to fix this plugin so quickly, I will certainly look into your other plugins and consider a donation. Oliver

9. alec 8 November 2010 at 12:02 pm

   Hi Oliver,

   You’re welcome.

   A donation would be much appreciated.

   Thanks for taking the time to write to us about this issue and look into it with us.

   Making the web work for you, Alec

10. Martin 9 November 2010 at 1:49 am

    Hello Oliver,

    thank you for the bug report, now the new version is released on WordPress.org.

    Regards, Martin

11. Tim Luimes 8 March 2011 at 9:35 am

    I’ve noticed that when I display an image and the containers height and width are set to auto, it ignores the width and height settings within the img html element. So the image is always my default fv_gravatar_cache size. When I disable the cache plugin, the items follow the img elements settings again.

    I’ve disabled the auto width and height in my template, however there’s an auto width and height used in the new WP admin bar which causes the image size to be displayed in it’s wp_gravatar_cache setting size.

    If you could help out, it would be appreciated.

12. Martin 8 March 2011 at 10:08 am

    Hello Tim,

    we actually released a new version which is fixing this issue few minutes ago.

    Please upgrade and let us know how it works for you.

    Thanks, Martin

13. Djoh 9 March 2011 at 12:41 pm

    Hi Martin, The update broke the blank avatar for me – even the settings page show a broken link to the picture. I get

    When I display the cached picture, I get for those without gravatar.

    Thanks in advance !

14. Martin 10 March 2011 at 1:21 pm

    Hello Djoh,

    please try to resave the options.

    Also check if your .htaccess is not restricting access to your cache directory. We just discovered that it can (of course) cause issues, so we will cover that in FAQ soon.

    Thanks, Martin