[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