How to Synchronize Social Media Shares, Counts, and Comments Across HTTP and HTTPS

Social Media

The Issue

I use a social media, sharing, or commenting plugin and it shows different data on HTTP and HTTPS versions of the same page/post.

Viewed via HTTP

Viewed via HTTP

Viewed via HTTPS

Viewed via HTTPS

Why Does This Happen?

We build a lot of sites that use social media sharing and commenting plugins, such as:

And if you really want to boil it down to the basics, each of these plugins essentially does the same thing: associate data (comments, share counts, likes, etc) with a specific URL. Pretty simple, right?

The issue described at the very beginning of this article arises because HTTP and HTTPS versions of the same page look like two separate URLs to most of these plugins.For all intents and purposes, these two URLs are treated as separate pages by most plugins, even though they point to the exact same content. That little ‘s’ makes all the difference.

I imagine there are times when this separation is desirable, however we typically want HTTP and HTTPS versions of a page to be treated the same, so that all comments, likes, shares, etc. appear the same, regardless of which protocol is being used in the URL. If that’s what you’re looking to do, then read on. . .

The Solution

To solve this problem, we essentially have to do two things:

  1. Get the HTTP version of the current page/post URL.
  2. Pass this URL to the plugin.

1. Get the HTTP URL

This is the easy part. We generally use the following bit of code (which can be placed in functions.php):

In this snippet, we’re doing two things:

  1. Defining a function, get_http_url( $url ), which converts any URL to HTTP.
  2. Creating a shortcode, [http-url], which outputs the HTTP version of the current post/page URL.

Note: We could have combined these into one simple shortcode, however I prefer separating each bit of functionality out into it’s own function, so that we can use them later if so desired.

2. Pass the HTTP URL to the plugin

Now that we can generate the HTTP version of a post/page URL, we need to basically tell our plugin to use this URL (always HTTP) instead of the auto-generated URL (HTTP or HTTPS). How we accomplish this varies from plugin to plugin, so we’ll outline the basic steps and then give two examples below.

The Steps

  1. Figure out how to inject your HTTP URL in place of the auto-generated URL used by your plugin. Good plugins will have a well-documented way to do this. Decent plugins will have a way to do this. Bad plugins will have neither a way to do this, nor documentation (if this is the case, time to switch plugins).
  2. Use the shortcode you created above to insert your HTTP URL.

Examples

We’ll look at two examples: Share Buttons by AddThis and Facebook Comments Box.

Example 1: Share Buttons by AddThis

Share Buttons by AddThis
By default, this plugin will automatically use the current post URL to send and retrieve associated share counts. Fortunately, this plugin falls into the “good” category, as it provides a simple method and clear documentation for overriding the default URL using the addthis:url attribute.

So, say we’ve created a text widget that displays our share buttons. Out of the box, the HTML looks like this:

If we want to ensure that our sharing buttons will always reference the HTTP version of a page’s URL, and likewise ensure that our share counts are the same regardless of which protocol we’re using to view the page, then we can easily use the addthis:url attribute along with our [http-url] shortcode like so:

NOTE: you’ll need to make sure shortcodes are enabled inside widgets, which you can do by adding add_filter('widget_text', 'do_shortcode'); to functions.php.

Presto! Our share counts are now the same whether we’re viewing HTTP or HTTPS.

Example 2: Facebook Comments Box

Facebook
This plugin is a little trickier, and falls somewhere between “good” and “decent”. The plugin does provide us with a handy filter, facebook_rel_canonical, however the documentation is pretty tough to track down. According to the plugin’s readme.txt file, the facebook_rel_canonical filter “affects Open Graph protocol URL definitions, URL references sent in Open Graph actions, and more.” Kind of obscure, but sounds like we’re in the right place.

So, whereas before we we’re simply outputting some custom HTML, this time we have to use WordPress’ native filters API to substitute our HTTP URL for the plugins default URL:

Just include this snippet in functions.php and you’re ready to go! Comments will now all be associated with the HTTP URL of any given post/page.

In Conclusion

While the details may vary depending on what plugin you’re using, the essential principals remain the same:

  1. Get the HTTP version of the current URL.
  2. Pass this URL to your plugin.

I find that sleuthing around different plugins to figure out how to pass in my custom URL is actually a pretty enjoyable (though sometimes time-consuming) task. I inevitably learn more about how the plugin works, and usually discover a handy trick or two along the way.

And if you run into a brick wall and just can’t figure it out, always feel free to file a support request or email the plugin author.

And if that fails, you can always contact us – we love a good challenge.

And if that fails. . . well. . . time to switch plugins :)