Bug in comment function

[rokr4peace]

If I write a comment with following content:
The statement 3<4 ist right! And the statement 10-2-1=7 ist also true. What about 4>3?

will lead to following comment:
The statement 33?

Somehow the comment function takes a part as a HTML comment (<!-- ... >) and hide it!

[devasheeshkaul]

Reproduction Report

Description

❌ This report validates whether the issue can be reproduced.

Environment

• WordPress: 6.9-alpha-60093-src
• PHP: 8.2.29
• Server: nginx/1.29.0
• Database: mysqli (Server: 8.4.5 / Client: mysqlnd 8.2.29)
• Browser: Chrome 138.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.3
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.0

Actual Results

1. ❌ Error condition doesn't occurs (issue not reproduced).

Additional Notes

• I tested submitting a comment with the special characters as described in the issue report, and the comment rendered correctly on the frontend without any issues.

• Additionally, I tested editing the comment via the admin area, and it continued to display as expected on the frontend with no issues.

Supplemental Artifacts

[siliconforks]

The comment, displayed on the page wp-admin/edit-comments.php

[siliconforks]

Replying to devasheeshkaul:

Additional Notes

• I tested submitting a comment with the special characters as described in the issue report, and the comment rendered correctly on the frontend without any issues.

• Additionally, I tested editing the comment via the admin area, and it continued to display as expected on the frontend with no issues.

I can reproduce this issue on the wp-admin/edit-comments.php page. (See attached screenshot above.) Did you check that page?

[devasheeshkaul]

Oh yeah, you're right @siliconforks. I didn't check the preview. It is getting cut off in that column.

[devasheeshkaul]

Upon further check, it seems like the issue is originating from the ​default filter applied for textarea admin display

add_filter( 'comment_text', 'wp_kses_post' );

I wonder if adding a custom filter to bypass this in the admin listing would be a suitable approach or not.

[SirLouen]

Nice spotting @siliconforks

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

@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).

[dmsnell]

This is ultimately a problem stemming from HTML parsing failures inside of wp_html_split(). I think it’s best to resolve it there so we don’t multiple ad-hoc fixes (which will probably end up breaking other things).

The good news is that fixing this where the problem originates should resolve a number of other related issues.

While this function is not a direct duplicate of #63694, it’s reporting a specific manifestation of a problems dealt with generally there, so I’m marking it as a duplicate.