WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 3 years ago

#32102 closed enhancement (wontfix)

Emoji - only load when required

Reported by: ChriCo Owned by:
Milestone: Priority: normal
Severity: major Version: 4.2
Component: Formatting Keywords: close
Focuses: Cc:
PR Number:

Description

With the new 4.2-Release, the Emoji-Inline JavaScript and CSS are always loaded. But the Emoji-Replacement makes only sense, when we have the Option use_smiles are activated.

We should add the check for use_smiles similar to the convert_smilies()-function

Attachments (1)

32102.patch (852 bytes) - added by ChriCo 4 years ago.
added check for use_smiles and wp_smiliessearch

Download all attachments as: .zip

Change History (27)

@ChriCo
4 years ago

added check for use_smiles and wp_smiliessearch

#1 @SergeyBiryukov
4 years ago

#32080 was marked as a duplicate.

#2 @ocean90
4 years ago

Since Emoji are no (or not always) smilies I disagree with this suggestion. There is a lot of more happing for Emoji, not just the inline scripts.

#3 @ChriCo
4 years ago

  • Version set to 4.2

@ocean90 thanks for your response. Maybe we can add some add_theme_support( 'emoji' ); which gives us the possibility to activate / deactivate the whole "emoji"-process?

#4 @pento
4 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed
  • Version 4.2 deleted

Per the discussion on this post, it's not appropriate to tie the emoji compatibility layer to smilies. If you want to disable it, there are plugins available for that.

#5 @ChriCo
4 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Version set to 4.2

@pento
Yep thats true, but not everyone wants/needs Emoji and/or wants the additional load of these inline Script and Style in his site. Installing a Plugin to remove something from WordPress isn't always the best solution.

Why isn't it possbile to add (or at least discuss) the add_theme_support( 'emoji' ); or an option for this? I would understand, if you argue with the "Decisions not Options"-think, but in Backend you've also the option for use_smiles which should be removed and can be "easily" replaced by another Plugin to control this.
Additonal we have some "features" which are controlled by add_theme_support(). Seems like a big inconsistency for me, when which "rule" (option in backend, theme-support, decission from WP for everyone, something else) is used.

Last edited 4 years ago by ChriCo (previous) (diff)

#6 @Monika
4 years ago

@pento
If I deactivate Emoji my old smilies are broken. "it's sink or swim" :(

#7 @SergeyBiryukov
4 years ago

  • Milestone set to Awaiting Review

#8 @SergeyBiryukov
4 years ago

#32140 was marked as a duplicate.

#9 @XgoikenX
4 years ago

Why should the default behaviour practically overwrite explicit user input?

#10 follow-up: @pento
4 years ago

Why isn't it possbile to add (or at least discuss) the add_theme_support( 'emoji' ); or an option for this?

add_theme_support() (like wp-admin options) are kind of a cop-out from our perspective. Either the code is good enough to be enabled by default, or it needs more work. The emoji script has no effect on your Page Speed score, and the actual running time will be a few ms: 1 or 2 clock ticks in Chrome.

but in Backend you've also the option for use_smiles which should be removed

You're absolutely right. Smilies are deprecated by emoji, and this option should be removed in the future. Historically, we've disabled deprecated options on new installs only, so that's probably what will happen to it.

If I deactivate Emoji my old smilies are broken. "it's sink or swim" :(

If you'd like to deactivate emoji but retain the old smilies, here's a plugin to do that for you.

Why should the default behaviour practically overwrite explicit user input?

The default behaviour is to only provide emoji compatibility in browsers that either lack emoji support (IE on Windows Vista or earlier, Chrome on Windows), or have bugs in their emoji rendering (Firefox, Chrome on OS X). This isn't overwriting user input, it's simply rendering characters that otherwise wouldn't be rendered.

#11 @XgoikenX
4 years ago

This isn't overwriting user input, it's simply rendering characters that otherwise wouldn't be rendered.

Of course it overwrite’s the user's input, because in many cases FF and Chrome would render emoji perfectly fine. Why else would the user use them, if they wouldn’t work for her? Also by that argument you’d have to differentiate by the emoji, that is actually used and not replace them all in one sweep.

And in any case the design that is imported doesn’t match the original one. It even adds color where none is given originally.

#12 @pento
4 years ago

In the case of Firefox, we do only replace the emoji that don't render correctly - Firefox doesn't support flag emoji, so we only replace the flag emoji characters.

In the case of Chrome OS X, it doesn't render emoji within elements with a font-weight higher than 500. There's no fast method to detect if the current element is rendering bold text, and it'd be weird if emoji were used multiple times on a page, but only some of them were replaced. So, we chose speed and consistency over native rendering.

In both of these cases, the emoji compatibility layer will automatically disable itself when Firefox and Chrome fix their rendering issues.

And in any case the design that is imported doesn’t match the original one. It even adds color where none is given originally.

There's no such thing as "original" emoji. Emoji vary by the platform they're being displayed on, not by the platform they were typed on. The important part is that they convey the same emotion.

#13 in reply to: ↑ 10 @Monika
4 years ago

Replying to pento:

but in Backend you've also the option for use_smiles which should be removed

You're absolutely right. Smilies are deprecated by emoji, and this option should be removed in the future. Historically, we've disabled deprecated options on new installs only, so that's probably what will happen to it.

Emojis are not smilies, but many people don't know the difference, so they believe that they have disabled emojis too if they have disabled smilies. And there is no information on old installs.

And for me, I have never thought that emojis will kill smilies :(

#14 follow-ups: @XgoikenX
4 years ago

In the case of Firefox, we do only replace the emoji that don't render correctly - Firefox doesn't support flag emoji, so we only replace the flag emoji characters.

There's no such thing as "original" emoji. Emoji vary by the platform they're being displayed on, not by the platform they were typed on. The important part is that they convey the same emotion.

http://bradschetl.org/example.png Maybe an example helps (both viewed in FF). Upper part is after 4.2 and below is before 4.2 / after adjusting filters. I hope this illustrates that replacement should at the very least respect the color choice (black in my case).

One more argument: current practice is a privacy concern for users, because it shares requests with an unexpected third party.

#15 in reply to: ↑ 14 @michaelkallweitt
4 years ago

  • Severity changed from normal to major

Replying to XgoikenX:

One more argument: current practice is a privacy concern for users, because it shares requests with an unexpected third party.

Thanks for pointing this out. It's something I haven't been aware of.

Guys, this is a serious issue especially for site owners in the EU, as we're not allowed to transfer personal data to third parties without a user's prior consent. By making such a change, you are putting a number of your users in legal trouble!

Please fix this ASAP or, at least, provide a workaround!

#16 @dunkelangst
4 years ago

I use WordPress since version 2.2 (2007) and WordPress 4.2 is annoying me the first time!

Emojis are no Smilies! I want to switch the ridiculous emojis off! I also have never thought that emojis will kill smilies :(

#17 @SergeyBiryukov
4 years ago

#32206 was marked as a duplicate.

#18 in reply to: ↑ 14 @marsjaninzmarsa
4 years ago

Replying to XgoikenX:

Upper part is after 4.2 and below is before 4.2 / after adjusting filters. I hope this illustrates that replacement should at the very least respect the color choice (black in my case).

But:

There's no such thing as "original" emoji. Emoji vary by the platform they're being displayed on, not by the platform they were typed on. The important part is that they convey the same emotion.

Pre 4.2 doesn't respects either. Behavior on modern platforms (Win 8+, OS X, mobiles) is rendering Emojis in color.

#19 @Howdy_McGee
4 years ago

It really should be up to the user whether they would like to use Emojiis, not forced upon. Preferably adding this setting under Settings -> Writing.

#20 @mikt
4 years ago

There should be a setting to disable it - why is there a need to modify functions.php or use a plugin to do so?
I dont' get the reason behind that. If you like emojis (i suppose noone NEEDS them anyways) - fine, but the majority most probably would not want to use it.

#21 @kraftbj
4 years ago

  • Keywords close added

This conversation between faevilangle and pento sums up the argument well: https://wordpress.slack.com/archives/core/p1430386777008874

One more argument: current practice is a privacy concern for users, because it shares requests with an unexpected third party.

There isn't a privacy concern. Your local browser, through JS, determines if it can render emoji natively or not. If not, it requests a static JS file to provide the compatibility layer. No data is shared with any third-party. If the usage of the w.org CDN to provide the emoji graphics is a concern, there is a filter to allow you to download an emoji image set and use that locally instead. The privacy concern is exactly the same as using a CDN to bring in jQuery instead of hosting it locally.

As the smiley option has been removed for new installs, the philosophy of Decisions, Not Options, the existence of plugins/filters to disable/modify behavior, I suggest closing this ticket as wontfix.

#22 follow-up: @Ov3rfly
4 years ago

The "void privacy policy" is a totally valid point (as soon as only one emoji graphic is fetched from third party CDN). Clients asked questions if their site was hacked after 4.2 update when they saw the script and external baseUrl. WordPress out of the box before 4.2 came without any CDN use and was safe to recommend in terms of privacy.

After talking to many WordPress devs it appears the main problems with the emoji feature are:

  • Adds unwanted script and css to each and every page (this was mentioned most)
  • In core
  • On by default
  • No switch to disable
  • Funtionality will never be used in 99% of CMS scenarios
  • You need an extra plugin like this to get rid of it

WordPress is not a blog for a few lolcat images any more, it is often used as fully featured CMS and in this context a stable and lean core is required. Any playground toys like emojis and funny icons should live in plugin world, but never in core.

Side note, a little OT: Seems adding functionality to core instead of providing them as a plugin has become a new trend, see also discussions about customizer, also a funny toy for "one page blogs" but completely useless for company CMS sites with a dozen different multilingual menus and widgets in sidebars for different site areas...

Last edited 4 years ago by Ov3rfly (previous) (diff)

#23 in reply to: ↑ 22 @Monika
4 years ago

Replying to Ov3rfly:

The "void privacy policy" is a totally valid point (as soon as only one emoji graphic is fetched from third party CDN). Clients asked questions if their site was hacked after 4.2 update when they saw the script and external baseUrl. WordPress out of the box before 4.2 came without any CDN use and was safe to recommend in terms of privacy.

After talking to many WordPress devs it appears the main problems with the emoji feature are:

  • Adds unwanted script and css to each and every page (this was mentioned most)
  • In core
  • On by default
  • No switch to disable
  • Funtionality will never be used in 99% of CMS scenarios
  • You need an extra plugin like this to get rid of it

WordPress is not a blog for a few lolcat images any more, it is often used as fully featured CMS and in this context a stable and lean core is required. Any playground toys like emojis and funny icons should live in plugin world, but never in core.

Side note, a little OT: Seems adding functionality to core instead of providing them as a plugin has become a new trend, see also discussions about customizer, also a funny toy for "one page blogs" but completely useless for company CMS sites with a dozen different multilingual menus and widgets in sidebars for different site areas...

yes I agree 1000%
most of my customers can't understand why a toy must be a core feature.

#24 @pento
4 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from reopened to closed

With regards to the privacy issue, there's now a plugin to use locally hosted emoji images, instead of from the w.org CDN:

https://wordpress.org/plugins/wp-local-emoji/

While I appreciate that not everyone agrees with the decision to include emoji support in core, we don't intend to remove it or provide UI disable it. Instead, I recommend you use the various plugins linked to in this ticket to disable it or alter the behaviour to your liking.

#25 @Cybr
4 years ago

With regards to many users asking for an option to enable or disable emoji's I've created a plugin which does exactly that thing. It's not page/post specific (yet), but it can be coded to include that way.

https://wordpress.org/plugins/emoji-settings/

Please consider. Thanks!

#26 @pento
3 years ago

#38252 was marked as a duplicate.

Note: See TracTickets for help on using tickets.