by Bart Kuijper.
All requests to load an avatar from gravatar.com are redirected to a local image, preventing Gravatar from potentially gathering data about your site …
When displaying a post or comment with avatars enabled, WordPress will always check for the existence of a Gravatar. (Note: even the default avatars ‘mystery person’ and ‘blank’ are in fact Gravatars served from gravatar.com.) WordPress does this by sending an MD5 hash of every displayed post or comment author’s email address to gravatar.com. Even with many plugins that introduce locally stored default or user avatars, this check still happens. On top of that, some themes or plugins force (Gr)avatars to load even if the display of avatars is disabled completely in WordPress’ settings. If for whatever reason you do not wish for Gravatar to receive these requests (which some people have voiced GDPR concerns about), this plugin is for you.
The way it works is every time WordPress attempts to display an avatar, this plugin first checks if the image is about to be retrieved from gravatar.com. If it is, the URL is changed to the locally stored ‘mystery person’ image (included with this plugin). If the avatar has any other source, this plugin doesn’t interfere.
Gravatars are also removed from the Discussion page in Settings and replaced with the locally stored ‘mystery person’ image. Again, any non-Gravatar images are left alone.
Upon activation of this plugin, if a Gravatar is selected as the default avatar, that setting is changed to the locally stored ‘mystery person’ image. If any non-Gravatar avatar is selected, that setting isn’t changed.
Upon deactivation of this plugin, if the locally stored ‘mystery person’ image is selected as the default avatar, that setting is changed to the Gravatar logo. If any non-Gravatar avatar is selected, that setting isn’t changed.
This plugin can be installed the usual way through WordPress’s interface. If you want to manually install this plugin:
That’s it. You can (de)activate the plugin as often as you like. You can remove it completely either by deleting it in WordPress or through FTP. This plugin doesn’t modify any files nor does it add anything new to the database, once removed there is no trace of it.
Not through the WordPress Dashboard. You would have to replace
/wp-content/plugins/redirect-gravatar-requests/mystery.jpg. You would also have to repeat this after each plugin update.
The reason for this choice is simple: if you enable the display of avatars, but use this plugin to block Gravatars, then you most likely are already using another plugin for custom avatars.
There is nothing to be configured about this plugin. As soon as it’s activated, it will redirect all attempts to load a Gravatar from gravatar.com to the locally stored ‘mystery person’ image included with this plugin.
You can verify that the plugin is working on a page displaying (Gr)avatars in Chrome by opening the developer console (default hotkey F12), selecting the ‘Network’ tab at the top, typing ‘gravatar’ in the console’s search box and then reloading the page (by pressing CTRL+R). With the plugin deactivated, you will see requests going out to gravatar.com. With the plugin activated, you will see those requests going to this plugin’s locally stored image instead.
This plugin filters the WordPress
get_avatar function. However some theme and plugin authors use their own code to load (Gr)avatars, in some cases even if the display of avatars is disabled completely in WordPress’ settings. In order for this plugin to be able to intercept Gravatars, the offending theme or plugin has to either be making use of the
get_avatar function or at least apply the
get_avatar filter in their code.
If you come across such a theme or plugin, feel free to open a support ticket and I’ll be happy to see if there’s a way to deal with it.
It should be, since this plugin specifically targets only Gravatars. If you do run into problems, please let me know.
get_avatarto also intercept Gravatars that were forcefully displayed by an unruly plugin.
/languages/redirect-gravatar-requests.pot), because it’s ignored and a new one is automatically generatad.