WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

#31771 closed defect (bug) (fixed)

Emoji rendering in Windows XP

Reported by: afercia Owned by: pento
Milestone: 4.2 Priority: normal
Severity: normal Version: 4.2
Component: Database Keywords: emoji has-patch
Focuses: Cc:
PR Number:

Description

See attached screenshots, tested on 4.2-beta2-31866

Latest Chrome:

https://cldup.com/FmCDwtW5Yk.png

Latest Fireox:

https://cldup.com/hq8PJWzZdl.png

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

Attachments (1)

31771.diff (627 bytes) - added by pento 5 years ago.

Download all attachments as: .zip

Change History (10)

#1 @afercia
5 years ago

  • Keywords emoji added

#2 @pento
5 years ago

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; ?

#3 @afercia
5 years ago

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"
  }
}

#4 @kraftbj
5 years ago

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
5 years ago

#5 @pento
5 years ago

  • Component changed from Formatting to Database
  • Keywords has-patch added
  • Milestone changed from Awaiting Review to 4.2
  • Owner set to pento
  • Status changed from new to assigned

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?

#6 follow-up: @afercia
5 years ago

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:

https://cldup.com/aHFL9GSyfT.png

#7 in reply to: ↑ 6 ; follow-up: @azaozz
5 years ago

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 :)

#8 in reply to: ↑ 7 @afercia
5 years ago

Replying to azaozz:

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

Chapeau! :)

#9 @pento
5 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

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.

Note: See TracTickets for help on using tickets.