Add option to globally disable comments on a content type.

[serundeputy]

Describe your issue or idea

Give administrators the ability to globally disable comments for a content type. Then content editors do not have the Comment settings vertical tab for that content type.

Steps to reproduce (if reporting a bug)

• visit /admin/structure/types/manage/TYPE

Actual behavior (if reporting a bug)

• There is no setting to entirely disable comments.
• There is just a setting to close comments.

Desired behavior (if reporting a bug)

• Add a setting to globally disable comments across the content type. Meaning the content editors will not have access to the comment settings to turn them on or off per node.

Relevant version/system information (if applicable)

1.x

---

PR: backdrop/backdrop#2117

[serundeputy]

PR: backdrop/backdrop#2117

---

QC: http://2117.backdrop.backdrop.qa.backdropcms.org/
Username: admin
Password: TNtv9zGT

---

You can see/use the new Globally disable option on posts for example: http://2117.backdrop.backdrop.qa.backdropcms.org/admin/structure/types/manage/post

[olafgrabienski]

A nice idea, but what's supposed to happen with content where first comments were allowed and then were globally disabled by the setting? At the moment in the PR, comments created before they were globally disabled continue to be allowed. Is that okay?

Apart from that, I think the help text can be improved.

Current status:

• Globally disable
  Checking this box will eliminate the vertical tab for comment settings per node.

First try:

• Globally disable
  Don't show the vertical tab for comment settings on Add or Edit content pages.

[olafgrabienski]

An update regarding the user interface: I've just watched the Backdrop meeting of Mar 29 on Youtube: The idea (around 20:34) was to display checkboxes similar to the "Sticky" and "Promoted" sections on the Publishing settings tab. Here's the "Sticky" example:

Sticky

• Show option to make posts sticky
• Make posts sticky by default

For comments that would mean to not call the setting "Globally disable" but to add a (positive) option, enabled by default, like "Show option to change comments settings". Here what it could look like:

• Show option to change comments settings

  Default comment setting for new content
  ( ) Open comments
  (x) Closed comments

  [...]

NB: I guess with the goal of the new general setting to disable comments easily, it's better to have comments closed as a default, so I changed the default of the respective radio buttons above from "Open comments" to "Closed comments".

[mikemccaffrey]

Personally, I think that when the box is checked to have the comment controls hidden on the node forms, the settings for whether comments on an individual node are displayed should be taken from the content type settings.

That way you can decide that all nodes of a certain type should have their comments either enabled or disabled, regardless of how the individual nodes have previously been set. All the individual node settings can be retained, and returned to working as usual if the checkbox is selected for the content type.

Maybe the checkbox can say something like "Apply these settings to all nodes of this type" or something similar.

[serundeputy]

I like that @mikemccaffrey ... it is inline with what i was thinking.

Apply these settings to all nodes of this type

Can we come up with some wording similar to this that avoids the word node? I like the word node, but I know we as a community are trying to avoid it in front facing help text.

---

TODO: when the node type form is saved with the new setting go through existing nodes of this type and turn comments off.

[olafgrabienski]

Apply these settings to all nodes of this type

Can we come up with some wording similar to this that avoids the word node?

What about "(content) items"? For instance:

• Apply these settings to all items of this content type.
• Apply these settings to all content items of this type.

[serundeputy]

I like the first:

• Apply these settings to all items of this content type.

[ghost]

I'd love to have this feature! I sometimes enable the Comments module to allow visitors to comment on Posts, but I never want comments enabled on the Page content type. So I'd like to have the ability to fully disable comments per content type.

The way I see this working:

• Have a checkbox on node type forms (e.g. /admin/structure/types/manage/page) that enables comments for that content type.
• When the checkbox is unticked, none of the comment settings are displayed (e.g. 'Comments per page', 'Anonymous commenting', 'Preview comment', etc.). This is basically adding 'states' to those settings so they're displayed/hidden based on the checkbox being ticked or not.
• When the checkbox is unticked, none of the comment tabs are displayed (e.g. 'Comment fields', 'Comment display'). Not sure how this would happen, but it's just annoying to have these tabs on a content type where I don't want/need comments.

[klonos]

Just chiming in to say that we generally have been using "piece of content" in place of "node", but I like "content item" equally 👍...so either "...pieces of content of this type.", or "...items of this content type." are both fine.

I would love to have a more thorough go at this, as I am not using comments very often, so I need to get my head around how this works currently and how it should ideally work. I do agree that the checkbox should be "positive" though ...as in ticked by default, and with something along the lines of "Allow comment settings per content item" for its label, and "If this option is disabled, comment settings will be locked and hidden for all individual items of this content type." for its description.

@serundeputy the PR currently has conflicts. Care to reroll?

[ghost]

what's supposed to happen with content where first comments were allowed and then were globally disabled by the setting?
- #3016 (comment)

In my opinion, the new setting should simply show/hide the vertical tab where comments can be administered per node. Whether comments are opened or closed should continue to be controlled by the existing 'Default comment setting for new content' setting.

So if the new setting (called 'Show comment settings' for arguments sake) is enabled, editors can see the Comments vertical tab, and open or close comments for that node as normal. If 'Show comment settings' is disabled, editors cannot see the Comments vertical tab, and so comments are opened or closed based on the 'Default comment setting for new content' setting in that content type.

A use case for this might be wanting to have comments open for all Posts, and then automatically closed after 2 weeks. So you set that up in the Post content type, then untick the new 'Show comment settings' so that editors can't change that behaviour on individual Posts. And it makes the interface more tidy too.

I'm advocating for this same distinction between show/hide and enabled/disabled on the Sticky, Promote and Revision settings as well here: #3800

So to answer @olafgrabienski's question above, I'd suggest that nothing would change with the introduction of this setting as it simply controls the visibility of the vertical tab. Comment opened/closed status would still be controlled by that setting in the content type.

[olafgrabienski]

If 'Show comment settings' is disabled, editors cannot see the Comments vertical tab, and so comments are opened or closed based on the 'Default comment setting for new content' setting in that content type.

Seeing the word "new" in the 'Default comment setting for new content' setting, I guess comments on content items which were created before comments were globally disabled would be continued to be allowed.

In contrast to this, @serundeputy wrote in #3016 (comment):

TODO: when the node type form is saved with the new setting go through existing nodes of this type and turn comments off.

What do you think about it, @BWPanda ?

[ghost]

I think it should work the same as, say, the Promoted setting. What should happen in the same situation to existing nodes if the Promoted setting was hidden (not shown). Should they all lose their promoted status?

[olafgrabienski]

What should happen in the same situation to existing nodes if the Promoted setting was hidden (not shown). Should they all lose their promoted status?

No, I don't think so. What do you think, @serundeputy, in the case of the comment setting?

Btw, there's a difference for administrators who might want to change settings for individual nodes when a vertical tab isn't available: It's easy to change the Promoted setting via the bulk actions on admin/content. It might be helpful to add such an action for the comment settings as well.

[klonos]

I have re-read this entire thread, and I have the feeling that we need to flesh everything out properly. I need to re-read #1472 and any linked d.org issues/posts about this, to refresh my understanding of things around comments, and their use cases. I think we should have a clearer definition of what we are trying to achieve, because it seems to me that we are discussing (and possibly confusing) a few separate things: disabling comments vs. hiding comment options.

The current PR seems to be hiding things (sets invisible via #states). My preference would be to disable things completely if possible. Think of it as a setting for the Comment module, which completely disables its functionality for content types specified by admins.

A related UX/UI issue is that currently, the "Configure" operation for the Comment module in /admin/modules takes people to /admin/content/comment, where they can manage published vs. unapproved/pending comments. I would like to see that changed to link to a single, "proper" settings page for the Comment module instead, where there is:

1. A list of all existing content types, with checkboxes next to them. People can use this as a single go-to place to configure which content types could have comments enabled and which can't. Ideally, any functionality provided by the comment module would not load at all for these content types.

2. A "Default state for new content types" checkbox, which controls if comment settings will be on/off for new types. Setting this to "on" would leave the current functionality as is. Setting it to "off", would practically make any comment settings opt-in (site admins would specifically need to visit this settings page to enable comment settings for a content type). This means that even admins will not get a "Comment settings" vtab when creating new content types - as if Comment module is disabled.

3. A matrix of comment-related permissions.

4. ???

This admin page could also serve as a home for any contrib modules related to comments.

I still need to figure out a few things like what would/should happen to any existing comments on pieces of content, when comments get disabled for their content type.

Also need to go through any contrib solution to see how they do things (and possibly figure out why).

PS: quoting myself from #1472:

...So, lets add a "Disabled" checkbox in the content type edit form that truly disables comments on a per-content-type basis:

1. sets the comments for all nodes of the content type to "hidden" (to account for possible past comments)
2. removes the entire "Comment settings" vtab in the node edit/create form for the content types where this setting is enabled
3. uses #states to hide all settings in the "Comment settings" vtab in the content type edit/create from (and updates the vtab summary to simply say "Disabled").

[yorkshire-pudding]

I'm pleased I searched before adding this myself as it's exactly what I was thinking is needed.

[jenlampton]

I just implemented a custom solution for a site that needed exactly this feature, +1 for this idea! (adding milestone candidate label for 1.22)

[olafgrabienski]

it's exactly what I was thinking is needed

a custom solution for a site that needed exactly this feature

Happy to see new activity here! Can you describe your use cases more "exactly"? :-) There are still a few open questions in the thread, e.g. what should happen with existing comments when the setting isn't disabled.

I'm also not sure if / how #3001 should influence the concept. The option to close comments after a certain time span was quite new when this thread here started.

[yorkshire-pudding]

@olafgrabienski - my use case is more about setting up content types that will never have comments; I'll want to simply disable for content type. I can see merit in the other use cases, I just haven't come across them yet. Most content types in my sites don't have comments so it would be at the start.

[jenlampton]

My use case is for an event that accepts session submissions. When submissions are accepted, comments are closed, so by default each node has the comments set to "closed".

Then when the event starts, comments open on all sessions (so people can discuss the video for the session). I wrote a custom handler that will update all existing nodes of that type to switch the status from "closed" to "open".

Then, when the event ends, all comments need to be switched to "closed" again. My custom handler will also switch all existing nodes of that type to comments "closed".

In my case, all sessions were created more than 2 weeks before the event stared, so Comment Closer wouldn't affect my session nodes at all.