[wp-trac] [WordPress Trac] #57105: Enhance wp_handle_comment_submission() with a custom validation
WordPress Trac
noreply at wordpress.org
Mon Nov 14 20:23:46 UTC 2022
#57105: Enhance wp_handle_comment_submission() with a custom validation
-------------------------+------------------------------
Reporter: apermo | Owner: (none)
Type: enhancement | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Comments | Version: trunk
Severity: normal | Resolution:
Keywords: | Focuses:
-------------------------+------------------------------
Comment (by apermo):
Well you are mostly right. I can somehow achieve what I tried to achieve
with my suggestion with that filter.
But.
My use-case as described above enhances the set of comment fields by a
custom field. Which is missing in `$commentdata`.
While it is perfectly possible to access the data via the `$_POST`, I
guess you will have to agree, that this is a little hacky.
I see two advantages of my suggestion.
1. it fires earlier, I did not expect a possible exit hidden further 2
functions deep, so that would be easier to find.
2. It contains the raw comment data, which is missing inside that filter.
I see three potential approaches to make the `pre_comment_approved` filter
work for that use-case without the need for `$_POST`
1. Add all custom form data to `$commentdata`.
2. Allow to add selected custom data to `$commentmeta` via filter.
3. Pass on the raw data within `$comment_data` all the way to
`pre_comment_approved`, yet with a name like `$raw_commentdata``
My thoughts on these, after noting them down:
1. All data, feels wrong, and could lead to unexpected flaws, especially
if there is some attack.
2. Adding the data via filter, just to use them 2 functions deeper to get
the an exit, does seem like a weird compromise, in that case I would still
prefer the original proposal.
3. That would likely be the better compromise.
I still see the advantage of my suggestion, that it is earlier and also
easier to find.
Before doing the suggestion, I searched google, stackoverflow etc. and did
not find anything on how to do a custom validation for the comment
feature. And since I could not find anything, I went step by step into the
code and into `wp_handle_comment_submission` and stopped there since I did
not expect a filter/short circuit hidden that deep.
On top, it is arguable wether `pre_comment_approved` does comply with the
single responsibility principle. Since it serves two purposes in a kind of
way, it does set the status to 1, 0, 'spam' & 'trash' and adds a short
circuit, which is at least 1.5 responsibilities.
I would argue that a distinct filter for an early rejection is beneficial,
but I can agree that having two filters that serve the same purpose is
even worse. So unless you see anything now that I don't see, I think the
best compromise. Would be 3. (pass along the new `$raw_commentdata`)
If you want we can have a chat tomorrow via Slack if you need further
explanation on my train of thought.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/57105#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list