Facebook treats http://www.example.com the same as www.example.com and the same as example.com and http://example.com
However, https://www.example.com and https://example.com are different from the above.
If you have a site that has both http and https, going back and forth between protocols will kill your counts.
Solution:
function _service_links_get_tags($node, &$settings) {
//snip
$url = str_replace('https://', 'http://', $url); //Add this line
switch ($settings['short_links_use']) {
//snip
This forces the social media to all use the http url.
I experimented with removing the protocol all together, but google+ requires the protocol.
Comments
Comment #1
SolomonGifford commentedHere's a patch to add https support to service links.
Comment #2
nonsieI agree with everything but
This causes notices in IE if your whole site runs on https so there needs to be a setting of some sort instead of straight replace
Comment #3
SolomonGifford commentednonsie,
Can you please verify that the only difference is that line?
I have tested in IE7 and above and cannot reproduce. I suspect there is another issue on your site.
Note that the url is ONLY the url that is being sent to google/facebook/twitter for tally. It should not affect items being loaded on the page.
Solomon
Comment #4
nonsieThis happens in IE unless you have disabled mixed content warnings.
I've been using this patch (http://drupal.org/files/service_links_ie_ssl.patch) for couple of high traffic sites without any problems for 3 months now.
Comment #5
SolomonGifford commentedThere's something else going on with your page. Read my comments above.
Comment #6
SolomonGifford commentedI found one more bug with this.
needs to be changed to
Comment #7
wiifmRe-rolled #1 with the new --dev
This fixes all issues for me when running HTTPS.
Comment #8
wiifmAnother patch, this one includes the above patch, and also includes a change to the drupal_add_js() test for external links, it removes the strpos check for '://' and replaces it with '//'.
The patch is a lot larger due to my editor removing the trailing whitespace as well.
Comment #9
TheCrow commented#1524562: SSL for Twitter JS?
Comment #10
natukI am sorry for re-opening this, but I think that it should not have been closed in the first place. The issue mutated from this one:
to this one:
This issue: #1524562: SSL for Twitter JS? solves the second problem, but it does not solve the original one, I think - certainly not in my case.
EDIT: It appears that:
http://norhttps://then the correct count appears. Example: currently for FB the link is like this://www.facebook.com/plugins/like.php?href=http%3A//www.example.com/node/1&layout=button_count&show_faces=false&action=like&colorscheme=light&width=100&height=21&font=&locale=, which does not work if we switch to https. If this becomes://www.facebook.com/plugins/like.php?href=www.example.com/node/1&layout=button_count&show_faces=false&action=like&colorscheme=light&width=100&height=21&font=&locale=, then the counters work regardless of whether https is used.Comment #11
TheCrow commentedLet's try this patch
Comment #12
TheCrow commentedThe patch #11 is became critical for Facebook Like, without it the confirm link and the popup window neither show up.
Btw in my custom copy i reimplemented the iframe building it with javascript functions, any "Like" test on the home page project would be appreciated.
Comment #13
natuk#11 would work, but it does not because there is no string replace for https. For example in Facebook Like instead of:
var iframe_txt='<iframe src="' + $(this).attr('href').replace('http://', '//').replace('http%3A//', '') +we need something like:
var iframe_txt='<iframe src="' + $(this).attr('href').replace('http://', '//').replace('http%3A//', '').replace('https%3A//', '') +Comment #14
TheCrow commentedYou're right natuk! the same error is in the twitter patch...
This is another version using createElement() function for the iframe in FL, it should be readable than the string and the style is applied through jQuery so shouldn't be a problem for IE.
Comment #15
TheCrow commentedCommitted
Comment #17
yaelsho commentedHello,
I just upgrade to the last dev due to unresponsive facebook like button.
Post upgrade the widget still not working correctly.
When pressing on the like widget:
-The like count is increasing correctly.
-It does not open facebook like iFrame.
-When checking in facebook, the like action does not apear on my wall.
-I'm getting the followig browser error:
"Blocked a frame with origin "https://www.facebook.com" from accessing a frame with origin "https://apis.google.com". The frame requesting access set "document.domain" to "facebook.com", but the frame being accessed did not. Both must set "document.domain" to the same value to allow access."
"Blocked a frame with origin "https://www.facebook.com" from accessing a frame with origin "https://platform.twitter.com". The frame requesting access set "document.domain" to "facebook.com", the frame being accessed set it to "twitter.com". Both must set "document.domain" to the same value to allow access."
Any suggestions?
p.s- the rest of the widgets: google+1, twitter, linkedin are working good.
Thanks, Yael
Comment #18
TheCrow commented@yael may i see your webpage?
Comment #19
yaelsho commentedhttps://www.zorrolist.com
Thanks for checking, Yael
Comment #20
TheCrow commentedTried right now with Chromium and Firefox, both work fine for me: i liked the main page and it was registered among my "activities" instantly. The only reason you have troubles could be some anti-spy/ad-block/javascript-block addon installed in the browser (indeed it was not working with a browser profile where NoScript is installed).
The various javascript error you mentioned appear only for webkit based browsers and depends from some internal strict settings this webengine has while working with https and iframes, i can't do anything for that but they don't affect the normal behaviour of those widget services.
Comment #21
SilviuChingaru commentedThis no longer work after facebook july update. Check #2039431: Facebook like button for more details.
Also from Facebook Developer Roadmap:
So, in my opinion the only option left for us is to use only http:// url, or a better choise will be to let administrator decide what url to use http or https.
Comment #22
natukI think fiftyz has a point. I do not think we can avoid the problem with the counter being reset when changing from http to https. I guess it would be reasonable to have this as an admin setting, although I think defaulting to the current page protocol would be reasonable as well.
I suppose that one could override this in the template.php under preprocess_page where a conditional based on the date of the switch to https could be used to decide on whether to use https in the facebook url.
Also have a quick look here: #2018213: Facebook like widget not showing
Comment #23
TheCrow commentedLet's continue here, being a new trouble needs a new solution: #2039431: Facebook like button
Comment #24
alfarider commentedthere is no solution for this issue i have this bad error
in the iframe url this is bad url
http://www.facebook.com/plugins/like.php?href=sitename.com/