Future about embeds and emojis

Neither embeds nor emojis are affected by the GDPR or DSGVO. People are reading these laws in too paranoid a manner and making assumptions that are untrue.

You are free to not use embeds or emojis if you wish, but there’s no legal obligation for you to do so.

As for the emojis, the included code that references the w.org CDN is a fallback for older browsers only. Newer browsers have emoji support built into them, and thus do not use that code. Emojis are already supported by core in this respect.

Emojis is easy to solve, if I understand what the issue is.

Emojis are served from w.s.org which includes trackers, but it’s actually pretty dumb to serve them that way because it results in additional http requests when virtually every modern browser has color emoji libraries.

Unfortunately WordPress makes no attempt to determine if the browser is capable of of its own emojis, it uses the w.s.org emojis even with modern browsers, but there is a solution.

You can use https://www.ads-software.com/plugins/disable-emojis/ and instead of using the remote svg emojis the browser will use it’s own emoji – thus zero tracking issues *and* fewer http requests.

Emojis are served from w.s.org which includes trackers, but it’s actually pretty dumb to serve them that way because it results in additional http requests when virtually every modern browser has color emoji libraries.

Actually, WordPress includes a browser detection script. If the emojis are supported by the browser, then it does not get them from s.w.org (which is our CDN). It only uses those image files as a fallback when the browser can’t show them. Also, the CDN does not “include trackers”. It sends image files, not javascript.

Unfortunately WordPress makes no attempt to determine if the browser is capable of of its own emojis

See, it does, actually. The script is called “wp-emoji-release.min.js”, and it’s compiled from three other scripts, which are wp-emoji.js, twemoji.js, and wp-emoji-loader.js. You can find all of these in the /wp-includes/js/ folder.

I would recommend looking at wp-emoji-loader.js specifically, as that shows the tests that it runs to determine support in the browser. While all modern browsers have some level of support, the level of support varies greatly, and so fallbacks like these are still often needed.

The detection script doesn’t work then. At least not for emoticons (where it translate ; ) to a wink and : D to a big grin).

Standard latest version FireFox on 64 bit linux – it uses s.w.org for emoticons. When I use the plugin to disable s.w.org – then browser emojis are used for emoticons.

I should note I had the same experience with Chromium on Linux – it also used s.w.org for emoticons even though there’s an emoji font that provides them just fine, and did so once I installed the plugin that disables emojis.

I suppose it is possible the scripts are testing for specific emojis not natively supported by firefox and chromium (for chromium on Linux it seems to use a combination of Symbola falling back to DejaVu when Symbola doesn’t have it. FireFox ships with its own color emoji font and falls back to Symbola when their color emoji font doesn’t have it)

• This reply was modified 6 years, 7 months ago by alicewondermiscreations.

You can read the script yourself, but yes, Firefox is broken on pretty much all non-Windows systems. When they fix that, then it won’t be needed to use a fallback.

FireFox isn’t broken on Linux, emojis work just fine in it.

Well there are other issues with FireFox, but the emojis work.

I guess what I’m saying is when the fallback scripts are only there for a minority of browsers that don’t have native emoji support, result in tracking cookies and additional http requests, and also incorrectly identifies systems that actually don’t need the fallback – KISS dictates the removal of the fallback scripts.

It’s kind of funny.

Twice I have recommended features that are not eye candy and needed in core – ability to build a webfont string that allows the sysadmin to specify the server, and a PSR-4 autoloader – and have been told that belong as plugins and not in core even though they really need to be in core because of script load issues.

But a purely eye candy feature like emoji fallback that would work just fine as a plugin, that’s in core.

I don’t understand.

• This reply was modified 6 years, 7 months ago by alicewondermiscreations.

There aren’t any tracking cookies. The CDN at s.w.org doesn’t send any cookies. It’s a CDN. It has no tracking scripts. It’s serving images, not scripts. This isn’t that complicated.