Emoji Javascript doesn't support HTTPS

[trenzterra]

My WordPress site is running on SSL courtesy of CloudFlare's Flexible SSL feature.

For some reason, however, the emoji javascript code that is added to each page assumes that your site URL starts with http and does not support https. I have already changed my site URL to start with ​https:// but it seems the emoji code does not detect this.

The javascript I'm referring to is this:

<script type="text/javascript">
			window._wpemojiSettings = {"baseUrl":"http:\/\/s.w.org\/images\/core\/emoji\/72x72\/","ext":".png","source":{"concatemoji":"http:\/\/www.websiteurl.com\/wp-includes\/js\/wp-emoji-release.min.js?ver=4.3"}};
			!function(a,b,c){function d(a){var c=b.createElement("canvas"),d=c.getContext&&c.getContext("2d");return d&&d.fillText?(d.textBaseline="top",d.font="600 32px Arial","flag"===a?(d.fillText(String.fromCharCode(55356,56812,55356,56807),0,0),c.toDataURL().length>3e3):(d.fillText(String.fromCharCode(55357,56835),0,0),0!==d.getImageData(16,16,1,1).data[0])):!1}function e(a){var c=b.createElement("script");c.src=a,c.type="text/javascript",b.getElementsByTagName("head")[0].appendChild(c)}var f,g;c.supports={simple:d("simple"),flag:d("flag")},c.DOMReady=!1,c.readyCallback=function(){c.DOMReady=!0},c.supports.simple&&c.supports.flag||(g=function(){c.readyCallback()},b.addEventListener?(b.addEventListener("DOMContentLoaded",g,!1),a.addEventListener("load",g,!1)):(a.attachEvent("onload",g),b.attachEvent("onreadystatechange",function(){"complete"===b.readyState&&c.readyCallback()})),f=c.source||{},f.concatemoji?e(f.concatemoji):f.wpemoji&&f.twemoji&&(e(f.twemoji),e(f.wpemoji)))}(window,document,window._wpemojiSettings);
		</script>

[stanquinn]

this exact same thing is happening to me right now.

[killerbishop]

Tested switching over to SSL and this appears to work as expected. The basis of SSL or not in the format of the URL boils down to the is_ssl() function which requires $_SERVER['HTTPS'] to be present with a value of either on or 1 - the other option is existence of $_SERVER['SERVER_PORT'] set to a value of 443. @stanquinn and OP - I would say this is likely where your problem may be. You can probably confirm if these apply in your environment by outputting the values.

[markparnell]

When using Cloudflare's "flexible" setting, the end user accesses the site over HTTPS (their connection to Cloudflare is secure) but the connection between Cloudflare and the server is loaded over HTTP. This is necessary if the server doesn't have any sort of certificate installed (though even a self-signed or expired certificate is sufficient to switch Cloudflare to "full" instead).

As such the is_ssl() check is going to report that SSL is not being used as that's what the server sees in the request from Cloudflare, even though the end user's connection is secure.

It should be quite simple to resolve this by removing the http[s]: prefix from the URL since a URL starting with // will use the same protocol as the page itself - and since that happens on the browser side of things it won't be affected by the difference at the server. Then we could avoid the is_ssl() check altogether.

I wonder too whether this has wider ramifications for is_ssl() elsewhere?

[desrosj]

This looks like it was fixed as apart of #35376 in [36249] and was shipped as a part of version 4.4.2. Since then, the Emoji related URLs have been using https at all times.

Though this ticket was created first, I am going to close this out as a duplicate since a fix was already committed.