ellatrix
commented
1 year ago Hi! For the back-end question, could you open an issue here: https://core.trac.wordpress.org?
Yes, we rely on the OS to give you an emoji picker as they are better suited to support this.
This is both a backend and editing UI issue, as far as I know.
On the backend side:
If I am not mistaken, WordPress still relies on old smileys images code instead of using purely UTF8 text emojis. At least, that was the case last time I checked, and I didn't see an existing ticket nor announcement around this having changed. If so, this not only means extra old backend code and slower load performance (if images are involved), but causes problems for some feed readers or planet aggregators like Venus / PlanetPlanet / etc., that would not occur if emojis were pure unicode text.
Like over 70 thousand users, I have worked around the issue by installing this plug-in to force WordPress to use unicode* text emojis... but users shouldn't be expected to use this hack anymore. Many years have passed, and all major desktop operating systems (in addition to the mobile OSes) have had support for native, unicode-based full color emojis. Windows XP/Vista users should not be the limiting factor in 2023.
The other part, on the editing UI, is that Gutenberg does not have any emoji insertion button in its toolbars. It should have that when inside a block that handles text (also for post titles, ideally also outside of Gutenberg in the quick-edit mode in the posts list); just a button that opens a picker showing the browser's/OS's native emojis (with a quick search field), and inserts the chosen unicode emoji character. Currently, I have to use a separate app (GNOME Characters) to pick emojis and paste them into WordPress' Gutenberg editor, and it shouldn't be that hard. I can't be expecting my teammates to be running Linux with a dedicated emoji app to add iconography to texts in WordPress 😏
utf8mb4encoding. WordPress had an automated encoding migration script as part of core some years ago, but it was only there for a certain time window and required specific PHP / MySQL versions, which were not present in my shared host back then. I'm not sure why that encoding migration was not kept in place in WordPress; in my case, my 20-years-old blog was so old that it had missed the WordPress MySQLISO-8859-1toutf8toutf8mb4tables encoding conversion time window, so I had to do some database surgery in 2019 to fully and properly convert it to real unicodeutf8mb4... however, I suspect I'm the only person on the internet that encountered this problem and to care enough about it, vs most blog instances being much younger than that, and therefore having the correctutf8mb4encoding from the start.