Category Archives: Social Media

Programmatically Clearing the Facebook Share Image Cache

When you share a URL on Facebook, it scrapes the page for the URL for the Open Graph data to determine what image/video to display.  Facebook caches the image for that URL, so if you change the image and then share the same URL at a later time, the old image will still get displayed, which is probably not what you want to do.

Facebook provides the Open Graph Debug Tool that can be used to manually clear the cached value for the URL, but that may not be a workable if your website allows images to be changed dynamically.  Ideally, you would want a way to programmatically clear the cache after the associated image is changed.

Fortunately, there is a way to clear the cache using the OpenGraph API by forcing a scrape of the URL. The key is to set the ‘scrape’ parameter to true in the API call. The following Ruby code assumes that the Facebook application id and secret are stored in environment variables.

facebook_open_graph.rb

module FacebookOpenGraph
  def self.clear_cache(url)
    params = {
      :client_id => ENV['FACEBOOK_APP_ID'],
      :client_secret => ENV['FACEBOOK_SECRET'],
      :grant_type => "client_credentials"
    }
    uri = URI("https://graph.facebook.com/oauth/access_token?#{params.to_query}")
    response = Net::HTTP.get(uri)
    access_token = Rack::Utils.parse_nested_query(response)["access_token"]
    unless access_token.nil?
      uri = URI('https://graph.facebook.com')
      res = Net::HTTP.post_form(uri, 'id' => "#{url}", 'scrape' => 'true',
          'access_token' => "#{access_token}", 'max' => '500')
    end
  end
end

Then to clear the cache you merely need to call the clear_cache method, passing in the URL being shared.

FacebookOpenGraph.clear_cache("http://myurl.com/some_cool_page")

Facebook URL Linter, Critical Errors, and Rackspace

When you share a URL on Facebook, Facebook will scrape the page to find the Open Graph data embedded in the page.

Facebook also provides a tool called the Open Graph Object Debugger to help you debug errors found in the page.  This can be rally useful if, for instance, your tags are not well-formed, or there are problems with the images or videos that are on the page being shared.

Sometimes, unfortunately, you get a dreaded “Critical Errors That Must Be Fixed – Error Linting URL” as shown below.

UrlLinterCriticalError

Unfortunately, this doesn’t tell you a lot about the cause of the error.  I was trying to have an image display using the og:image tag.  I had been able to successful share pages that had images that were in my Rails  asset directory, but this particular page used an image that was hosted on Rackspace Cloud Files.

To try and diagnose whether there was a problem with the image (e.g. corrupt file, invalid size for Facebook, etc) I downloaded the image and stored it in my Rails assets.  Everything worked fine.  No errors from the Facebook URL Linter.  The problem must have something to do with the storage on Rackspace.  But browsing to the image on Rackspace worked fine as well.  The image displayed fine in the browser and was publicly accessible.

Why wasn’t the Facebook URL Linter able to parse it?
Well when you store files with Rackspace Cloud Files, you get a pretty hideous URL, like

http://12345678901234567890-12345678901234567890123456789012.r12.cf3.rackcdn.com

A URL is a URL right?  Well yes and no.  I think the Facebook URL Linter finds this to be a pretty suspect URL and considers it spammy.  So I needed to make the URL a little more “friendly” to a spam filter.

The answer was to use a CNAME to map a more readable URL to the Rackspace URL.

My client’s site is hosted on GoDaddy, so that meant going into their DNS settings and adding a CNAME record to point to the Rackspace URL.  I picked something meaningful like “images”.  So now my og:image tag could change from

<meta property="og:image" content="http://12345678901234567890-12345678901234567890123456789012.r12.cf3.rackcdn.com/some_image.png">

to

<meta property="og:image" content="http://images.mydomain.com/some_image.png">

In hindsight, the CNAME is a good idea on its own. Sure it might be an extra hop to get the image, but having a more logical URL makes a lot of sense, and it also makes in easier to change where your images are stored.