ClassicPress PetitionsClassicPress Petitions
This is a read-only archive. Post or comment on the live version of this page on our forums.

Remove Emojis (GDPR friendly)

September 7, 2018 · 15:00 · ribeiroeder
Description

Removes the extra code bloat used to add support for emoji’s in older browsers

Planned James Nylen

Our roadmap for v2 is to move features into "core plugins" that can be disabled or deleted as needed: https://www.classicpress.net/roadmap/

Emoji support is a great candidate for this effort. We need to build a plugin directory first though.

Voters
+120 more
Tags
Request: Modify feature
Request: Remove feature
Discussion
KTS915

Agreed. This means that we should enable STRICT_ALL_TABLES in MySQL because the fact that WP does not do this is what led to the insertion of emojis in the first place (apparently as some sort of cover for adding esoteric security).

James Nylen

I think this proposal and STRICT_ALL_TABLES are two separate issues.

I am not in favor of this one. On my computer one of the only places I get nice-looking emoji rendering is on WP sites, because I'm running a version of Linux which does not have support for this by default.

Also, what is the connection to GDPR here?

Wade Striebel
Dora D.

@James Nylen: Embedding emoji-images (or any other data) from external servers like s.w.org without notice and approval to/by the user voids GDPR, it allows tracking of users via their IP address (IP address is considered personal data in GDPR).

James Nylen

The possibility of tracking is not enough to void GDPR. It depends on what the server actually does with the IP addresses.

Dora D.

@James Nylen: That's why you have to notify the user and tell him/her what exactly does or does not happen with the IP and have them approve it. And to be able to know what happens, you need detailed information from the external server provider.

Do you know what exactly s.w.org does with the IP addresses collected from the emoji images server? GDPR requires a full postal address and a named contact person for these requests. None of this exists at wordpress.org

James Nylen

Yep, I definitely agree we can do better there. Probably the easiest option for now would be to serve the emoji images from the individual site directly.

My overall point with jumping into this discussion is that the emoji feature was introduced for good reasons: not all platforms support emoji display, and they don't display consistently on the platforms that do support them. Something we should consider before deciding to remove it.

Dora D.

Agree. Serving emoji images from local site would be fine in terms of GDPR.

invisnet

I think emojis are another candidate for being moved to a core plugin.

Pieter Bos

I thought that emojis where a "mere" by-product of allowing multibyte characters or something like that?

James Nylen

I think we are talking about two different things here. One is multi-byte character storage in the database (which was obfuscated and conflated with emoji support) and the other is emoji support in the front-end.

I don't think we should remove front-end emoji support, but adding an option to disable it would certainly be fine.

I don't know enough about the multi-byte character storage issue to have an opinion yet.

Avrom

@KTS915 covered the issue in his first comment.

I don't like the why the Emojis bloat my source code in the first place. Yes I'd like to see it removed from core, but maybe as an optional ClassicPress plugin (and eventually a well controlled plugin under a ClassicPress library).

Daniele Scasciafratte

I don't agree too.
People with various browsers that not support them will have issues because there is no alert and will complain about wrong rendering to the webites owners and later to us as project.
There is https://wordpress.org/plugins/disable-emojis/ that remove that and for gdpr remove only the autofetch of the dns.
Maybe we can plan instead of a plugin to add a constant for wp-config that disable them.

For gdpr we can do another constant that globally change this behaviour also in other stuff (if there are).

Neal Umphred

Remove.

Chris Chiotis

Definitely I am pro on removing them and have them as a side plugin

John

I've been getting into emojis more lately, but feel they're plugin territory.

Pieter Bos

I'm also for removing and make them available as a plugin for people that want to use ClassicPress as a blog (assuming that most company sites don't need funny faces).

Pedro de Carvalho

+1 on moving it to plugin land.

Ashley Goodman

Plugin

Greg Schoppe

Emojis should definitely be plugin-land. Emojis are nice and cool and I'd love to be able to install a plugin and use them in a GDPR-friendly way, but they have no right to bloat business installs and run random javascript on the front end, and they certainly shouldn't be pinging random servers (ironic, given wordpress's general fear of CDN integration for things like JQuery).

Glenn Tate

Emoji added as security flaw update ...

https://poststatus.com/the-trojan-emoji/

Peter B

We are talking about the fact, that you can protect the database even without showing fancy smileys on the front-end even if a business site simply does not need poop emojis or whatsoever (with extra code that has nothing to do with security to render those smileys).
Maybe if the Fart Co still needs those emojis...well in that case they can install a plugin for that purpose.

Greg Schoppe

@Peter B, there are plenty of legitimate businesses that use emojis in their marketing. There is no need to belittle those that find this feature useful, just to communicate that you don't.

The important question is not "Are emojis 'professional'?", it's "Do emojis belong in core?". To my mind the answer is no.

As long as we maintain utf8_mb4 support, we retain the security 'fix', and if we simply render the emojis in the system font, by default, we have a reasonable level of core functionality.

Those people who want to use a standard cross-platform emoji icon-set are wanting a very specific feature set that fundamentally goes beyond what emojis are designed to be. Emojis are designed to trigger device-specific rendering. So, it seems beyond the base level of support to offer a custom wordpress emoji glyph-set, and it also seems counter to the web-standards-first approach to features that I would prefer to see in CP.

All that said, it would obviously be useful as a well-supported core-maintained plugin, similar to the direction I imagine we will eventually want to take with embeds.

Glenn Tate

When speaking of bloat I'd like to know how much code is involved and if it actually impacts the speed of the site.

Greg Schoppe

WP emoji support adds two kilobytes of additional javascript in the head of every page, and an additional four kilobytes of minified JS that gets loaded asynchronously.

In addition, it parses the entire page on every change of ready state to look for any emoji characters, and rather than rendering them using the system font or a default browser implementation (as intended for emojis), it makes an external call to an address at s.w.org to pull in image files.

s.w.org is wordpress.org's CDN, so there is also some concern over the privacy/GDPR impact of making requests to an external server whose privacy policy is not available to the site admin or the general public, as well as concern for having features of CP that rely on the WP website to function.

James Nylen

> WP emoji support adds two kilobytes of additional javascript in the head of every page, and an additional four kilobytes of minified JS that gets loaded asynchronously.

It also has its hooks into the grunt-based build process. If I recall correctly, it scans every source file looking for a regex which appears in one single file, and does a replacement. Not a huge problem but it would be good to get rid of this too.

> s.w.org is wordpress.org's CDN, so there is also some concern over the privacy/GDPR impact of making requests to an external server whose privacy policy is not available to the site admin or the general public, as well as concern for having features of CP that rely on the WP website to function.

We are planning to remove this callout and host emoji locally for v1. We have started, and planned an approach that we think will work, but there is still a good bit left to do: https://github.com/ClassicPress/ClassicPress/pull/212

After v1, the front-end emoji features would be a good candidate to move out into a core plugin.

Daniel Hendricks

I don't know if the GDPR is the best argument for this topic (though admittedly valid) since, let's be honest, it is almost impossible to be fully compliant (and "compliance" is very subjective anyway; ask any attorney).

That said, I think it should be a checkbox in Settings, disabled by default. I have seen significantly more sites that do not use or have no use for emojis than those that do, yet nearly all of them have the useless extra code in the page head. You can slap some GDPR help text on the checkbox, as desired.

However, I certainly wouldn't complain if it was removed entirely. That sort of rubbish should be added by a plugin, not be part of core. WordPress has some notable missing elements/issues (host header injection, anyone?), yet they decided that shoving emoji down everyones pipe was important. 0_o

Alan Coggins

I would not miss emojis at all. Happy to have them removed, or enabled by checkbox in Settings as mentioned above.

James Nylen

Since I last commented here, we've published our roadmap for version 2, in which lesser-used or less-wanted features will be moved out into "core plugins" that are enabled by default but can be disabled or deleted entirely. You can read more here: https://www.classicpress.net/roadmap/

This is currently the top petition by number of votes ( https://petitions.classicpress.net/?view=most-wanted ), so it seems like a good place to start, and I'm marking this petition as Planned. We "just" have to build a plugin directory first.

Avrom

The Plugin Directory will take a long time to fully develop. Getting rid of built-in Emoji's would be far less work and a faster timeline to accomplish IMO. As others mentioned, a checkbox and disabled by default would be great.