backdrop
Add option to globally disable comments on a content type.
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: https://github.com/backdrop/backdrop/pull/2117 Advocate: @NormPlum
PR: https://github.com/backdrop/backdrop/pull/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
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.
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
- [x] 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:
-
[x] 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".
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.
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.
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.
I like the first:
- Apply these settings to all items of this content type.
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.
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?
what's supposed to happen with content where first comments were allowed and then were globally disabled by the setting? - https://github.com/backdrop/backdrop-issues/issues/3016#issuecomment-377905554
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: https://github.com/backdrop/backdrop-issues/issues/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.
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 https://github.com/backdrop/backdrop-issues/issues/3016#issuecomment-378429837:
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 ?
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?
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.
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:
-
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.
-
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.
-
A matrix of comment-related permissions.
-
???
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:
- sets the comments for all nodes of the content type to "hidden" (to account for possible past comments)
- removes the entire "Comment settings" vtab in the node edit/create form for the content types where this setting is enabled
- 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").
I'm pleased I searched before adding this myself as it's exactly what I was thinking is needed.
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)
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 https://github.com/backdrop/backdrop-issues/issues/3001 should influence the concept. The option to close comments after a certain time span was quite new when this thread here started.
@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.
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.
This is a popular feature request, has an existing PR, and is relatively simple to achieve. Is anyone interested in being an advocate for Backdrop 1.33.0?
@quicksketch Thanks for reviving the issue. I think first it needs more discussion. The PR is from April 2018, then the discussion went into different directions, questions were raised and not answered with consensus. To me it's not yet clear what we're trying to achieve: Hide comment settings, or disable comments?
Starting with a comment by @klonos the discussion is moving towards 'truly' disabling comments. However, I feel we still need a better description of the goal. Maybe discuss it at one of the next weekly meetings?
We discussed the topic with a small group at yesterday's dev meeting (which wasn't recorded) and came to the conclusion to focus the request on the simple use case mentioned by @yorkshire-pudding, https://github.com/backdrop/backdrop-issues/issues/3016#issuecomment-1012964541:
my use case is more about setting up content types that will never have comments; I'll want to simply disable for content type. (...) Most content types in my sites don't have comments so it would be at the start.
The goal would therefore be more or less the same behavior as when disabling and enabling the Comment module – only not completely, but for selected content types. Even though this use case is relatively simple, some questions need to be answered, e.g. "What should happen with existing comments?".
Suggestions for next steps:
- Document what happens when one disables and re-enables the Comment module.
- Make a new pull request. (The existing one is very old and has an outdated approach.) Is anyone interested to give it a try?
After reading through this discussion I've come up with the following user stories which I think summarise the different ideas people have for this functionality:
User Story 1: As a site admin, I want to completely disable all comment functionality on a given content type, so that admins and editors never see comment settings for that content type, and comments cannot be posted to nodes of that type.
User Story 2: As a site admin, I want to enforce whether comments are open/closed on a given content type, so that editors cannot change this setting on a node-by-node basis.
User story 1 seems to be what @serundeputy, @klonos and @yorkshire-pudding are wanting. User story 2 seems to be what ghost is wanting. What @jenlampton described seems to be different altogether, and could be summarised as wanting the ability to bulk open/close comments on nodes of a given type.
Based on what @olafgrabienski suggested, it sounds like this issue should focus on User story 1, and User story 2 can become a separate issue.
Assuming we go with user story 1, as for the question of what happens to existing comments on nodes when commenting is disabled for that content type, I suggest that they are hidden/removed, but not deleted from the database.
For example if you have the Post content type with commenting enabled, and a post node with 3 comments on it, when you disable commenting on the Post content type, those 3 comments on the post node should remain in the database but be hidden when viewing that post node. All comment settings (checkboxes, vertical tabs, etc.) should be hidden. Then if/when commenting is reenabled for the Post content type, everything can go back to how it was with no data loss.
Document what happens when one disables and re-enables the Comment module.
It's exactly like I describe above. All settings and comments are hidden, but remain in the database. So when you reenable the module, everything goes back to how it was.
So we need to replicate disabling the Comment module, but only for a specific content type.
I made a PR for this. It's basically the same as @serundeputy's.
The 'Default comment setting for new content' setting used to be called comment_enabled, but now it's called comment_default. However a default value for it was left in the code when it was renamed, so I've used it as the name for the new setting. https://github.com/backdrop/backdrop/commit/139dca8d0258e56b4e8d8b632dfec603a8468e37#diff-31b1a81299c28c61f5516b680c405a43bcc441803f38fa6d3a98692c3efce552L1144
There was also a code comment from Drupal that no longer applies, so I removed that.
Thank you @NormPlum!
What you and @olafgrabienski have described sounds like the best goal here to me too. That is:
As a site admin, I want to completely disable all comment functionality on a given content type, so that admins and editors never see comment settings for that content type, and comments cannot be posted to nodes of that type.
This sounds good to me!
Regarding @olafgrabienski's comment:
Even though this use case is relatively simple, some questions need to be answered, e.g. "What should happen with existing comments?".
IMO the most reasonable and safe thing to do would be to hide all existing comments from all users, including administrators. If they have disabled comments, they should be entirely hidden, just like disabling the Comment module. However, the comments are not deleted, they still exist in the database (again this is just like disabling the module but not uninstalling it). If comments were re-enabled on a type, all the previous comments would be restored.
Deleting all comments on a content type I think can be left to a separate issue (or contrib).
Thanks for the PR, @NormPlum ! I've had a look at the sandbox site, and the basics work fine: If comments are disabled on the content type level, people are not able to post comments, and existing comments are hidden from the node display. When comments are re-enabled, people are able to post comments, and existing comments appear again.
Question: I've noticed that comments are by default disabled for all content types. Should they be enabled for the Post content type?
I've also noticed two places where disabling comments on the content type level shows different results in comparison to disabling the Comment module:
(1) When comments are disabled for a content type, on the page "Manage comments" (admin/content/comment) the comments related to that type are still linked in the list, but the link goes to nonexisting comments, e.g. example.com/comment/3#comment-3.
(2) Comment related tabs on the content type configuration pages (e.g. admin/structure/types/manage/post) are still visible, see screenshot:
Addendum: After disabling and re-enabling comments first on the content type level, then on the module level and again on the content type level, some Posts show a very strange behavior: When you view those Posts, you only see the title, not the body. Instead of the body, there is the embedded display of another post. See e.g. https://pr5166-wjrq8iazwnfy8vnj8eig8z7mph6gylcv.tugboatqa.com/posts/hello-test. Its body content isn't visible, and it shows another post below. Screenshot for reference:
I moved this into the 1.33 milestone and put @NormPlum as the advocate in the issue summary (thank you!)