I’m a Moodle developer by trade, with some administration duties thrown in for laughs. I see to the care and feeding of Lafayette College‘s Moodle sites. In addition, I handle some development and code management duties for the Collaborative Liberal Arts Moodle Project. All this is a long way of saying I push a lot of code around in a way that requires me to work with dozens (hundreds?) of developers whom I’ve never met. This means I have to document my work and develop against actual APIs. Further, working for an institution with thousands of students, staff, and faculty means that all our maintenances are published and (save emergencies) occur outside business hours. I can’t just shoot from the hip.
Gravatar is an online service which allows you to upload an avatar which will then be populated to other services. You don’t realize how many places use Gravatar until you upload an image and suddenly see yourself all over the web. It’s pretty cool. Gravatar provides a simple API so that you can add this functionality to your own website via web services. Moodle added support for Gravatars in the 2.2 release which dropped in December 2011. We turned it on at Lafayette since it’s easier than making thousands of people upload files.
So far, so good, right? Enter chaos.
Thursday morning we started seeing hundreds of broken user profile images on our Moodle instances. I knew we hadn’t touched anything. Stranger–we saw lots of Gravatars still appearing so it couldn’t be a recurrence of last Spring’s incident when Gravatar was unavailable. Cue an hour of tedious debugging until arriving at the conclusion that default image support had stopped working.
Gravatar’s API allows you specify a default image, to be used if the user doesn’t have a Gravatar. You may pass an image you host yourself, or use one of their stock images. Moodle uses the default headshot image, as defined by whatever theme you’re using. Moodle has a complex mechanism for determining which images to serve up, based on your current theme and context and whether caching is active. All image requests pass through theme/image.php, which acts as a clearinghouse for determining what image should be retrieved. This system is file extension agnostic for better compatibility and flexibility.
One of the benefits of collaborative development is that you’re usually not the first person to encounter a problem. I found that my issue had just been reported to the Moodle tracker by another developer who had come to the same conclusion. Here’s the issue. A Moodle request to Gravatar would look like this:
Let’s break that down. The URL contains the location of Gravatar’s image serving mechanism, an md5 hash of the user’s email address, a requested image size (s=100), and the default image url (d=
I still don’t have the full picture but it appears that Gravatar made a change–unannounced and undocumented–to require file extensions in the default image. Several developers submitted support requests to Gravatar trying to confirm that this was the case. After several days(!) I got an answer back from one of Gravatar’s “Happiness Engineers” (blech). I’ve quoted the relevant part below:
We have recently implemented some changes that wouldn’t change our current documentation so much as an enforce that default images must actually be images. They should also be publicly accessible.
I noticed in the case you mentioned that you’re using a php file to serve up the image. For security reasons, that will no longer work.
This is nonsense. My own testing shows that they’re just looking at the extension, which is poor man’s security at best. Extensions can be faked. If they were serious about security they would eschew this extension malarky and just check the mimetype.
For me the greater issue is that this change happened in the dead of night, with no warning. Many hours of developer and administration time will now be consumed working around a change, leaving aside for a moment that the change is bonkers. What the support person told me perfectly explains the problem, yet as of writing the online documentation doesn’t reflect it.
Gravatar itself acknowledges on the same documentation page, when discussing displaying a Gravatar image:
If you require a file-type extension (some places do) then you may also add an (optional)
.jpgextension to that URL:
I find that sentiment at odds with whatever process determined the change we’ve been discussing in this post.
So, that’s 760 words explaining the issue I spent far too much of my Thursday debugging. What does it all mean? That Gravatar is a neat, fun service which has no respect for the people who develop against its APIs. That may sound harsh but I maintain that if you have respect for your development community you don’t make changes like that without some kind of announcement or warning. That the change is technically deficient is also a cause for concern.
There’s a Moodle tracker item for providing support for alternative avatar services. It hasn’t gotten a lot of traction so far, but I intend to make a push there. Behavior like this makes me angry.
UPDATE: I’m amused, months later, to discover this blog post from Gravatar discussing the change, including the file extension requirement. It’s dated October 7, or over a week after the change and this blog post.