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.


function _service_links_get_tags($node, &$settings) {
$url = str_replace('https://', 'http://', $url); //Add this line
switch ($settings['short_links_use']) {

This forces the social media to all use the http url.

I experimented with removing the protocol all together, but google+ requires the protocol.


SolomonGifford’s picture

Here's a patch to add https support to service links.

nonsie’s picture

I agree with everything but

$url = str_replace('https://', 'http://', $url);

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
SolomonGifford’s picture


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.


nonsie’s picture

This 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.

SolomonGifford’s picture

There's something else going on with your page. Read my comments above.

SolomonGifford’s picture

I found one more bug with this.

  if (strpos($js, '://') !== FALSE) {

needs to be changed to
  if (strpos($js, '//') !== FALSE) {
wiifm’s picture

Status:Active» Needs review
new2.38 KB

Re-rolled #1 with the new --dev

This fixes all issues for me when running HTTPS.

wiifm’s picture

Another 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.

TheCrow’s picture

Status:Needs review» Closed (duplicate)
natuk’s picture

Status:Closed (duplicate)» Active

I 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:

When changing from http to https on a drupal website all social services counters are reset to 0

to this one:

Serving the social services widget javascript using http breaks the secure connection if the rest of the webpage is served as https.

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:

  • For facebook and twitter: If the link to the shared page in the iframes includes neither http:// nor https:// 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.
  • For linkedin the counters work anyway regardless of whether the page is served through https.
TheCrow’s picture

Status:Active» Needs review
new1.2 KB

Let's try this patch

TheCrow’s picture

Title:Facebook Incorrect like counts because http:// != https://» Facebook Like popup window doesn't show up
Priority:Major» Critical

The 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.

natuk’s picture

#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//', '') +

TheCrow’s picture

new2.35 KB

You'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.

TheCrow’s picture

Status:Needs review» Fixed


Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

yaelsho’s picture

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

TheCrow’s picture

@yael may i see your webpage?

yaelsho’s picture


Thanks for checking, Yael

TheCrow’s picture

Tried 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.

fiftyz’s picture

Status:Closed (fixed)» Active

This no longer work after facebook july update. Check #2039431: Facebook like button for more details.

Also from Facebook Developer Roadmap:

Social plugins will require an absolute URL in the 'href' parameter
Social plugins, such as the Like Box and Like Button, will require an absolute URL in the 'href' parameter.

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.

natuk’s picture

I 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

TheCrow’s picture

Status:Active» Closed (duplicate)

Let's continue here, being a new trouble needs a new solution: #2039431: Facebook like button

alfarider’s picture

Issue summary:View changes

there is no solution for this issue i have this bad error
in the iframe url this is bad url