WordPress Publishing Failed Could Not Update Post

The Issue with Emojis

Recently, I faced a rather annoying problem on www.URTech.ca and a few of its sister sites. I was attempting to add some emojis to a blog post (using Windows + Period to access the emoji keyboard) but encountered an irritating error every time I clicked on PUBLISH or SAVE DRAFT: “Publishing failed. Could not update post in the database”.

This is not a flaw in the WordPress core software; rather, it stems from a limitation of older SQL databases. If your website was created years ago and has undergone multiple updates through different versions of WordPress, it likely still employs an outdated encoding format.

Emojis are classified as 4-byte characters. Earlier MySQL databases typically used utf8mb3, which accommodates only 3-byte characters. Therefore, when trying to insert a 4-byte emoji into a 3-byte slot, the database rejects it, resulting in that generic FAILED error message from WordPress.

Here are two methods I tested to resolve the issue of “Publishing failed. Could not update post in the database.”

Method 1: Update Your Database Structure

The simplest solution is to upgrade your database tables to utf8mb4, the current standard that supports 4-byte characters seamlessly.

You can initiate this by adding a temporary snippet to your theme’s functions.php file.

1. Navigate to Appearance > Theme File Editor > functions.php.
2. Append the following code at the bottom:

   // TEMPORARY CODE: RUN ONCE TO CONVERT DATABASE TO UTF8MB4
if ( function_exists( 'maybe_convert_table_to_utf8mb4' ) ) {
global $wpdb;
$wpdb->set_charset( $wpdb->dbh, 'utf8mb4', 'utf8mb4_unicode_ci' );
maybe_convert_table_to_utf8mb4();
}

3. Save the file, refresh your site’s homepage to activate the code, and then remove this code immediately from your functions.php file.
   • It’s not critical to remove the code, but leaving it in will slow down your site as it runs on every page load, consuming unnecessary resources.

The Catch: In my situation, this method didn’t work. When I set up my WordPress database, I specified a custom table prefix (urt_), and this meant the automated conversion could not navigate my specific structure. If you encounter the same issue, fear not; Method 2 is your solution.

Method 2: The HTML Encoding Workaround (The “Reliable” Fix)

Since Method 1 didn’t yield results for me, I opted for a workaround that is just as effective and safer but requires it to run every time a post or page is saved. Instead of altering the database structure entirely, we can instruct WordPress to encode emojis as HTML entities (like 😃) before saving.

HTML entities are simply plain text, making them compatible with older 3-byte database tables. When you load the page, your browser automatically converts the text back into an emoji.

Follow These Steps:

1. Return to your functions.php file.
2. Insert this code and keep it there permanently:

   /**
* Force WordPress to encode 4-byte characters (emojis) as HTML entities before saving.
* This prevents database errors on utf8mb3 setups.
* This code is safe and permanent.
*/
add_filter( 'wp_insert_post_data', 'my_encode_emojis_before_save', 10, 2 );

   function my_encode_emojis_before_save( $data, $postarr ) {
   if ( ! empty( $data[‘post_content’] ) ) {
   // Utilise the built-in WordPress function to encode 4-byte characters securely
   $data[‘post_content’] = wp_encode_emoji( $data[‘post_content’] );
   }
   return $data;
   }

3. Save the file.

Conclusion

This code incurs virtually no performance overhead, as it runs only for a brief moment when you click SAVE DRAFT or PUBLISH; it does NOT execute each time a page or post is loaded by visitors.

If you’re grappling with this issue on an older website, I highly recommend Method 2. It’s straightforward, secure, and effective.

Once I added that filter, I could save my post with as many emojis as I desired without any hassle.