I use a social media, sharing, or commenting plugin and it shows different data on HTTP and HTTPS versions of the same page/post.
Why Does This Happen?
We build a lot of sites that use social media sharing and commenting plugins, such as:
- Share Buttons by AddThis
- The list goes on and on. . .
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. . .
To solve this problem, we essentially have to do two things:
- Get the HTTP version of the current page/post URL.
- 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):
* Return HTTP version of a URL.
* @param string $url Original URL.
* @return string URL converted to HTTP.
* Output the HTTP version of the current post/page URL.
* @return string $url Current page/post URL converted to HTTP.
// Get current URL
// Get HTTP version of URL
In this snippet, we’re doing two things:
- Defining a function,
get_http_url( $url ), which converts any URL to HTTP.
- 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.
- 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).
- Use the shortcode you created above to insert your HTTP URL.
We’ll look at two examples: Share Buttons by AddThis and Facebook Comments Box.
Example 1: 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
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
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:
* Convert all Facebook Comment Box URLs to HTTP.
* @since 1.0.0
* @param string $href Current post URL.
* @return string URL converted to HTTP.
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.
While the details may vary depending on what plugin you’re using, the essential principals remain the same:
- Get the HTTP version of the current URL.
- 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 🙂