Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Fresh commons 7.x-3.0 install, I disable both the "Commons Q&A" and "Commons Q&A Pages" modules, but there is a link on /node/add to create both of them!
I'm not asking for them to be hidden, as you could just use the url get where you create them. They should just not exist when I disable that module. Commons is already hidding stuff (there is no question or answer in the "Create X" menu on group pages, and there is not such a menu at all on group pages when you're anonymous), but you can still access it. That's a terrible security failure.
I set this bug to critical priority because it's not only with Q&A but it seems to be the usual way to work on commons, and that *should* change if you really want to make something good.
It looks like drupal people forgot about KISS (Keep It Simple Stupid) and the UNIX philosphy:
Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.
Comments
Comment #1
japerryContent Type features in Drupal are designed to add functionality, not remove it, due to potential data loss. We cannot remove the content type when the module is disabled, nor should we, as this would go against normal use cases with features.
While we may visit being able to selectively enable a feature at install time, administrators need to manually remove content types and any potentially associated content with them. When you remove a CT, its menu entry will go away.
Comment #2
Dani_what commentedOk, I understand that, but shouldn't Content Types be marked as "enabled" and "disabled", or something similar, so that you can decide which of them can be used without actually removing them? That'd be useful if I want to enable the creation of some content types temporarily, or disable them but keeping the content, etc. I maybe could do something similar using permissions, but I don't want people to get a 403 error that could be confusing, but just take it out from the menus and give them a 404 if they use the url.
BTW, I went to /admin/structure/types and there is not "delete" link for CTs created by modules, so I shouldn't be able to remove them, thus your answer shouldn't help me get rid of undesired CTs. Luckily, that is one of those "hidden" things, and I could remove questions and answers through /admin/structure/types/questions/delete and ......./answers/delete.
Anyway, thank you for your answers.
Comment #3
japerrysorry, as I was driving today I realized that the 'locked' attribute is still set on the content type. It might be reasonable to allow CTs to become 'unlocked' when we disable AND uninstall the module. I still think the best idea is a selective 'enable' at the start, but I'm not sure what complexity that'd add to our UX experience during install.
As far as CT enabled/disabled, this isn't currently possible in drupal 7 or 8. The closest you can get to disabling them is setting restrictive permissions so only user 1 has access to them.
Comment #4
ezra-g commentedReclassifying as a feature request per #3.
Comment #5
Dani_what commentedComment #6
peezy commentedUntil this feature request is implemented, you can also adjust the create permissions for questions and answers content types at /admin/people/permissions.
Comment #7
devin carlson commentedI've run into this issue in the past. This is a core bug #1441950: Node types removed from hook_node_info with base = 'node_content' cannot be deleted that people most often encounter through features #1055460: Disabling a feature does not disown content type as
hook_node_info()is rarely implemented manually.Marking this as a duplicate of those issues as they are relatively major (currently ~130 followers) so I don't think that this should be up to Commons to fix.