Hi,
In WordPres 4.2+ it’s possible to use emoji inside the post content editor. However, I can’t use emoji in ACF fields including WYSIWYG editor with full features. If I save the field, all the field content is automatically removed.
Is it possible to give emoji compatibility to your fields?
Thanks
Hi @andreu
When you say that all the field content is removed do you mean that your emojis are removed or that if you’ve pasted in a block of text in the wysiwyg-field and save it the whole thing gets removed leaving you with an empty editor?
If so, does the same thing happen if you paste in text NOT containing any emojis?
Hi @jonathan
The whole thing gets removed when I save the input with emojis. If I try to save the input without emojis everything works fine.
Thanks
Hm okay,
Just to be sure, these emojis are the ones built into the later versions of WordPress? Not something from a plugin etc.
Yes, they are built in from 4.2. You can try copy/pasting one emoji from here https://codex.wordpress.org/Emoji
Okay so I’ve tried it now on a WYSIWYG field.. I tested the car emoji ? 🙂
It works just fine for me.. the content is saved regardless of how I place the emoji. Could you try disabling all other plugins and test it again? And perhaps try it with the default twentyfifteen theme. Just to eliminate any outside interference
Hi Jonathan,
I tested it with twentyfifteen and only ACF Pro 5.2.8 enabled and it’s still removing all my content when I try to save a WYSIWYG field. Any ideas of how can we debug this?
Thanks
Do you have wp_debug on?
https://codex.wordpress.org/WP_DEBUG
If not please activate it and see if it turns up any notices/warnings/errors..
Here’s a snippet I like to place in my wo-config file which’ll save all issues to a debug.log file in wp-content rather than spit them out directly on the screen.
// Turns WordPress debugging on
define('WP_DEBUG', true);
// Tells WordPress to log everything to the /wp-content/debug.log file
define('WP_DEBUG_LOG', true);
// Doesn't force the PHP 'display_errors' variable to be on
define('WP_DEBUG_DISPLAY', false);
// Hides errors from being displayed on-screen
@ini_set('display_errors', 0);
I already had debug enabled and no error appear when I save the post. With debug disabled it happen the same. Thanks
Hm okay..
Perhaps it’s an issue of your database. Do you have the latest WP version? Also, does the same thing happen when you place emojis in the standard editor?
What’s interesting here is that ACFs wywisyg-field just makes use of the wp_editor in WP core so it does pretty much the same things as the default editor.
Yes, in main post content editor this works fine. It only happens in WYSIWYG editor of my ACF’s field 🙁
Yes, I have WordPress latest version too.
Well slap me silly and call me sally..
All I can think of is doing some dumb “did you plug it in” testing..
Like try deleting ACF and reinstalling (to make sure you’ve got all files and nothing is corrupt).
I uninstalled and removed ACF. I tried this with a previous version of ACF and this don’t work. After updating to the latest version still not working. Also, I tried to create another WYSIWYG field with different name and doesn’t work either.
Hmm okay..
I can’t think of a reason why this would happen.. perhaps your database is the issue. Could you check the collation of wp_postmeta to make sure its utf8mb4
Hi @jonathan,
My collation is utf8_general_ci. Could it give any problems? I use to work with it as my server’s WP auto install set this collation by default. I can’t see utf8mb4 you mention in the dropdown.
Thanks
Okay. Are you using the same collation for all tables in the DB?
I have two different collations in my DB. Should I use the same? Which is the best collation to use?
I don’t use to change this and in general all my WordPress are working fine…
I’m just thinking that maybe it’s due to a collation on the wp_postmeta table not compatible with the emojis. Since the default editor works and those are saved in wp_post table. could you make sure you have the same collation for wp_postmeta and wp_post
I know I’m almost three years late to the party, but I was running into the same issue and couldn’t find a solution.
I tried inserting an emoji directly in the database, which prompted an error. After researching that error, it seems the field’s collation type didn’t support all emoji (but some, like 3-byte ones would work). In my case, it was set to utf8_general_ci.
Solution: Change the field collation type to utf8mb4_general_ci to support longer-byte emoji.
To be on the safe side, make a backup of your database before operating this change. Hope this helps other people that run into this issue! 🙂
@chriskirknielsen I made an account just to say thank you for a thorough answer, this should be highlighted as the correct answer. I’m surprised this isn’t covered elsewhere, at least to my knowledge.
Many thanks!
Hi,
I did the database update, but then the emojis are stored as ? in the database. When I display them though the wordpress admin dashboard, they are displayed correctly.
How do I need to convert them if I want to get them with a PHP script ?
Thx
@chriskirknielsen Thank you so much for your response. I also made an account on this forum just to thank you for sharing your findings and helping others. Thanks a lot.
Hello,
I’ve just come across the same problem. Changing the database column to ut8mb4 does seem to work, but we shouldn’t have to need to do this and risk messing up all the rest of the content.
https://benjaminintal.com/2017/11/06/sanitize-emojis-custom-fields/
There’s a solution here to get it working without needing to update the column format. Would it be possible to implement this directly into acf?
