[drupal-devel] [feature] Menu fast edit node links
Dries
drupal-devel at drupal.org
Tue Mar 29 14:06:03 UTC 2005
Issue status update for http://drupal.org/node/9178
Project: Drupal
Version: cvs
Component: menu system
Category: feature requests
Priority: minor
Assigned to: mathias
Reported by: mathias
Updated by: Dries
Status: patch
Yes, we need something like this in core but as explained, there is a
depency on the new node form (and collapsible form/page elements in
particular). Is anyone going to work on this? I'm determined to help
get this in core ASAP but can't take a lead in this. Takers?
Dries
Previous comments:
------------------------------------------------------------------------
July 9, 2004 - 19:15 : mathias
Attachment: http://drupal.org/files/issues/menu_fast_edit.patch (1.18 KB)
When developers are creating custom menus, the process of adding content
becomes twofold:
1. Create content
2. Navigate to administer > menus > add menu item and add the latest
node entry
This patch adds a link hook to the menu module. Specifically if a node
does not have a menu entry the 'add menu item' link appears. If a menu
item exists, the 'edit menu item' and 'delete menu item' are displayed
thereby speeding up the publishing workflow.
Note: This feature is only present when the menu module is enabled.
Status: Waiting for JonBobs blessing ...
------------------------------------------------------------------------
July 10, 2004 - 19:21 : JonBob
This is interesting. I do have a couple reservations.
This adds a bunch of queries to node listing pages, since it has to
check for every node whether that node has a menu item set.
I also wonder how much time this saves the user in reality. It saves
navigating to the menu admin screen, sure, but provides little other
help. It seems that if we are to provide a link to the menu item add
page, we should at least be pre-filling in the path and title fields
for the user. The provided method is little better than having the menu
admin page open in another browser tab.
Maybe a node link isn't the right interface for this, anyway? Possibly
a tab, or a hook_nodeapi('form admin') injection? If done right, this
could finally replace that aging "link title" field in page.module
nodes.
------------------------------------------------------------------------
January 24, 2005 - 23:23 : mathias
Attachment: http://drupal.org/files/issues/menu_quick_link.patch (5.91 KB)
This new patch gives users the ability to define menu items on any node
creation/editing form. Screenshot here:
http://asitis.org/tmp/menu_quick_link_form.png [1]
It does this through nodeapi (as suggested by Jonbob), which means that
any node has access to these fields unless specified otherwise via the
new menu configuration settings.
The functionality lives in menu.module, and users with 'administer
menus' permission are allowed to edit the menu item fields inside the
node form.
One more note. I'm also proposing the addition of a misc/drupal.js [2]
file to Drupal core (* gasp *). Currently it includes javascript
functions to hide regions of a page. When a link is clicked on for a
collapsed region, the region unfolds revealing the additional parts of
a page. In this case the menu item fields are displayed after clicking
the 'Menu item settings' link. I think it helps make best use of screen
real estate, but we'll leave that verdict up to the usability experts.
Let's remove the js file if it's the only thing stopping this patch
from being submitted. I thought it might be worth exploring, especially
for form pre and form post regions of the node form.
[1] http://asitis.org/tmp/menu_quick_link_form.png
[2] http://asitis.org/tmp/drupal.js
------------------------------------------------------------------------
January 24, 2005 - 23:34 : mathias
Woops. Setting status to 'patch'.
------------------------------------------------------------------------
January 25, 2005 - 15:17 : Bèr Kessels
+1 on the feature, I use menu_otf all the time.
-1 for the javascript. Not that i am against it, ion contrary. I think
we should not start implementing JS on a per-case basis, but we should
introduce a javascript system that can do your accordeon-magick on any
element.
So it should wait IMO.
------------------------------------------------------------------------
January 25, 2005 - 17:07 : Dries
I agree with Ber: +1 for the feature, -1 for the Javascript. This would
(or should) be easy to implement/integrate as soon the new node forms
are done. Both the new node forms, and this feature are crucial.
------------------------------------------------------------------------
January 27, 2005 - 22:39 : mathias
Attachment: http://drupal.org/files/issues/menu_quick_link_0.patch (4.12 KB)
Okay, here's the latest patch, footloose and javascript free.
------------------------------------------------------------------------
February 1, 2005 - 10:04 : robertDouglass
+1 to the feature, with or without javascript.
The Menu item title:* is showing that it is required, but it can't be
required as that would force users to create menu items (and it doesn't
validate to be required).
The patch does, however, open up a big can of permissions worms, and
lacks configuration. I would like to see a checkbox on the Workflow
(/admin/node/configure/types/{type}) page so that I can hide this on a
per-type basis.
Then, I think we need some way of limiting this by role, by user, and
by menu. I would at least want an "excluded menus" list where I could,
say turn off the main Navigation menu so that people don't go and trash
it.
Very cool feature in a very important direction! I sincerely hope this
makes it into the code freeze.
------------------------------------------------------------------------
February 3, 2005 - 00:37 : Anonymous
I removed the required mark next to menu item form field. Thanks for
spotting that.
I don't completely understand what you mean by this patch 'opening up a
big can of permissions worms'. User's with 'administer menus' permission
are simply given an easier way to add menu items while creating content.
I think it's better to keep it simple to begin with.
http://asitis.org/tmp/menu_quick_link_form.png [3]
There actually is a configuration interface (settings/menu). Your menu
cache probably needed to be cleared after applying the patch :-) On
that page you can choose which node types acquire the quick menu item
form field as well as define the default menu item.
I disagree with putting the menu item form visibility settings on the
admin/node/configure/types/{type} page. Those settings are for the
default state of the node instance, not what's visible on the form
field. For example, I wouldn't want to see a list of all 'form pre'
and 'form post' fields on that page to select from, but it could be
useful as a standard interface elsewhere.
[3] http://asitis.org/tmp/menu_quick_link_form.png
------------------------------------------------------------------------
February 3, 2005 - 00:40 : mathias
Last comment by 'learning to login' mathias.
------------------------------------------------------------------------
February 6, 2005 - 12:23 : Dries
I'm going to put this on hold until the collapsbile form groups [4]
settled. I encourage you to participate in the design and discussion
so that it meets your requirements. The same should be done for other
parts of the node edit form, so let's try to come up with a generic
solution that can be used through an API that shields you from all
Javascript details.
[4] http://drupal.org/node/16204
------------------------------------------------------------------------
March 14, 2005 - 00:13 : killes at www.drop.org
Hmm, should we have a status "on hold"? I am unsure what to do with this
one. It still applies.
------------------------------------------------------------------------
March 29, 2005 - 12:15 : TDobes
+1 on this... trying to explain to users that they need to add their
pages, then add their pages to the menu system (and explain why) was
incredibly difficult... menu_otf has helped with this, and I think this
sort of functionality really belongs in core.
More information about the drupal-devel
mailing list