Allow admin to place menu items into primary links or other menus.

#1 go to admin menus and place it where you like once it's been created.

#2 is a bit advanced, as nodes could be 'owned' by any number of views so may appear in many menus if you tried that. When you are viewing one of those nodes, what would the menu parent be?
And it's trickier still for other dynamic reasons and the way that menus are created and cached.
A few earlier attempts (taxonomy_path, taxonomy_menu) hit lots of snags, and 'views' is even harder than that. It's probably possible to come up with a feature request that could address just one instance or special-case hack, but to properly do that in the general case is probably really hard code. Good luck with that!

I'd like this too,. Saves a few clicks.

#1: hook_menu() does not allow for menu placement. To do this you have to do direct database manipulations and that is simply impossible for exported views, so it is not possible for Views to do this.

#2: That is the kind of thing that would need to be done by another module. Views cannot do this.

D6 actually allows this easily. Here is a small patch. There is a bug in core which which cripples this a bit. The choice you make for a custom menu only works during menu item creation. It is ignored for updates. chx and pwolanin are working on a patch now. The item's menu change will be respected unless the admin has explicitly customized the item in menu admin.

one more try

Very good. It's an intuative enough request, and makes sense on the UI.
No reason why not (apart from more clutter on that horrible screen :-B )
Good one!

Ok, I am in favor of this but if there is a bug that prevents this from working for updates, I am leery; that's the same situation we have in block caching and it's *very* confusing.

Can we link to an issue about said fix? Maybe once that's in we can commit this.

dman: While I'm completely amenable to specific criticisms and or suggestions regarding the UI, I would appreciate it if you'd refrain from casual snipes at it. An unbelievable amount of work from many people went into this UI and I understand if you may not like it, but such comments disrespectful of that effort, smiley or not.

@merlinofchaos - the patch is in at #285309: menu_name in hook_menu is ignored on updates. yes, it makes sense to commit this after that gets in.

@merlinofchaos Apologies if you took that personally. I just think that the views edit interface is one of the most intimidating I've ever seen, and my only thoughts about this feature request were that it would add even more widgets to it, which (I think) should be done conservatively.

I totally appreciate the power underneath it as I'm sure you know, but can you imagine my face the first time I ever tried it out, js off?
In lack of any constructive improvement suggestions (sorry, I don't have any) I just have to apologize in advance each time I tutor someone into it. It's scary, that's all I'm saying. You can disagree.
[/off-topic]

dman: Well, we put a lot of work into it (and it works with js off) and it's meant to be something you can take in very small chunks.

I mean, look at the Views 1 interface. I have trouble believing you can think this is the most intimidating UI you've ever seen having already used Views 1, which is a nasty, gnarly mess of collapsed fieldsets full of stuff with no real sense of where anything is. :/

My patch was more complex than needed. Here is a happier one.

#285309: menu_name in hook_menu is ignored on updates is almost in. I have not forgotten about this.

Finally, the dependant bug fix is committed. This one should be RTBC now.

Here's the current version of this patch. It didn't make it in for 2 reasons:

Need 6.5 to be released
Needs to also function on menu parent tab normal items.

in terms of rendering local tasks, that's all based on the router table, so Drupal won't care where or how many links there are. There are added to the links table in order to construct the active trail, so they should probably always move together with whatever the parent link is.

I don't think it would make any sense to let the user move the tabs separate from whatever page they derive from.

If I read pwolanin right, he is agreeing with the patch - there is no utility in letting tab menu items choose a menu to attach to. If I'm wrong, please elaborate.

I'll move this along once 6.5 is out. Thanks for the reroll.

I'm talking about the menu tab *parent* which can be a normal menu item, which Views can create in addition to the tab if it's a default tab.

As per Earl's request, here's a version of the patch that gives a warning on versions of Drupal earlier than 6.5. Works great. Thanks for the great patch!

Committed. THanks Drupal 6.5!

sorry. cross post

subscribe