[wp-trac] [WordPress Trac] #31168: Comments should be turned off on pages by default

[WordPress Trac]

#31168: Comments should be turned off on pages by default
-------------------------------------+---------------------------
 Reporter:  melchoyce                |       Owner:  valendesigns
     Type:  enhancement              |      Status:  reopened
 Priority:  normal                   |   Milestone:  4.3
Component:  Comments                 |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:
-------------------------------------+---------------------------
Changes (by nacin):

 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Is there a compelling reason for the filter to be a dynamic one in the
 form of `get_{$post_type}_default_comment_status`? I think this is more
 appropriate as `apply_filters( "get_default_comment_status", $status,
 $post_type, $comment_type )`.

 We typically force specific, dynamic filters on developers in a few
 situations (these somewhat overlap/blur):
  * when we find it to be overly generic, such as `option` (does not exist)
 vs `option_{$option}`
  * when we find it to be overly dangerous, such as `update_option`
 (incorrectly using this filter took down .com, thus it was reverted there
 and #13836 was wontfix'd -- it was only added four years later when there
 was a compelling use case)
  * when it'd be significantly easier to use the dynamic one, such as when
 it's used for `manage_{$taxonomy}_custom_column`
  * when we use it as the underlying piece of an API, such as
 `sanitize_option_{$option}` (which is what `register_setting()` directly
 uses) or `auth_post_meta_{$meta_key}` (ditto for `register_meta()`)

 For something so minor, it seems annoying to need to `add_filter()` for
 each affected post type you may be trying to control. It's also a bit
 weird that it's broken down by *post* type and not (also?) by *comment*
 type, which is probably more expected here. I don't think there is a worry
 that someone will accidentally override the default comment status
 everywhere, unless that's actually exactly what they intend to do. As I
 write this, I wonder if this is worth keeping like this to avoid people
 stomping on random custom post types. But, most of our filters with a
 $post_type variable use it as an argument, and not as part of the dynamic
 name.

 '''P.S. Could someone perhaps massage the above guidance into the
 handbook? :-D'''

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