[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