Count shares from both http and https URLs

[dreamwhisper]

From previous conversations related to share counts when switching from http to https, simple share could include both in the total count.

[nickcernis]

Noting the Facebook API supports multiple URLs in a single request:

https://api.facebook.com/method/links.getStats?urls=http://example.com,https://example.com&format=json

It's increasingly common for users to move to HTTPS and lose their share counts, so we're still asked about this. For example: https://wordpress.org/support/topic/facebook-share-cont-lost-after-migration-to-https?replies=2#post-8714649

[NicktheGeek]

Instead of pulling both, the simpler solution will be to specify one or the other. However, I'll see if there is a way to make it work with both because more and more sites will have to make this switch.

[NicktheGeek]

Genesis Simple Share

[nickcernis]

@NicktheGeek The Facebook badge counts HTTP URLs for HTTPS pages after this change. This could reset counts to zero on sites that have always served posts over HTTPS, so I'm not sure it's right.

Tested by:

1. Visiting a post where the Facebook badge is visible.
2. Adding this code to functions.php:

   add_filter( 'post_link', 'fake_permalink' );
   add_filter( 'page_link', 'fake_permalink' );
   function fake_permalink( $permalink ) {
       return 'https://example.com';
   }

3. Refreshing the page.

Expected to see:

• Combined share count from https://graph.facebook.com/?id=https://example.com and https://graph.facebook.com/?id=http://example.com.

Actually see:

• Share count from the HTTP version only.

[NicktheGeek]

This is interesting. Originally I had it serving the combined values, but then I was seeing double values because it seemed Facebook was serving the combined count so I made it not use that. Now it seems they are doing the count segregated again.

[NicktheGeek]

curious, it seems if FB doesn't have both http and https for a given url it returns what they do have. https://graph.facebook.com/?id=https://www.copyblogger.com/do-not-read-this-post-or-the-kitten-gets-it/ https://graph.facebook.com/?id=http://www.copyblogger.com/do-not-read-this-post-or-the-kitten-gets-it/

Both are showing 131 shares, but there is no way that is correct. That post almost certainly only has http shares.

[NicktheGeek]

@nickcernis ok, I've updated the release branch. I'm not sure the best way to make this value accurate since FB apparently will use the https or http share if there isn't both so that some URLs would get a double share count. I opted to check if the count values are exactly the same. If they are it only uses the first value. There will likely be real world scenarios where the http and https values are identical so only one or the other will be used but that is no worse that the current solution where one or the other is used and by and large most share URLs will have different values if there is data for each. I think that is the only reasonable solution I can come up with short of throwing the whole thing out.

[nickcernis]

Thanks, @NicktheGeek. I'm still seeing 21.40M (the HTTP total) for https://example.com instead of the combined HTTP + HTTPS total (~21.45M):

I'm not sure it's our fault, though. I spotted this in the comments when the Jetpack team tried to solve the same issue:

Facebook protocol summing has been shown to falsely double counts, so we only request the current URL.

Ref: https://github.com/Automattic/jetpack/blob/007b10ce27f828737f681a06d83ff8393cd5b20a/modules/sharedaddy/sharing.js#L33

So perhaps the counts from FB can't be relied upon, and using the current URL is the best approach after all. Sorry for the pain this caused!

Edited to add: using the larger value of the two seems fine if it will prevent doubling. Setting as confirmed.

[NicktheGeek]

@nickcernis I would try a different example URL. The rounding could be getting thrown off.

Also, might be worth making sure your scripts are updated and pulling from the right branch. I'm getting a different value.

[nickcernis]

Thanks — looks good for other URLs.