Support

Account

Home Forums Backend Issues (wp-admin) Emoji removed from custom fields

Solving

Emoji removed from custom fields

    • andreu

    • July 28, 2015 at 8:56 am

    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?

    • andreu

    • July 30, 2015 at 11:39 pm

    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.

    • andreu

    • July 31, 2015 at 2:00 am

    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

    • andreu

    • July 31, 2015 at 2:51 am

    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);
    
    • andreu

    • July 31, 2015 at 3:04 am

    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.

    • andreu

    • July 31, 2015 at 3:28 am

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

    • andreu

    • July 31, 2015 at 4:40 am

    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

    • andreu

    • August 4, 2015 at 1:33 am

    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?

    • andreu

    • August 10, 2015 at 8:34 pm

    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

Viewing 21 posts - 1 through 21 (of 21 total)

You must be logged in to reply to this topic.

We use cookies to offer you a better browsing experience, analyze site traffic and personalize content. Read about how we use cookies and how you can control them in our Cookie Policy. If you continue to use this site, you consent to our use of cookies.