The assumption made here, in comment_form_node_form_alter(), is incorrect.

  // If the node doesn't have any comments, the "hidden" option makes no
  // sense, so don't even bother presenting it to the user.
  if (empty($comment_count)) {
    $form['comment_settings']['comment'][COMMENT_NODE_HIDDEN]['#access'] = FALSE;
    // Also adjust the description of the "closed" option.
    $form['comment_settings']['comment'][COMMENT_NODE_CLOSED]['#description'] = t('Users cannot post comments.');
  }

Comments being closed and comments being hidden are different states, and users should be allowed to choose between them. For instance, if a collection of nodes did have commenting available for a period of time, and now commenting is closed, then I may want to show the number of comments per node. Zero is a valid number of comments. But if I want to remove all trace that commenting ever happened on those nodes, then I want to be able to change their status from CLOSED to HIDDEN. It's like the difference between zero and NULL.

This whole IF block should be removed.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

brad.bulger’s picture

Version: 7.23 » 7.27
Status: Active » Needs review
FileSize
781 bytes

Patch file to remove this code.

Status: Needs review » Needs work

The last submitted patch, 1: comment-2140251-hidden.patch, failed testing.

mirie’s picture

I agree with this proposal completely. I also noticed that the default value also has funky logic. In comment_form_node_form_alter(), line 1223:

    $comment_settings = ($node->comment == COMMENT_NODE_HIDDEN && empty($comment_count)) ? COMMENT_NODE_CLOSED : $node->comment;

I found out about this because I implemented my own hook_form_BASE_FORM_ID_alter() for the node form to override the comment hidden issue. That meant that even though I made the hidden comment option accessible and saved the node with hidden selected, on the next refresh of that node edit form, the value selected for comments was Closed because the node didn't have any comments! That seems like unexpected behavior to me...I was surprised.

brad.bulger’s picture

Ah, I just ran into this. Yes, it resets the mode from Hidden to Closed because reasons (???) and makes comment links appear when they ought not to. You have to manually reset it every time. That's just wrong.

If the node's own comment property is not set, it should use the default for the content type.

I've added that in and redone the patch.

brad.bulger’s picture

Version: 7.27 » 7.x-dev
Status: Needs work » Needs review
dcam’s picture

Version: 7.x-dev » 8.1.x-dev
Status: Needs review » Active

This code that is causing the original issue still exists in Drupal 8. See formElement() in /core/modules/comment/src/Plugin/Field/FieldWidget/CommentWidget.php. That means the change will need to be made to Drupal 8 first.

dcam’s picture

Version: 8.1.x-dev » 8.0.x-dev

Actually, since this is considered a bug then it may be possible to get this fixed for 8.0.x.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

quietone’s picture

Version: 8.9.x-dev » 7.x-dev
Issue tags: +Bug Smash Initiative

The code in question does not exist in Drupal 9.3.x. It was removed on 27 Sept 2013 before this issue was opened. I think it was Drupal 8.0-alpha4, #731724: Convert comment settings into a field to make them work with CMI and non-node entities.

Moving to Drupal 7.