Emoji rendering in Windows XP

[afercia]

See attached screenshots, tested on 4.2-beta2-31866

Latest Chrome:

Latest Fireox:

Tested also in IE 8, behaves as Chrome but sooo slow when displaying the editor even with a very short post.

[pento]

The square in the title box is sadly unavoidable. We can't replace emoji characters with images in a text input, only within TinyMCE.

The "????" seems to suggest that the emoji is being converted to latin1 at some point. Could you please post your DB_CHARSET, and the output of the MySQL query SHOW CREATE TABLE wp_posts; ?

[afercia]

Previous screenshots are from @rianrievteld test server, I don't have access there. Can replicate the issue on my local environment:

define('DB_CHARSET', 'utf8');

array(1) {
  [0]=>
  object(stdClass)#354 (2) {
    ["Table"]=>
    string(8) "wp_posts"
    ["Create Table"]=>
    string(1846) "CREATE TABLE `wp_posts` (
  `ID` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `post_author` bigint(20) unsigned NOT NULL DEFAULT '0',
  `post_date` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
  `post_date_gmt` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
  `post_content` longtext COLLATE utf8mb4_unicode_ci NOT NULL,
  `post_title` text COLLATE utf8mb4_unicode_ci NOT NULL,
  `post_excerpt` text COLLATE utf8mb4_unicode_ci NOT NULL,
  `post_status` varchar(20) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT 'publish',
  `comment_status` varchar(20) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT 'open',
  `ping_status` varchar(20) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT 'open',
  `post_password` varchar(20) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
  `post_name` varchar(200) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
  `to_ping` text COLLATE utf8mb4_unicode_ci NOT NULL,
  `pinged` text COLLATE utf8mb4_unicode_ci NOT NULL,
  `post_modified` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
  `post_modified_gmt` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
  `post_content_filtered` longtext COLLATE utf8mb4_unicode_ci NOT NULL,
  `post_parent` bigint(20) unsigned NOT NULL DEFAULT '0',
  `guid` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
  `menu_order` int(11) NOT NULL DEFAULT '0',
  `post_type` varchar(20) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT 'post',
  `post_mime_type` varchar(100) COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '',
  `comment_count` bigint(20) NOT NULL DEFAULT '0',
  PRIMARY KEY (`ID`),
  KEY `type_status_date` (`post_type`,`post_status`,`post_date`,`ID`),
  KEY `post_parent` (`post_parent`),
  KEY `post_author` (`post_author`),
  KEY `post_name` (`post_name`(191))
) ENGINE=InnoDB AUTO_INCREMENT=3976 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci"
  }
}

[kraftbj]

I was able to duplicate this using a VM box from ​http://modern.ie, trying on IE 8 and Chrome latest, on a test site that works fine with Emoji on other OS.

Notable, the post_title in db is ????. The post_name was %f0%9f%98%96. Anytime I tried to edit that same post in any other OS after getting ???? the first time (replacing the ???? with a new title including emoji) yielded the same ????.

[pento]

There was a short period where trunk was incorrectly upgrading sites to utf8mb4, when their MySQL client libs didn't support it.

There are possibly other situations where a client is talking to a server that's been upgraded (different PHP versions on different servers, moving a site to a new host with the wrong client version). So, 31771.diff​ tries to mitigate that. Could you both please test it and see if that helps?

[afercia]

Hi @pento, not sure what changed but also without the patch, now everything seems to work fine, even IE 8 is much faster (as fast as IE 8 can be). Screenshot without the patch applied:

[azaozz]

Replying to pento:

31771.diff fixed it here.

Replying to afercia:

We've been trying to get the JS for the emoji chars replacement working better, it shows :)

[afercia]

Replying to azaozz:

We've been trying to get the JS for the emoji chars replacement working better, it shows :)

Chapeau! :)

[pento]

In 31947:

WPDB: When we check the character set of a column, and find that it's utf8mb4, we should also check that the current connection supports utf8mb4. It's possible that the environment may have changed since upgrading the DB, so we can fall back to utf8 when that happens.

Fixes #31771.