| Project: | Drupal core |
| Version: | 7.x-dev |
| Component: | menu system |
| Category: | task |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed (duplicate) |
| Issue tags: | Needs usability review, Usability |
Issue Summary
I think it would be a nice big usability improvement if the menu section in the node creation/edit form was configurable per node type. I'm guessing that on your average install only the "page" node type is used in the menu tree, but still the menu section pops up on every other node type. The current ways to get rid of this is unsetting it via hook_form_alter() in a custom module or use something like formfilter.module. Both ways are pretty non-trivial for a new Drupal user.
I've created a simple module that does this for 5.x/6.x/7.x as a proof of concept: http://drupal.org/project/menuless_nodetype
I think this would both improve the usability on the admin side ("how do I get rid of that?") and the content editor side ("do I need to add my article to a menu?").
I had a look at node.module and menu.module and it seems that if the settings should appear on the node type creation form (not just when editing an existing node type) it would be tidy to add it to content_types.inc, but that would make node.module (a required module) dependent(ish) on menu.module (not required). An alternative approach would be adding hook_form_alter voodoo to menu.module.
I've attached a screen shot of menuless_nodetype.module's config section.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| menu-per_nodetype.png | 27.1 KB | Ignored: Check issue status. | None | None |
Comments
#1
I would rather prefer that Menu Settings per Content Type become part of D7. See the Menu Settings field at the end of this screenshot:
#2
Ah, my Google Fu was obviously too weak to find that one. To clarify, I'm not advocating the inclusion of any specific module per se, I just think that adding the possibility to easily disconnect a node type from the menu system would be a great thing.
Conceptually, I think we should be asking "should this node type be used in menus?" while ctm.module asks "which menus would you like to use this content type in?".
My concern is that while the higher level of control that ctm.module provides might be very useful for some users it could unintentionally push the idea that multiple menus are a common (or even necessary) way to structure your content and that this should be done with multiple content types (e.g. "footer menu page", "header menu page", "primary links page").
I'm sure this level of control is super useful in some situations, but I've build a lot of sites and I haven't found myself needing it yet.
#3
Bump.
We should just add the variables to core, and let contrib modules (or form builder if it gets into core) handle the UI for this.
#4
#186707: Menu settings fieldset on node form should be by content type and #503784: Make menu node form integration a variable per content type marked as duplicate.
#5
+1 for me from one of the "duplicates".
@catch: I don't understand your comment about having someone else do the UI. To me, this is a relatively self-contained issue and the simple UI that I see should be handled by the menu module, as most would undoubtedly expect any of my modules to do.
#6
I'll give it a go....
#7
+1!
#8
The other thing I'd like to see here (not sure if it's part of this issue or not) is the ability to mark a menu selection as being required for a content type.
This would eliminate 90% of the WTFs with the Page content type.
#9
In case anyone is looking at this, I have a nearly complete patch I'll post when my power comes back on. (thunderstorm has me on phone only mode)
#10
This patch allows content types to have no menu settings, optional menu settings or required menu settings. The default profile is set to require menu settings for page nodes and disable menu settings for article nodes.
#11
I did a quick code review (without applying the patch and testing its functionallity):
This review is powered by Dreditor.
+++ modules/menu/menu.install 10 Aug 2009 03:28:58 -0000@@ -33,6 +33,9 @@ function menu_install() {
+ $setting = variable_del('menu_content_type_' . $type);
variable_del does not return anything. No need to assign "nothing" to an unused variable.
+++ modules/menu/menu.module 10 Aug 2009 03:28:58 -0000@@ -388,17 +388,42 @@ function _menu_parent_depth_limit($item)
+ '#options' => array(
+ '0' => 'No menu settings',
+ 'optional' => 'Optional menu settings',
+ 'required' => 'Required menu settings',
+ ),
Use t() for the options.
And
0 => t('No menu settings'),.+++ modules/menu/menu.module 10 Aug 2009 03:28:58 -0000@@ -388,17 +388,42 @@ function _menu_parent_depth_limit($item)
+
Minor: remove spaces
+++ profiles/default/default.profile 10 Aug 2009 03:28:58 -0000@@ -156,6 +156,10 @@ function default_profile_site_setup(&$in
+
Minor: remove spaces
Apart from the point noted above: +1!
#12
How is this much different than #351249: Finer control over the Parent Menu select box ?
#13
@Bojhan: hah, I knew someone would notice this :-)
From a quick view I would say: duplicate!
#14
Ugh. Dang it all. I searched the queue because I knew there was something somewhere about this, and found this issue but did not find the other. :(
@Jody Lynn: I'm really very sorry for wasting your time. :( However, it doesn't look like the other patch does the required bit. Any chance you could combine your patch with the one in the other issue?
#15
Yup the required part, sounds like something we want to do! And also makes this functionality far more interesting :)