[wp-trac] [WordPress Trac] #61827: wp_check_comment_disallowed_list() can't be used to match unprocessed HTML

WordPress Trac noreply at wordpress.org
Thu Oct 24 13:21:49 UTC 2024


#61827: wp_check_comment_disallowed_list() can't be used to match unprocessed HTML
----------------------------------------+-----------------------------
 Reporter:  cfinke                      |       Owner:  SergeyBiryukov
     Type:  defect (bug)                |      Status:  reopened
 Priority:  normal                      |   Milestone:  6.7
Component:  Comments                    |     Version:  6.6.1
 Severity:  normal                      |  Resolution:
 Keywords:  has-patch needs-unit-tests  |     Focuses:
----------------------------------------+-----------------------------

Comment (by david.binda):

 I know that my previous comment was about firing the `check_comment_flood`
 action twice and thus causing a backward compatibility issue, but now I
 wonder whether it’s okay for the newly introduced function, the
 `wp_check_comment_data` to not have the `pre_comment_approved` filter
 incorporated, which means it would run twice :)

 The [https://core.trac.wordpress.org/attachment/ticket/61827/61827.diff
 61827.diff] allows filtering the return value of the
 `wp_check_comment_data` call from inside the `wp_allow_comment`, but not
 the second call on filtered data, which, IMHO, means the default WordPress
 behaviour will always be used, ignoring a result of any custom callback to
 the `pre_comment_approved` filter (except for `trash` and `spam` values).

 Running the PHPUnit tests with the proposed
 [https://core.trac.wordpress.org/attachment/ticket/61827/61827.diff
 61827.diff] there are some failures. Moving the `pre_comment_approved`
 filter to the `wp_check_comment_data` function fixes the failures except
 for one.

 IMHO, we should move the `pre_comment_approved` filter from
 `wp_allow_comment` to `wp_check_comment_data` function.

 The remaining failure in
 `Tests_XMLRPC_wp_newComment::test_new_comment_duplicated` seems to be due
 to the `WP_Error` return check from the `wp_allow_comment` which is now
 happening only after the newly introduced `wp_check_comment_data`
 function, which does not seem to be returning a `WP_Error` and is
 overriding the duplicate comment situation.

 I’m attaching a diff addressing my concerns mentioned above. To sum up the
 changes in between the
 [https://core.trac.wordpress.org/attachment/ticket/61827/61827.diff
 61827.diff] and the new diff:

 1. move `pre_comment_approved` filter to `wp_check_comment_data`
 1. check if `wp_allow_comment` returns a `WP_Error` and if so, return it
 early from the `wp_new_comment` before we even get to the
 `wp_check_comment_data` function call.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/61827#comment:17>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list