Stop double-escaping editorial comment fields

[GaryJones]

Summary

When a user added an editorial comment, five fields on the comment — author name, email, URL, IP address and user agent — were passed through esc_sql() before being handed to wp_insert_comment(). That function already escapes every value via $wpdb->prepare(), so the pre-escape was applied a second time and the literal backslash-quote sequences from the first pass were stored as data in the comments table.

The most visible symptom was an author whose display name contained an apostrophe. "O'Brien" appeared on their editorial comment as "O'Brien", and the same corruption silently affected comment author email, URL, IP and user agent. The WordPress.Security.ValidatedSanitizedInput.InputNotSanitized phpcs notice on the two $_SERVER lines had gradually cemented the belief that esc_sql() was a sanitisation step; it is not.

Removing esc_sql() from all five fields is the correct fix. The two $_SERVER values retain a light sanitisation via sanitize_text_field( wp_unslash( ... ) ) so phpcs's input-not-sanitised rule is satisfied without reintroducing the double escape. A regression test pins the behaviour: a user whose display name contains an apostrophe must have that apostrophe stored verbatim on their editorial comment.

Test plan

• composer test:integration — the new test_insert_comment_does_not_double_escape_author_name case passes, and the existing editorial-comments AJAX tests continue to pass
• Create a user with a display name like "O'Brien" and add an editorial comment from them; the comment author on the resulting comment should read "O'Brien", not "O'Brien"