id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc,focuses 49869,Apply comment field filters to backend,ttodua,,"Recently, I had to work on an internally consuming WP project. I am a bit surprised how WP filters are mainly affecting only visual side, instead of applying to backend functions. so, for example: {{{ add_filter('comment_form_default_fields', 'website_remove'); function website_remove($fields) { if( isset($fields['url']) ) unset($fields['url']); return $fields; } }}} it only removes 'url' input field from output of comment form. So, what is the point of that, if it can be simply achieved by css `display:none`. ? the intention is clear, that it should REMOVE ""url"" parameter from comment system at all. However, at this moment, even if people use 'comment_form_default_fields' filter to remove `url`, it is almost meaningless - anyone in front-end form can just insert `url` field (i mainly say bots, but also typical user can just insert ""url"" parameter in browser ""inspect element"") and submit form and in backend, in `wp-includes/comment.php :: wp_handle_comment_submission` still accepts the `url` field. In parallel of the fact that WP advocates ""never trust user input"", the filters should be applied firstly and mostly to backend functions in my mind. I firmly reckon that the filters (in any other WP form too) should be applied in both front-end and back-end functions for same parameter. So in backend, the same filter should be applied to comment fields ( in `wp-includes/comment.php :: wp_handle_comment_submission`): {{{ $comment_data = apply_filters('comment_form_default_fields', $comment_data, true); }}} the third parameter is indication whether the filter is in BACK-END (true) or FRONT-END (false). So, in front-end output of comments (`wp-includes\comment-template.php`, function `comment_form`) the filter can now be: {{{#!php