The best plugin for caching gravatar among the ones I tested so far

First of all thank you for rating the plugin.
This is important so that I can know that the plugin is being used by others.

I want the plugin to adapt to all projects that use Gravatar within wordpress. Your comment is important and I want to keep in mind your point of view in future updates.

However, I would like to know more about the permissions conflicts that you mentioned. So that I can take into account your situation if possible.

The “conflicts” were actually with cache configuration. For example, you are setting Cache-Control "max-age=0", whereas I had different settings for cache. I assume you do this to rely on the Last-Modified request header, which I’m removing in another configuration file. So, I end up with no cache at all for those images.

Regarding the permissions, see: https://httpd.apache.org/docs/2.4/upgrading.html#run-time
For Apache 2.4, Order directives should be replaced with Require equivalent directive. The old directive will cause Apache errors, unless you enable mod_access_compat.

In general, I think it is a good practice to warn the site admin about the htaccess file when it is generated.

Thank you very much for your explanation.

I will read on the subject and see how to resolve these conflicts.

I already had in mind to create a new tab for editing the .htaccess file, this way allowing to adjust the settings properly.

This configuration was based on the systems I use, it really has to be more generic.

However cached images have to be revalidated if you use multiple sizes of avatars on your site. Otherwise the browser will read some of your local cache and others from the server.

But anyway I think the best way is to allow the administrator to edit the file for the needs and I will work towards that.

However cached images have to be revalidated if you use multiple sizes of avatars on your site. Otherwise the browser will read some of your local cache and others from the server.

Honestly, I don’t think the plugin should change the cache policies already set by the admin. These are low level settings, and it is really difficult to determine good settings “automatically”, considering the possible interactions with other configurations and plugins.

Anyways, making the admin aware of this file should be enough. And allowing the admin to edit the file is a way to achieve that.

1 – I will allow the administrator to edit the file for the needs of the project.
2 – Allow the administrator to decide whether the file is created in the cache directory or not.

In addition, I will point out the need to revalidate avatars. It is the most difficult part because of my English.

Here’s an example on my site of the need to revalidate the avatars:
1. I’m going to visit this link https://www.ncdc.pt/members/ and I have the avatars of the visible members of my site, with size 150×150.
2 . I visit the link https://www.ncdc.pt/members/admin/ and I have several admin user avatars with various sizes 150×150, 50×50 among others.

If the admin user updates the gravatar between these two steps, we will have different avatars.

To avoid these browser cache problems, the browser must always send the if-Modified-Since header so that the avatar can be revalidated.

The way I have to do this is using in apache these three settings:
Header set Cache-Control “max-age = 0”
ExpiresActive Off
FileETag None

I believe there are other ways to do the same, however this was the way it worked with multiple browsers.

The options you intend to provide seem reasonable to me.

I also understand the need to invalidate the cache. However, the same reasoning applies to most of the images in a WordPress site: if you don’t have a cache invalidation mechanism, you may get outdated images (although inconsistencies may not be so obvious in other cases). So, the default site cache policy (set in the root htaccess file, for example) should work for gravatars too.

Moreover, you could also get the behavior you want with properly configured Etags. However, in your default configuration you are preventing Etags from working.

But again, the options you intend to provide seem reasonable to me.

Regarding ways to prevent the cache issues: would you consider to use a query string for cache invalidation?

That is, in the database you are saving a lastModified column. So, if the image URL had the ?v=11111111111 at the end, where 11111111111 is the lastModified value for the file, whenever you get a new version of the file, you would also update the lastModified value, so the browser would treat it as a completely different file (the cache details would be irrelevant and you could set a expire date of years for the file).

(A more reliable approach would be to include the lastModified value in the file name, so abc.png would be called abc.11111111111.png, and a rewrite rule would convert requests from abc.11111111111.png back to abc.png. The problem is that this would require rewrite rules, which require htaccess, which I would rather avoid.)

I have already spent a lot of time analyzing these proposed solutions.
They all have advantages and disadvantages.

Etag is not counseled when the site grows and we have to use multiple servers with multiple file systems.

? V = 01011970, query strings actually solved the problem but created several resource problems. Because we had to serve the avatars dynamically and it would be nice to have to use this plugin because Gravatar does that.

The idea of this plugin is to serve avatars with minimal cost. That’s why it serves the avatars statically.

V = 01011970, query strings actually solved the problem but created several resource problems. Because we had to serve the avatars dynamically and it would be nice to have to use this plugin because Gravatar does that.

The idea of this plugin is to serve avatars with minimal cost. That’s why it serves the avatars statically.

I’m not sure I understood what you mean by “we had to serve the avatars dynamically”, but if the server is properly configured, you can freely add query strings to static requests, and they should still be served statically. The query string is just a way to lie to the browser, to make it believe it is in the presence of a new file. The server typically only sends requests with php extension to PHP handler, and serves directly other resources.

With query strings you could completely eliminate requests to cached resources. With Last-Modified you have to check if the file was updated.

Note that this is the standard method used by WordPress for some static resources. For example, this site loads https://www.ads-software.com/support/wp-content/themes/pub/wporg-support/style.css?ver=20180419.

Yes WordPress actually uses query strings but consumes more resources to process them.

The plugin will not go that way. It will only serve avatars statically without query strings.

My problem with using query strings with dates is because filetime is a low-level function and has costs to get the file modification date. Since most of the avatars served are the default avatar and they do not have the date in the database. However, I’m thinking again with another approach.

Wait, I’ll give you some news.

Since using query strings does not solve the problem when sites use caches like wp super cache as other points that may not be desired may not be the only option. However this solution may be useful in certain cases. I will add as an option to use query strings and allow the project administrator to decide the best option for each case.

Thanks for the update (and for your time working on the plugin). Making this an option should be very helpful.

In my bigger site I will also have problems due to interactions with a page cache plugin (the query string will not fully prevent outdated avatars). Anyways, my goal in this site is really performance, and I don’t care about minor inconsistencies (I’m using aggressive cache policies even for page cache).

In another (smaller) site, the query string option should completely solve the cache issues for me.