Change record status: 
Introduced in branch: 
Introduced in version: 

In Drupal 7, comment settings were per node type. The settings were managed from the 'edit node type' form and saved as variables.

In Drupal 8, comment settings are a field. This means you can add commenting to any entity type by adding a comments field. This also means you can have multiple comment threads on a single entity type so you could potentially have a 'for' and an 'against' comment field. Or a 'public' and 'admin' comments.

User interface changes

  • Comment field ui now has its own distinct place, on the same level as content type settings.
  • Comment settings are no longer managed on the content type settings page, instead these are field instance settings and are managed by editing the comment field on an entity

Field settings
Admin settings

Upgrade path

The upgrade path is written so that all node types that have comments enabled by default gets a new comment field created for it (even if no nodes of that type have any comments). Comment settings are migrated over to that field's instance settings. One comment-field is created for each node type because in Drupal 7 it was possible to have different fields on each form so this preserves that functionality.

Fields on comment-forms

Each field added must nominate a comment type (bundle) as this governs the fields present on the comment-form. In the default install a new comment field called 'comment' is added to the article and page node type. You can utilise the 'reuse existing field' form on new node-types to add this field to node types you create. Fields attached to the comment-form are per comment-type. So if you wish to have the same comment-form on article and page node-type, you would use the same comment-type on both. If you want to have a 'link' field (for example) on the article node comment form, but not on the page node comment form, then add a new comment-type and then choose this when adding the new 'comments' field to the page content-type. Each comment-type allows a separate set of fields on the comment-form.
Managing fields on comment-forms is done from the new admin UI at admin/structure/comments (see screenshot above).

API Changes

There are significant API changes in this change - including the introduction of a CommentManager service. Whilst procedural wrappers remain, we will be working to continue to move many of these to the manager service to allow proper DI (dependency injection). Procedural wrappers will be retained and marked as deprecated. Many of these procedural wrappers have changed from 8.0-ALPHA3 to accommodate the new functionality. Key changes are as follows:

Contstants changed


To determine if an entity has a comment field

Use comment manager service.

// Check if there are any comment fields on nodes, returns array of field info 
// consistent with field_info_fields() filtered to only comment fields.
$field_names =\Drupal::service('comment.manager')->getFields('node');
// Do something with a particular field.
if (isset($field_names['my_comment_field'])) {
  $comment_count = $node->my_comment_field->comment_count;

Creating a comment field using code

The simplest way is to use the manager.

// Add a field using default name of comment and default value of hidden.
\Drupal::service('comment.manager')->addDefaultField('node', 'page');
// Add a second comment field called admin_comments, defaulting to open.
\Drupal::service('comment.manager')->addDefaultField('node', 'page', 'admin_comments', COMMENT_OPEN);

Comment configuration

All variables of form comment_XXX_%type are removed, use instance settings instead.

$mode = variable_get('comment_default_mode_' . $node->type, COMMENT_MODE_THREADED);
use \Drupal\field\Field.
$instance = Field::fieldInfo()->getInstance('node', $node->type, 'comment');
$mode = $instance->getFieldSetting('default_mode');


Forum creates its own comment field called comment_forum.

  if ($node->comment == COMMENT_NODE_OPEN) {
    // Do something.
  if ($node->comment_forum->status == COMMENT_OPEN) {
    // Do something.

Comment statistics

Because we can have multiple comment fields on an entity/bundle - the comment_count etc (anything that was in node_comment_statistics table) have been moved from top level node object properties to properties of each field. Note that node_comment_statistics table is now comment_entity_statistics for consistency.

$comment_count = $node->comment_count;
$field_name = 'comment';
$comment_count = $node->$field_name->comment_count;
Site builders, administrators, editors
Module developers
Updates Done (doc team, etc.)
Online documentation: 
Not done
Theming guide: 
Not done
Module developer documentation: 
Not done
Examples project: 
Not done
Coder Review: 
Not done
Coder Upgrade: 
Not done
Other updates done


Nemo’s picture

This sounds like a great change. I suspect it will be one of those features that gets in quietly and turns out to be incredibly useful.

Does this also now mean that we can add comment-type-2 as a field to comment-type-1?
For example, if I create a content-type called 'Product' and add a comment-type called 'Member Review'.
I can add ratings, etc fields to the 'Member Review' comment-type.
Can I also add a new comment-type called 'Remarks' and add it as a field to the 'Member Review' comment-type?

This would essentially allow me to use a different comment-type for replies to comments. Incredibly useful for Reviews where you want certain fields on the top-level (star ratings etc), but don't want them on replies to the top-level comments. (like how the reviews on Amazon have a different comment type for replying to the reviews)

Rajeshreeputra’s picture

With the comment field added to the content type, comments functionality are available with all the content created with same content type.
I want comments enable for few pages of same content type and comment functionality disabled for few pages. Is there any chances to have something like, conditional field for comments usability like, if I add comment field to my content type it also add one field called comments enabling option with value yes/no. At the time of content creation user can select option for comments, if user select yes then comments get enable for that node/page, if no then comments not get enabled for that node/page, even both the pages/nodes are created using same content type.

Rajeshreeputra’s picture

We can do the comments open/closed using core settings on each page