Default Gravatar images and SSL

I have a client who runs a number of WordPress/BuddyPress sites over SSL. He noticed in the last few days that default Gravatar images – the images that Gravatar serves when there is no Gravatar associated with the queried email address – were not being served. The browser showed broken images, and when you attempted to load the associated https://secure.gravatar.com URL in a separate tab, you’d see the message “We cannot complete this request, remote data could not be fetched”.

After a bit of futzing around, I found this recent post by Eric Mann describing a similar issue with the Photon CDN feature in the Jetpack plugin. He managed to figure out that Automattic’s CDN service wasn’t fetching items that were served over HTTPS. (The fact that it ever worked was, apparently, a bug; that “bug” was recently fixed.)

It turns out that the same thing is true for Gravatar’s “Default Image” feature (unsurprising, as I assume it uses the same CDN as Photon). Gravatar lets you specify a local file that will be served if no actual Gravatar is found: <img src="https://www.gravatar.com/avatar/00000000000000000000000000000000?d=http%3A%2F%2Fexample.com%2Fimages%2Favatar.jpg" /> But, as of the last few weeks, if the value of the d= param is served over HTTPS only, Gravatar throws an error.

There are a couple strategies for working around the problem.

  • Use Gravatar’s defaults instead – Gravatar hosts a number of default images that you can use, instead of a local image. This is especially pertinent in the case of BuddyPress. BP’s default behavior is to construct Gravatar requests like this: https://www.gravatar.com/avatar/00000000000000000000000000000000?d=http%3A%2F%2Fexample.com%2Fimages%2Fwp-content%2Fplugins%2Fbuddypress%2Fbp-core%2Fimages%2Fmystery-man.jpg. The thing is that this mystery-man.jpg that ships with BuddyPress is the same image as what you get with ?d=mm. So an easy way around the problem of Gravatar reading from your SSL-protected site is to avoid Gravatar from making any requests to your site at all. In BuddyPress, use the following:

    [code language=”php”]
    function bbg_use_gravatar_mm() {
    return ‘mm’;
    }
    add_filter( ‘bp_core_mysteryman_src’, ‘bbg_use_gravatar_mm’ );
    [/code]

  • Allow non-SSL access to your default – As suggested in Eric’s post, you can tell your webserver that some of your content can be served over HTTP rather than HTTPS. For example, on one of the sites I’m working on, we force HTTPS for all requests using an .htaccess rule. I can amend it to allow an exception for the custom Gravatar default:

    [code]
    RewriteCond %{HTTPS} off
    RewriteCond %{REQUEST_URI} !^/wp-content/themes/yourtheme/images/default-gravatar.jpg$
    RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R,L]
    [/code]

    Then, force BuddyPress to tell Gravatar you want the non-SSL version of the fallback:

    [code language=”php”]
    function bbg_custom_default_avatar() {
    return set_url_scheme( get_stylesheet_directory_uri() . ‘/images/default-gravatar.jpg’, ‘http’ );
    }
    add_filter( ‘bp_core_mysteryman_src’, ‘bbg_custom_default_avatar’ );
    [/code]

Even if you’re not using BuddyPress or WordPress, the same strategy applies: if you’re serving your whole site over HTTPS, tell Gravatar to use either one of its own images or one of your non-SSL-available images as its default.

6 thoughts on “Default Gravatar images and SSL

  1. Paul Gibbs

    Maybe we should switch BP to use the hosted version of mystery man if the image is the same. It would be nice to “fix” the broken images that one gets in local dev environments if the user specified doesn’t have a gravatar.

    Reply
  2. Luke

    Thanks again for this, Boone.

    The second solution still left broken gravatars at /users.php, so I used get_theme_root_uri () . ‘/mybuddypresshtheme/images/defaultgravatar.jpg… instead.

    Reply
  3. Adarsh Mehta

    Hello, Boone.

    I recently purchased an SSL certificate for my blog. I have successfully activated it, fixed basic problems because of which insecure content was being displayed, forced https all across my website and my blog and also made some other small changes which were necessary.

    I still have one problem for which I am not able to find a good solution. The Gravatars on some of my comments are still being loaded from a ‘http’ source.

    I have installed SSL Insecure Content Fixer plugin on my WordPress blog but I do not want to use that plugin to force load ‘https’ secure Gravatar images because it increases the load time of the page and makes the user experience bad.

    I googled for a solution and found your article. However, I am still not able to fix it. I am not using BuddyPress. The Gravatar images are just in my comments (the comments which do not have an original photograph of the user).

    I have also tried changing the image system to mystery person and then changing it back to Gravatar system. It solved the problem on Chrome, but not on Firefox or Opera for some reason.

    Right now, I have kept the mystery person image system so that my site loads properly till I find a fix.

    I hope you understood my problem. I would love it if you could help me out or just point me in the right direction. Sorry for such a lengthy and boring comment explaining my problems.

    Thank you.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *