Some of the functionality from menu_otf.module has been merged into core for 4.7.0. But there are some additional features of menu_otf which significantly increase the usefulness of the Menu item settings on node/*/edit pages.
The attached patch adds some extra functionality to menu.inc, as discussed at http://drupal.org/node/31896
My goal is to allow non-technical users the ability to completely manage a site navigation menu without ever needing to access the administer > menus page or to see any of the administrator-only menu options.
An administer > settings > menu page has been added. On this page the Administrator can control which options are available on the node/*/edit pages. The settings are:
- On which node types will Menu item settings be available. Useful if (for example) stories were to be shown only as snippets within another node and never to appear in the menu.
- Whether the users can control the weight of the menu item.
- Whether new menu items will default to expanded. This is merely a convenience.
The top-level menu available to users as the parent of a node. This is the most important and most complex setting. At present every menu item known to Drupal is available as the parent. This is very confusing to users.
And on the menu item settings form some extra options have been made visible. Users can now control:
- Menu item title
- Menu item description
- Expanded
- Parent item (within administrator-controlled limits)
- Weight
- and delete the item.
This encompasses all the functionality available through administer > menus with the exception of:
- Changing the Path (which is not useful in this context)
- Having two menu items point to the same node
This last point weighs heavily on my mind because once Primary and Secondary links are managed through the menu system it would be very useful to have (for example) a primary link and a navigation menu both pointing to one page. I expect this functionality to be added as part of the primary/secondary link patch.
| Comment | File | Size | Author |
|---|---|---|---|
| #27 | menu_node_edit_enhance_1.patch | 9.28 KB | Richard Archer |
| #22 | menu_node_edit_enhance_0.patch | 8.98 KB | Richard Archer |
| #21 | menu_node_edit_enhance.patch | 9.31 KB | Richard Archer |
| #20 | menu_node_edit_enhance_7.patch | 7.33 KB | Richard Archer |
| #19 | back_out_menu_otf.patch | 7.21 KB | Richard Archer |
Comments
Comment #1
Richard Archer commentedA screen grab of the administer > settings > menu screen
Comment #2
Richard Archer commentedA screen grab of the menu item settings panel.
Comment #3
dries commentedAny chance you can rework the primary and secondary navigation to use the menu system (rather than the theme system)?
Comment #4
Richard Archer commentedI've been working through a couple of easy-looking problems trying to get my head around the way Drupal works. I'll have a look at the links issue and see what I can come up with.
Comment #5
Crell commentedIf the primary/secondary links are moving into the menu system, one nice addition would be allowing the secondary link list to vary depending on what part of the site you're in. Currently it's useful only for "more universal links that get put somewhere else". It would be very nice to use it as truly secondary "sub menu" links. (Eg, you get one set of secondary links while under forum/*, another set under blogs/*, and another set while under foo/bar/*.)
I think the easiest way to do that would be to allow a given menu item to have an "only available on" dialog the way blocks do and the way the section module now does (see my recent patch to fix that up).
Comment #6
moshe weitzman commentednice patch. the checkbox for deleting should only appear if you are editing a menu item, and not when adding one.
Comment #7
Richard Archer commentedThe primary/secondary links system has its own issue at http://drupal.org/node/22215
Post all follow ups about links there please.
Comment #8
Richard Archer commentedI can't for the life of me see how the delete checkbox could show up if the user is adding a new node. Could you please describe how you made this happen?
I did spot a problem though... the user's entered values weren't being carried through if they hit Preview. This is a bug in HEAD. I'm hoping this patch will make it into HEAD before 4.7.0. If this isn't going to happen let me know and I'll roll up a separate patch for this bug.
Comment #9
Richard Archer commentedHere's a revision of this patch updated to use the new Forms API.
Comment #10
dries commentedI don't understand why we need all those settings. If you give people the ability to administer menu's, you better trust them not to screw up. I'd add the 'weight'-option to the node submission form and get rid of all the rest.
Comment #11
Richard Archer commentedHere's a much simplified version of this patch. I think I have pared it down to the bare minimum:
If any more complex adjustments are required...well, that's what admin>menus is for.
Comment #12
moshe weitzman commentedI had a quick read through. Looks like a good idea.
You state "on all edit node pages". I think thats better said "On the node authoring form". This covers adding nodes as well. In the same description, I suggest putting 'primary links' in a theme('placeholder') so that text gets italicized. same for 'Parent'.
Should we still show all menus to administer menus folks? Just thinking out loud.
Comment #13
moshe weitzman commentedoops. Now I see that you need administer menus permission to see this section of the node form. Thats not what I was hoping for. I am happy to give permission to typical users of my intranet to their menu links but i wouldn't want to subject them to admin/menu. not a big deal though. i should have spoken up earlier.
Comment #14
Richard Archer commentedJust changes to the hints text in this patch.
Now uses 'node authoring form' throughout (including in the primary links hint text).
I put apostrophes around the titles to make them stand out. I had a look at the way theme_placeholder was used elsewhere and I think it would be poor form to use it as a general-purpose highlighting tool. I had used apostrophes just above in the Primary links help text so I retained that style.
Functionality changes are still as per #11.
Comment #15
eaton commentedSome of this functionality (and then some) is already in http://drupal.org/node/29621
Comment #16
Richard Archer commentedThis patch shares no functionality with http://drupal.org/node/29621.
Further, I doubt whether Dries will accept 29621 in its current form. The option to hide nodes from tree or breadcrumb are advanced, rarely-used options and should be available only through admin>menu. See his earlier comment in this issue.
Comment #17
Richard Archer commentedThis patch adds a text link to the 'Menu settings' pane to allow the user to quickly jump to the admin/menu/item/edit page for this menu item. This is only available if the node is being edited, not if it is being created. This will also work well with the other advanced settings proposed in http://drupal.org/node/29621
I still think adding weight and description to the Menu settings pane is essential. Every single link added to a site should have a description for accessibility. And weight... well, unless your clients aren't as fussy as mine, half your time maintaining a Drupal site is probably spent fiddling with weights.
Adding the ability to restrict where the new menu item is placed in the menu hierarchy improves the ease of use of the Parent item selector and also fits in really well with the Primary links feature.
Comment #18
dries commented- 'node' should be 'post'.
- 'Restrict Parent items to' should be 'Restrict parent items to'.
- '%menuitem' should probable be '%admin-menu-edit'. (We don't glue words together.)
- I dislike this part:
The old code seems to be a lot more elegant, and doens't expose menu system details in the form building code. Hairy. The rest of the code looks great.
Comment #19
Richard Archer commentedDries,
I think you accidentally committed this patch along with webchick's form defaults patch.
Here's a patch that backs out this patch but leaves webchick's in place.
Comment #20
Richard Archer commentedThat ugly code just added the root of the menu_parent_items menu to the options list, working around a shortcoming in menu_parent_options().
In this patch I have made extensive changes to the menu_parent_options function so that it adds the passed parent menu item to the tree and then recurses through children. The new code is not quite as compact but it is certainly easier to understand.
I have confirmed that the new function works for both use cases in menu.module and also with the contrib controlpanel.module.
Comment #21
Richard Archer commentedKeeping up with HEAD.
Comment #22
Richard Archer commentedditto
Comment #23
chx commentedWhy are using an item instead of markup? Item is something that has a title.
Comment #24
killes@www.drop.org commentedI don't quite see how this addresses the problem of circular path aliases.
Also, please do not used escaped sinlge quotes inside translatable strings. If you need single quotes, use double quotes for the whole string.
Comment #25
Richard Archer commented@chx: When you place a markup field inside a collapsible fieldset the markup is displayed even when the fieldset is collapsed. I don't want this to happen, so I use item which behaves as I would expect.
@killes: OK, I'll roll a separate patch for the other bug.
Comment #26
dries commentedPatch no longer applies.
Comment #27
Richard Archer commentedRemoved the apostrophes and rerolled.
Comment #28
dries commentedCommitted to HEAD. Thanks Richard.
Comment #29
Waldemar commentedHmm,
I don't get it, is there any reason, why the menu settings are being shown on each post authoring form even if the user doesn't have any access to administer modules? Same applies to the path module. I did put in an extra if clause in each of these to prevent these settings to distort the form for users that don't need them / can't use them.
I can submit a patch if needed.
Waldemar
Comment #30
Waldemar commentedI meant to administer menus not modules of course :) Sorry.
Comment #31
Waldemar commentedOne should read all issues before one is complaining. Sorry about that!
Comment #32
(not verified) commented