Emojis cause "Updating failed. Could not update post in the database." error

[mikefitzman]

Hi guys

I recently discovered what I think is a bug, 'confirmed' by the folks at Brainstorm Force.

As of 26 January, I was suddenly unable to update certain posts and pages in WordPress. When I tried to save, I received the "Updating failed" error, but had made no backend or other changes to spontaneously create this error. I use Gutenberg.

I stumbled across a GitHub thread about someone with a lightning emoji in a post with the same problem. With this in mind, I removed all emojis from the pages and posts that could not save and sure enough, all functionality was restored to normal after doing so. I verified this several times by re-introducing emoijis, which reintroduced the error.

I've reported this to my host, Brainstorm Force (Astra theme devs) and now here. I hope it is of some assistance.

Regards

Mike

liquidaudio.com.au

[mikefitzman]

Sorry, my first post here and suggested by Brainstorm Force. I should add that I tried all suggested troubleshooting including deactivating plugins, clearing caches, checking REST API functionality, confirming database health and checking with my hosting provider.

Mike

[sabernhardt]

related GitHub thread:
​https://github.com/WordPress/gutenberg/issues/19552

[dmsnell]

@mikefitzman can you check on which encoding your database is using? if it's storing content with the utf8mb3 encoding then it cannot represent characters which require four bytes in utf8.

you can test this out indirectly by saving a post separately with each of the following two characters:

• 😄 (U+1F604) requires four bytes to encode in utf8, this should fail if the database encoding is utf8mb3
• ⚄ (U+2684) requires only three bytes to encode in utf8, a post should save with this character in it.

ideally, for many reasons, it would be preferable to store your database content as utf8mb4.

[mikefitzman]

@dmsnell Great suggestion, I've completed the test and cannot save posts containing the '😄'. Posts containing the other '⚄' character save normally. I'm wondering why my ability to save these 4-byte emojis changed overnight. I've had them in posts for a decade or more.

Mike

[dmsnell]

@mikefitzman you will want to figure out how to convert your database into utf8mb4. it's possible, though unlikely, that in the past those were being stored as their HTML numeric character references. For example, U+1F604 can be saved in HTML using only basic ASCII characters as 😄 or as 😄.

Another possibility which is more likely is that there were some glyphs that were saving because they only require three bytes, as ⚄ did. Another example is the ❤️, which only requires three bytes in utf8.

[mikefitzman]

Very interesting. I'd hate to break my site, so I may not try to convert the database unless I find a method that looks safe enough for me to try. Makes me think that Hostinger changed something without saying so. I wonder if this will be resolved through code changes...?

[salzano]

I think this is the same bug but with a different behavior because there is no error message.

When using the Full Site Editor to edit a Template Part, the Save button appears to work, but no changes are saved after pasting in the US flag emoji into the template 🇺🇸. My database collation is utf8mb4_unicode_ci.

Here are steps to reproduce on 6.4.3 and using the free FotaWP theme:

1. Go to Appearance > Editor > Patterns > Template Parts > Footer.
2. Paste the US flag emoji into a paragraph block in the template.
3. Press Save twice.
4. View a page that uses the Footer Template Part, see no changes.

[nataliat2004]

I was not able to reproduce this issue with and without Gutenberg activated. @mikefitzman , @salzano could you please check if instruction from this comment will help ​https://github.com/WordPress/gutenberg/issues/19552#issuecomment-1758798993?

[salzano]

OK. I deactivated all plugins. I still can't save a flag emoji in a Template Part.

I found that my tables were not all the same collation. I ran the query SHOW TABLE STATUS and found they looked like this:

wp_cf_form_entries	utf8mb4_unicode_520_ci
wp_cf_form_entry_meta	utf8mb4_unicode_520_ci
wp_cf_form_entry_values	utf8mb4_unicode_520_ci
wp_cf_forms	utf8mb4_unicode_520_ci
wp_cf_pro_messages	utf8mb4_unicode_520_ci
wp_cf_queue_failures	utf8mb4_unicode_520_ci
wp_cf_queue_jobs	utf8mb4_unicode_520_ci
wp_commentmeta	utf8mb3_general_ci
wp_comments	utf8mb3_general_ci
wp_edd_adjustmentmeta	utf8mb4_unicode_520_ci
wp_edd_adjustments	utf8mb4_unicode_520_ci
wp_edd_customer_addresses	utf8mb4_unicode_520_ci
wp_edd_customer_email_addresses	utf8mb4_unicode_520_ci
wp_edd_customermeta	utf8mb3_general_ci
wp_edd_customers	utf8mb3_general_ci
wp_edd_license_activations	utf8mb3_general_ci
wp_edd_licensemeta	utf8mb3_general_ci
wp_edd_licenses	utf8mb3_general_ci
wp_edd_logmeta	utf8mb4_unicode_520_ci
wp_edd_logs	utf8mb4_unicode_520_ci
wp_edd_logs_api_requestmeta	utf8mb4_unicode_520_ci
wp_edd_logs_api_requests	utf8mb4_unicode_520_ci
wp_edd_logs_file_downloadmeta	utf8mb4_unicode_520_ci
wp_edd_logs_file_downloads	utf8mb4_unicode_520_ci
wp_edd_notemeta	utf8mb4_unicode_520_ci
wp_edd_notes	utf8mb4_unicode_520_ci
wp_edd_notifications	utf8mb4_unicode_520_ci
wp_edd_order_addresses	utf8mb4_unicode_520_ci
wp_edd_order_adjustmentmeta	utf8mb4_unicode_520_ci
wp_edd_order_adjustments	utf8mb4_unicode_520_ci
wp_edd_order_itemmeta	utf8mb4_unicode_520_ci
wp_edd_order_items	utf8mb4_unicode_520_ci
wp_edd_order_transactions	utf8mb4_unicode_520_ci
wp_edd_ordermeta	utf8mb4_unicode_520_ci
wp_edd_orders	utf8mb4_unicode_520_ci
wp_gf_addon_feed	utf8mb4_unicode_520_ci
wp_gf_draft_submissions	utf8mb4_unicode_520_ci
wp_gf_entry	utf8mb4_unicode_520_ci
wp_gf_entry_meta	utf8mb4_unicode_520_ci
wp_gf_entry_notes	utf8mb4_unicode_520_ci
wp_gf_form	utf8mb4_unicode_520_ci
wp_gf_form_meta	utf8mb4_unicode_520_ci
wp_gf_form_revisions	utf8mb4_unicode_520_ci
wp_gf_form_view	utf8mb4_unicode_520_ci
wp_gf_rest_api_keys	utf8mb4_unicode_520_ci
wp_links	utf8mb3_general_ci
wp_nextend2_image_storage	utf8mb3_general_ci
wp_nextend2_section_storage	utf8mb3_general_ci
wp_nextend2_smartslider3_generators	utf8mb3_general_ci
wp_nextend2_smartslider3_sliders	utf8mb3_general_ci
wp_nextend2_smartslider3_sliders_xref	utf8mb3_general_ci
wp_nextend2_smartslider3_slides	utf8mb3_general_ci
wp_options	utf8mb3_general_ci
wp_p2p	utf8mb4_unicode_520_ci
wp_p2pmeta	utf8mb4_unicode_520_ci
wp_postmeta	utf8mb3_general_ci
wp_posts	utf8mb3_general_ci
wp_redirection_404	utf8mb4_unicode_520_ci
wp_redirection_groups	utf8mb4_unicode_520_ci
wp_redirection_items	utf8mb4_unicode_520_ci
wp_redirection_logs	utf8mb4_unicode_520_ci
wp_term_relationships	utf8mb3_general_ci
wp_term_taxonomy	utf8mb3_general_ci
wp_termmeta	utf8mb3_general_ci
wp_terms	utf8mb3_general_ci
wp_usermeta	utf8mb3_general_ci
wp_users	utf8mb3_general_ci

I used the linked github page to run queries to change them. Every table in the database is now utf8mb4_unicode_ci. I still can't save the flag emoji in a Template Part.

[mikefitzman]

My apologies guys, I'd love to try this but I don't know PHP or have a staging capability to do this without worrying about bricking my site. I still have the issue BTW, no 4-byte emojis are possible for me.