Comments: Fix content stripping between < and > when used for comparison

[BugReportOnWeb]

This PR fixes the issue where mathematical comparison expressions in comments were causing comment content between < and > to incorrectly strip when displayed in the WordPress admin comments list view.

Testing Instructions:

1. Add a test comment with mathematical comparisons. A few examples below:

The statement 3 < 4 is right! And the statement 10-2-1=7 is also true. What about 4 > 3?
Check if 15.5 < 20.7 and verify 100 > 99.9
Simple case 1 < 2 > 0 should match
In some cases the value should be < 5 but in some instances it can be > 10 too

2. Navigate to Comments (admin menu) and view the 'Comment' column in the comments list
3. Verify the comment display correctly without any content being stripped

Trac ticket: https://core.trac.wordpress.org/ticket/63810

---

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• The Plugin and Theme Directories cannot be accessed within Playground.
• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props devasheeshkaul, q0rban.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[q0rban]

would it be more appropriate to just check if the current user can view unfiltered html? There are some admins that might not be able to view unfiltered html, in which case this might double encode characters?

Suggested change

	if ( is_admin() ) {
	if ( current_user_can( 'unfiltered_html' ) ) {

[BugReportOnWeb]

Yeah, that's a good catch. I'll update it. Thank you!

[q0rban]

I think this may be a bit too restrictive. For example, the following math expression would NOT get matched by this regex:

5 < x > 3

https://regexr.com/8gpd8

I suspect there are just too many possible math expressions out there to craft a proper regex to capture them. Instead, perhaps we just run esc_html() on the comment text?

[BugReportOnWeb]

Thank you for the review! I agree it's hard to capture everything with just a regex. Initially, I though about escaping the characters using esc_html(), but that results in escaping any anchor tags as well:

Before	After

I wasn't sure if it's ideal to have these elements escaped in the comment list or not. Please let me know if I can make this change.

[dmsnell]

@BugReportOnWeb welcome! thanks for submitting this proposed fix.

Indeed, it looks like comments are being affected by this, but the problem does seem to stem from HTML parsing issues in wp_kses_post(), for which #9270 exists.

I’m going to mark this as a duplicate because I think we want to be careful not to patch over a bug deeper in the system on the rendering path. That will add overhead and then leave some quirks around once the underlying issue is resolved.

In #9270 we’re looking at relying on the HTML API to provide actual HTML parsing too, freeing us from having to discuss which specific instances of a parse failure we want to attempt to restore (without accidentally breaking other ones).