This patch adds a new option to the admin/settings/menu page, which allows the 'menu settings pane' in the node add/edit screen to be enabled or disabled. This is an important patch for menu OTF (on-the-fly), as many users may not want the menu settings pane showing up in all their node forms. Some users may simply feel that it adds clutter to the already bulging node form, while others may not want it showing from a usability perspective.
The wording for the settings explanations have been changed a bit, and should be reviewed. Also, this patch makes the display of the menu settings pane set to 'disabled' by default. I feel that this is the correct behaviour. Others may feel differently - either way, feel free to put forward your thoughts on the matter.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | menu_otf_toggle_2.patch | 2.05 KB | Jaza |
| #9 | menu_otf_toggle_1_0.patch | 1.93 KB | Jaza |
| #3 | menu_otf_toggle_1.patch | 1.64 KB | Richard Archer |
| #1 | menu_otf_toggle_0.patch | 1.53 KB | Jaza |
| menu_otf_toggle.patch | 1.97 KB | Jaza |
Comments
Comment #1
Jaza commentedNew patch that adds the toggling option to the per-node-type workflow settings, rather than to the main settings page. This is for consistency with other options on the node add/edit form, such as comments and attachments (also increases flexibility and usability). Default is now 'enabled' - mainly for consistency with comments and attachment settings.
Comment #2
Richard Archer commentedThis is the last remaining feature from the original menu_otf that I really miss in core.
I tried implementing this as a menu setting, but this solution is much more elegant. Well done!
This update just adds a phpdoc comment on the hook_form_alter function.
Comment #3
Richard Archer commentedOops!
Comment #4
dries commentedI'm not 100% this is needed. I'm tempted to put this 'on hold' for a while, until there is strong support for this patch.
Comment #5
venkat-rk commentedAs someone using menu OTF, I was wishing for exactly this same option once I had added my static pages to the site. I can't speak for everyone, but I think it is fairly safe to say that most sites don't add static pages on a regular basis, so once it is done, the menuOTF pane on every node form is rather annoying.
Sure, I can disable it for a role from access control>>permissions, but a toggle option in the admin area is easier to find and use rather than hunting for this checkbox out of hundreds on the access control page. This patch would certainly improve usability, IMHO.
Comment #6
Tobias Maier commentedcant we hide the menu-otf-stuff with the form-api?
we can theme the different forms so we can hide it too
Comment #7
Jaza commentedTobias: you "could" hide menuOTF with the forms API - either by theming the form with a function that returns an empty string, or by using the _form_alter hook to manually unset the menuOTF form elements - but doing so would be a dirty hack, and would not be accessible to non-coders. I also don't see how it could emulate the per-node-type flexibility of this patch.
Comment #8
dries commentedPostponed for now.
Comment #9
Jaza commentedNew patch updated for latest HEAD. I urge you to reconsider your position, Dries. Many people have already given their support for this patch, and it is a small but usability-enhancing change.
Comment #10
Jaza commentedOops.. forgot to merge Richard's PHPdoc comment into the last patch.
Comment #11
chx commentedFor the record: I like this functionality.
Comment #12
Richard Archer commentedI wonder if http://drupal.org/node/38777 isn't a more general-purpose way to solve this problem?
Comment #13
Crell commentedIt would, for everyone except UID 1. :-)
Comment #14
Richard Archer commentedIf someone is using UID 1 then they should expect to see some extra features that aren't available to other users.
I think this feature adds more complexity to the admin interface than it's worth. I would prefer to see this type of rarely-used setting in a contrib module... in this case using hook_form_alter to remove the menu_otf pane from the node edit form.
The other issue http://drupal.org/node/38777 on the other hand needs to be in core because it is adding a permission... as far as I can see a module can't add a permission to another module.
Comment #15
Jaza commentedI really don't agree with you, Richard, when you say:
I find that idea quite absurd. Why should users have to download a contrib module, in order to turn off a feature that they don't want in a core module? Menu.module is the one that has the functionality, it should also be the one responsible for allowing that functionality to be disabled.
I'm personally finding that the menu_otf functionality is increasingly getting in my way and serving to irritate me. The rest of menu.module, however, is great. Surely this patch is a better approach than creating a menu_otf_disable module? But if I have to make such a module, I will.
Comment #16
Richard Archer commentedI plan to create a module which adds a bunch of extra settings to menu.
There are a lot of options that menu items can have which have no admin interface, and the issue which addressed that problem died: http://drupal.org/node/29621
This issue also was effectively killed off by Dries, and as I pointed out earlier in this issue, this is functionality I sorely miss from the 4.6 menu_otf module, so it will also go in.
Hopefully these add-on features will slowly migrate into core.
Comment #17
gerhard killesreiter commentedRichard is the menu maintainer, it can be achieved in a contrib module, and I don't like it either.