-
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?
-
-
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?
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.
Thanks for isolating that issue Oliver.
With what would you suggest we replace fopen for our gravatar checks?
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.
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.
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
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
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
Hello Oliver,
thank you for the bug report, now the new version is released on WordPress.org.
Regards,
MartinHi Martin,
The update broke the blank avatar for me – even the settings page show a broken link to the picture. I getWhen I display the cached picture, I get for those without gravatar.
Thanks in advance !
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
