Hi,

I was just about to start writing a module to list menu items by menu, showing path and page callback to make sense of a really muddled site I'm working on when I found your module. The editing features you've included are a great help. To make the module useful for me I wanted to see where menu items had been created (e.g. node / view / module). I've attached a patch that displays the page callback if anyone else needs it.

As far as future features are concerned I'd really like to see all menu items including ones which override others. In a couple of sites I've had serious chaos where PMs are creating views which create menu items already created by pages etc. I haven't taken the time to work out if the menu editor would show them all in it's current state or if it just shows the 'overriding' item.

Also I would love to see a link to edit the view or node that creates the item.
Ultimately being able to edit or remove menu items created by views directly in the menu editor would be a great help but I imagine there is some considerable work to find out what needs changing in the views tables to make that reliable.

If you think this stuff is overkill for the module in it's normal state I could add a setting like 'advanced' which would enable the extra features for those that want to see them.

Thanks very much for making this module. I will continue to submit patches for functionality I find useful.

cheers

marcus

CommentFileSizeAuthor
menu_editor-6.x-1.0-admin.inc-add-page-callback-column.patch3.36 KBmarcus_clements
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

donquixote’s picture

donquixote CreditAttribution: donquixote commented

Hey.. I think your ideas make sense, but they are too special to turn them into native features. Now, my own brainstorming.

Some aspects that I think about when reading your post:

Path aliases (usually for node paths).
The menu editor form shows the node/[nid], but you can always hover the link to the node to see the alias. For these paths it is very likely that you already know the page callback (node_view).

Views paths.
These are special, because they allow fully customizable paths which are not aliases. Maybe there are other modules like this, I can't think of any at the moment.

Nodes creating their own menu items.
Menu items created via the usual node edit forms are just normal menu items, afaik. The node form is just another way to edit these items. You can create them in the node edit form, and delete them in the menu editor, or vice versa.

Views creating their own menu items.
Views create paths, but they can also create menu items. And as far as I know these menu items are special: You can not easily delete or modify them with the menu editor form. Or am I wrong?

----------

Possible features:

Extra columns with links and information.
Yes.. this reminds me of a comment complaining about horizontal space limitations.
#653552-6: Community Feedback for Menu Editor

One solution I had in mind was to have collapsible table columns. If we really want to add more columns, we have to seriously think about such a feature.

Possible extra information that could be displayed in an extra column:
- Node edit links.
- View edit links.
- module, system path and page callback. (in many cases this will just be node_show)
- node type
- url alias
- access information: who can see this menu item
- language information.

And instead of just information, there could even be interactive elements, such as:
- url alias editing integrated into the menu editor form.
- Editing menu items created by views. I think this would make a lot of sense, but I have not yet studied how exactly these items work, and which tables I would need to edit. If you could give me a hint, that would be nice!

---------

Submodule approach.
Instead of adding things like these into the module itself, I would prefer doing this in separate modules or submodules.
These submodules could work with hook_form_alter, or I could introduce new hooks to make this kind of stuff easier.

Looking at the code again, I had the following idea:
- I don't want to make the callback a new form element, as suggested in your patch. It can happily live in the presentation layer, it does not affect the form mechanics at all. And it doesn't need a #default_value.
- Store the full menu item information in $form[$item_key]['#_menu_item'], to make it available to hook_form_alter() and hook_preprocess_menu_editor_overview_form().
- Restructure the theme_menu_editor_overview() function, and provide a module hook or theme preprocess hook that allows to easily add or modify table columns. I'm still thinking about this one.

-------------

A note on the system navigation menu.
This menu is different from the others, because it is generated from the menu_router table. Probably this would make everything even more complex. I prefer not to touch it.

marcus_clements’s picture

marcus_clements CreditAttribution: marcus_clements commented

Before spotting your module I was planning to display a large table based on the menu_router and menu_links tables to try and make sense of the menu structure in sites where the process of creating the menu has gone wrong due to bad planning and inexpert staff.

Right now what would be useful for me would be:

  1. Identify how existing (visible) menu items were created (node/view/module etc.) so they can be edited and managed. Including the page callback column was the first step towards this - you've mentioned other things.
  2. List broken or orphan menu items with same info.
  3. Provide links to the edit page for the relevant node or view (or line in code?) for each of the menu items.
  4. Provide inplace editing where possible for each of the menu items.

I appreciate all your points and completely agree that the functionality we are now discussing is advanced and should not be included in the menu_editor main table/form by default.
Storing all the data in the $form[$item_key]['#_menu_item'] sounds like a good way to go to me. If we go down that road then I'll write a dependent module which displays all the info and just let people deal with having a large table in their theme for now. Since the full table is for devs only I'd expect them to have a hi-res monitor and know how to disable blocks or regions for a specific set of pages if necessary. Collapsing columns sounds good, and I do need to do that on another project but is a 'nice to have' IMHO.

Do you have time to do the $form[$item_key]['#_menu_item'] in the near future and commit it to CVS? If not let me know I'll have a go in the next few days.

In addition my understanding of the relationship between menu_router and menu_links is not complete, so how much work do you think needs to be done to show broken and orphan links?

It's interesting what you said about the navigation menu because one of my sites has a whole load of spurious disabled menu items which I think were created by some bad code in hook_menu and I'd really like to identify and edit or remove them via the functionality discussed above.

Anyway I'm happy to put a bit of time into this over the coming weeks and submit patches from time to time, based on your suggestions for how best to incorporate the functionality.

donquixote’s picture

donquixote CreditAttribution: donquixote commented

Do you have time to do the $form[$item_key]['#_menu_item'] in the near future and commit it to CVS? If not let me know I'll have a go in the next few days.

If you can wait a few weeks, then yes - I have some other work to do in between.

There is another half-finished feature,
#666644-1: Path Autocomplete for Menu Editor
This thing required me to change the names and ids of the form elements, and I think it is a bit buggy. I would like to finish this renaming and make it stable, so we can build on that modified version. Maybe you can help me testing, or identify bugs :)

donquixote’s picture

donquixote CreditAttribution: donquixote commented

"wait a few weeks"

BS.. here is the new snapshot :)
[no no no]
(waiting for packaging script)

EDIT:
Forget the above.

marcus_clements’s picture

marcus_clements CreditAttribution: marcus_clements commented

Burning the midnight oil señor Quixote ? ;-)

That link throws me an Access Denied.

donquixote’s picture

donquixote CreditAttribution: donquixote commented

I made a bit of chaos with CVS and release nodes.
To get the newest code, you can either wait for the packaging script for the 6.x-1.x-dev snapshot, or you can get it here:
http://drupal.org/node/695426
Yes, 1.1 ist the newest and not recommended for production code. 1.2 is back where 1.0 was.

EDIT:
Finally it's out in the latest 6.x-1.x snapshot.

@rayvaughn:
There is a new hook for you to play with :)
hook_menu_editor_overview_table_alter()

The hook is called from within theme_menu_editor_overview_form(), and allows to modify the data sent to theme('table').

mlncn’s picture

mlncn CreditAttribution: mlncn commented
Issue tags: +dgd7

@rayvaughn done this?

When Menu Editor is ported to Drupal 7, i think it would make sense for Xray module to implement hook_menu_editor_overview_table_alter() and do this.

donquixote’s picture

donquixote CreditAttribution: donquixote commented

For the record: I am getting closer to a more stable version of multicrud, which will make it possible to add new columns in a much funkier way than menu editor's hook_menu_editor_overview_table_alter().
This is all D6, but I hope if it is running smoothly I can port it to D7 soon.

apaderno’s picture

apaderno
he/him
Primary language Italian
Location Brescia, 🇮🇹 🇪🇺
CreditAttribution: apaderno as a volunteer commented
Version: 6.x-1.0 » 6.x-1.x-dev
Status: Active » Closed (outdated)
Issue tags: -dgd7

I am closing this feature request, as it's for a not supported project version. If you want to see this feature implemented for a supported project version, please re-open this issue.