In [33041] and [33054] for #31168, we’ve turned comments off on new pages by default.
I know many of you have done the “make a bunch of pages, fill them out, realize comments are turned on, go back into the admin (and super admin), turn off comments” dance. Now when you make a page, you won’t have to manually turn off comments — it’ll match the expected behavior of being off by default.
In addition to pages, this functionality has been extended to all custom post types. Post registrations that don’t explicitly add support for comments will now default to comments being off on new posts of that type (before, they defaulted to on). Up until now, post type support for comments has only affected admin UI User interface; a developer could omit comment support on registration but still allow comments to be posted. This is a change in behavior, and we will be closely monitoring its effects during beta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process.. Moving to explicit support will allow core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. behavior to be more predictable and robust in the future, but we will always consider real-world usage.
In trunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision., you’ll notice two new things: the get_default_comment_status() function, which accepts the post type and comment type as arguments (both optional), and within it a get_default_comment_status filter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output., which receives the status, post type, and comment type as arguments. If you’ve been directly checking options such as with get_option( 'default_comment_status' ), you will likely want to replace those calls with get_default_comment_status(). We recommend explicit registration of post type support for comments, but as an example of using the filter, you can restore current behavior using the following:
/**
* Filter whether comments are open for a given post type.
*
* @param string $status Default status for the given post type,
* either 'open' or 'closed'.
* @param string $post_type Post type. Default is `post`.
* @param string $comment_type Type of comment. Default is `comment`.
* @return string (Maybe) filtered default status for the given post type.
*/
function wpdocs_open_comments_for_myposttype( $status, $post_type, $comment_type ) {
if ( 'myposttype' !== $post_type ) {
return $status;
}
// You could be more specific here for different comment types if desired
return 'open';
}
add_filter( 'get_default_comment_status', 'wpdocs_open_comments_for_myposttype', 10, 3 );
#4-3, #comments, #dev-notes, #post-types
You must be logged in to post a comment.