Remove emoji from core. PLEASE

[Online-marketing]

Hello,

I am afraid that unneccessary scripts like the emoji script just bloat the wordpress core.
For the sake of streamlining the core, please remove the emoji feature and - if you want it, offer a plugin in exchange. I think it would be a progress.

[jorbin]

Hi Online-marketing, welcome to trac.

The emoji script fixes browser display issues for emoji. Without it, emoji would just be displayed as an empty box and that is a horrid experience for readers. ​Testing has shown no change in page load/render time for browsers that don't need the polyfill.

If you aren't using emoji anywhere (including user comments) or prefer to provide a bad experience to some users, ​https://wordpress.org/plugins/disable-emojis/ is a plugin that will remove the script for you.

Closing as maybelater as the script will be removed one day, but we are likely years away from that happening. We need all browsers to completely support emoji and the usage share for browsers that don't support it to drop much closer to zero.

[SergeyBiryukov]

Previously: #32102

[Online-marketing]

Dear jorbin!

I sincerely appreciate having the end user in mind, when one designs a core framework. But on the other hand I would even more be grateful to developers who might give the publishers, who use the software on a daily basis the chance to not use so called user experience enhancements from the start without having to alter code or to install a plugin to not to.

Furthermore I would develop a plugin for those users, who really want to use Smileys, Emojis and whatever else they would want to implement. The goal is to slim down and not to bloat. Every unneccessary byte is a byte too much, especially if i have to install about 30 plugins to make my wordpress run in desired ways.

The core is called core, because it delivers the CORE functionality. And not so many extras. Every peace of not utterly neccessary code for a core functionality of a cms / blog system is one peace to many!

It would make not only my life a lot easier, if I didn't have to check my core system for new stuff, that I manually have to filter out with every update that wordpress gives me. - this does not only go for the emojis, but also for xmlrpc, wlwmanifest.xml and all the other "functions" that perhaps 1% of the hardcore users might use at best. Most of the users I know, don't even know these functions exist and are actually surprised, when I tell them.

What you are telling me just reminded me to a joke where one guy asks an other: "gee, man, why are you clapping in your hands all the time?" - "to scare away the elefants!" "but there ain't no elefants here!" "you see, it's working!"

[Online-marketing]

Dear jorbin!

I sincerely appreciate having the end user in mind, when one designs a core framework. But on the other hand I would even more be grateful to developers who might give the publishers, who use the software on a daily basis the chance to not use so called user experience enhancements from the start without having to alter code or to install a plugin to not to.

Furthermore I would develop a plugin for those users, who really want to use Smileys, Emojis and whatever else they would want to implement. The goal is to slim down and not to bloat. Every unneccessary byte is a byte too much, especially if i have to install about 30 plugins to make my wordpress run in desired ways.

The core is called core, because it delivers the CORE functionality. And not so many extras. Every peace of not utterly neccessary code for a core functionality of a cms / blog system is one peace to many!

It would make not only my life a lot easier, if I didn't have to check my core system for new stuff, that I manually have to filter out with every update that wordpress gives me. - this does not only go for the emojis, but also for xmlrpc, wlwmanifest.xml and all the other "functions" that perhaps 1% of the hardcore users might use at best. Most of the users I know, don't even know these functions exist and are actually surprised, when I tell them.

What you are telling me just reminded me to a joke where one guy asks an other: "gee, man, why are you clapping in your hands all the time?" - "to scare away the elefants!" "but there ain't no elefants here!" "you see, it's working!"

[DrewAPicture]

Replying to Online-marketing:

I sincerely appreciate having the end user in mind, when one designs a core framework. But on the other hand I would even more be grateful to developers who might give the publishers, who use the software on a daily basis the chance to not use so called user experience enhancements from the start without having to alter code or to install a plugin to not to.

Furthermore I would develop a plugin for those users, who really want to use Smileys, Emojis and whatever else they would want to implement. The goal is to slim down and not to bloat. Every unneccessary byte is a byte too much, especially if i have to install about 30 plugins to make my wordpress run in desired ways.

To be fair, utf8mb4 support covers far more than just emoji or smileys – it also covers displaying native character sets for languages like Chinese, Japanese, and Korean. I think it's safe to say that publishers worldwide benefit from wider language support in WordPress, so while some may not realize the immediate value, others absolutely do.

WordPress is currently ​translated for more than 150 locales around the world, and it's with that worldwide audience in mind that we extend language support wherever we can (within reason).

It seems to me that a basic tenet of content management would be to avoid placing unnecessary burdens on content creators by doing our best to display content as it's intended to be displayed. The shims that exist in core WordPress are extending an olive branch to browsers that don't support modern language standards – it's not bloat, it's basic language support.

I'm re-closing the ticket as maybelater. Tickets do not need to remain open for discussion to continue.

[superpoincare]

I am not sure if this is done responsibly.

I did some experimentation.

When I disable emojis and move all external js to footer and even load external styles asynchronously with some above the fold css inlined - except Google Fonts - I observe is that fonts are fetched immediately after Google fonts css is downloaded.

On the other hand, if I don't disable emojis, both the initial fetch of Google Fonts css and the subsequent fetch of fonts are delayed. Both.

This I tested on Browserstack on OSX on Chrome and Safari.

[superpoincare]

Going to open a new ticket, as the title of this ticket is not what I wish.

[lukecavanagh]

You can disable emoji from loading on the front-end etc using this in a code snippets plugins, site specific plugin or the functions.php of the active theme.

/**
 * Disable the emoji's
 */
function disable_emojis() {
	remove_action( 'wp_head', 'print_emoji_detection_script', 7 );
	remove_action( 'admin_print_scripts', 'print_emoji_detection_script' );
	remove_action( 'wp_print_styles', 'print_emoji_styles' );
	remove_action( 'admin_print_styles', 'print_emoji_styles' );	
	remove_filter( 'the_content_feed', 'wp_staticize_emoji' );
	remove_filter( 'comment_text_rss', 'wp_staticize_emoji' );	
	remove_filter( 'wp_mail', 'wp_staticize_emoji_for_email' );
	add_filter( 'tiny_mce_plugins', 'disable_emojis_tinymce' );
}
add_action( 'init', 'disable_emojis' );

/**
 * Filter function used to remove the tinymce emoji plugin.
 * 
 * @param    array  $plugins  
 * @return   array             Difference betwen the two arrays
 */
function disable_emojis_tinymce( $plugins ) {
	if ( is_array( $plugins ) ) {
		return array_diff( $plugins, array( 'wpemoji' ) );
	} else {
		return array();
	}
}