Uncategorized WordPress

Don’t on Emoji in WordPress 4.2

WordPress 4.2 is almost here.  Yesterday marked the release of Beta 4 and if everything goes as planned, the first RC will be available next week. One of the
“features” that people are talking about in both positive and negative terms in emoji support. I put feature in quotation marks because really, emoji support is a bug fix.

The mission of WordPress is to democratize publishing.  WordPress aims to be usable by anyone, anywhere.  Part of this means to be usable in any language.  To help accomplish this, WordPress 4.2 is changing it’s tables to use utf8mb4 by default. Gary Pendergast summed up why this change was needed

In Unicode terms, utf8 can only store characters in the Basic Multilingual Plane, while utf8mb4 can store any Unicode character. This greatly expands the language usability of WordPress, especially in countries that use Han character sets. Unicode isn’t without its problems, but it’s the best option available.

In addition to supporting more character sets, utf8mb4 also supports emoji.  The problem is that browsers don’t always support emoji correctly. In another post on the Make WordPress Core blog, Gary describes these problems:

  • Some browsers don’t know how to render emoji , or they have bugs in their implementation . Notably, Chrome either doesn’t work or has bugs, older versions of IE don’t work, and Firefox has bugs.
  • Not all sites will be able to upgrade to utf8mb4, which means they’ll be unable to save emoji characters that they enter.

Not being able to use emoji makes everyone a sad panda (), so we need to fix this.

Fixing WordPress to work in more languages exposes emoji. Since emoji support isn’t great yet, WordPress needs to shim it. Most users won’t understand why their site works in some browsers but not others. Some people find emoji annoying. Others find them fun. But as of WordPress 4.2, we all can at least find them.


10 replies on “Don’t on Emoji in WordPress 4.2”

Someone deleted my comment.
The long and the short is that emojis should not be in core. They are classic plugin territory. We need to stop shoving stuff that only minority will use into core (it’s already bloated enough)

We’re using wordpress as a CMS for websites that don’t have comments enabled, and that don’t use emoticons in any of their content.

I know there are a lot of sites out there using wordpress that will be in the same situation (wordpress have pushed development to make it more than just a blogging platform over the years of course).

For such sites adding emoji support to the core in the way it has been is more of a hindrance than a help as it’s downloading code (whether asynchronously or not doesn’t matter) that isn’t needed.

Or am I missing something?

In the scenario I describe above, it’s a hindrance in the sense that it’s downloading front end code and injecting css into the head without asking first. Which then requires the installation of a plugin or theme change to stop happening.

Whether it does this asynchronously and without a significant performance penalty is irrelevant. Its almost always bad practice to download and execute code that serves no purpose (and that will be the case for many thousands of sites using wordpress as a CMS that don’t use emojis or allow comments).

I’ve disabled it on our sites already using the same method that plugin uses (only takes a few lines so admittedly not exactly the end of the world).

But I find it difficult to disagree with those who say it shouldn’t be part of the core and would have been better as a plugin. That would keep the core cleaner/less bloated and be less of a surprise for site maintainers who will never use this feature.

I’ve read the article that you reference, and I posted my comment there too at the same time I made my comment here, but I didn’t get a reply yet. I’m not sure if my comment was approved yet so if you didn’t see it that may explain why. I think that article misses the point I was making too really and does nothing to address this particular concern.

As I say, perhaps I’m missing something, but so far I’ve read nothing that addresses this particular point.

If there is some reason why it must be part of the core, then it would have been better received I think if an admin setting was provided to turn it on and off (and if it was turned off by default so as not to take people by surprise).

P.S. Just to be clear – it’s the compatibility layer code that’s getting added to the head that’s the issue in this scenario- not the update to the database to support unicode (which is a good thing), that people using wordpress as a CMS have an issue with.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.