id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc	focuses
65700	Comments: wp_insert_comment() and wp_update_comment() don't encode emoji for utf8mb3 columns like wp_insert_post() does	barry		"`wp_insert_post()` encodes emoji (and other 4-byte UTF-8 characters) as HTML entities before saving a post, when the destination column uses the legacy `utf8`/`utf8mb3` character set instead of `utf8mb4`. This logic lives inline in `wp_insert_post()` (`wp-includes/post.php`) and calls `wp_encode_emoji()`. It was introduced for posts under #31242.

`wp_update_post()` already benefits from this since it delegates to `wp_insert_post()` internally.

However, `wp_insert_comment()` and `wp_update_comment()` (`wp-includes/comment.php`) have no equivalent handling. On a site whose `wp_comments` table still uses `utf8`/`utf8mb3` collation (common on hosts that haven't run the utf8mb4 upgrade, or after MySQL 8.0.30+/MariaDB 10.6.1+ renamed `utf8` to `utf8mb3`), inserting or editing a comment containing an emoji currently either silently corrupts the content or fails outright, depending on SQL mode - the same class of issue as #60362 on the post side.

'''Proposed fix (attached patch)'''

* Extracts the existing ""encode emoji if the column is utf8/utf8mb3"" logic out of `wp_insert_post()` into a new private helper, `_wp_encode_emoji_in_fields( $data, $table, $fields )`, in `wp-includes/formatting.php`.
* Updates `wp_insert_post()` to call the helper (behavior-preserving refactor, no functional change for posts).
* Calls the same helper from `wp_insert_comment()` and `wp_update_comment()` for the `comment_author` and `comment_content` fields, so comments get the same utf8mb3 safety net posts already have.

'''To test'''

On a site where the comments table (or a specific column) uses `utf8`/`utf8mb3` collation - or force it for testing via the `pre_get_col_charset` filter:
1. Insert or edit a comment containing an emoji (via `wp_insert_comment()`/`wp_update_comment()`, or the standard comment form).
2. Before the patch: the emoji is corrupted in the database, or the save fails.
3. After the patch: the emoji is stored as an HTML entity, consistent with how `wp_staticize_emoji()` already renders emoji stored this way, and the comment saves successfully.

No behavior change on utf8mb4 installs."	defect (bug)	new	normal	Future Release	Emoji	7.1	normal		has-patch has-unit-tests