Download & Extend

Ability to add multiple menu parents per node in node edit Menu Settings

Project:Drupal core
Version:8.x-dev
Component:node.module
Category:feature request
Priority:normal
Assigned:Unassigned
Status:active

Issue Summary

Add features so that Menu Settings section of node edit page to allow entries under multiple menus per node

Benefit:Would no longer need retype Title and Description by adding them manually as is the only way to do it currently.

See the attached image for suggested layout.

AttachmentSizeStatusTest resultOperations
drupal-node_menu_settings-proposal.png8.32 KBIgnored: Check issue status.NoneNone

Comments

#1

While I think this would be useful for some people, though I'm not sure specifically what for, I doubt that enough people would use this for it to become a part of core. I would think that this could also be easily handled by a contrib module, since it's just a form alter and some queries into the path table if I'm not mistaken. I think this feature should be in the realm of contrib modules.

#2

Version:7.x-dev» 6.x-dev

I think this would be extremely useful as customer sites are worked on by people with little or no programming knowledge, the ability to simply add the menu items to multiple menus across the site from one easy to find location would be a real help. This should definitely be developed for use in the core if for no other reason than most other popular CMS systems have a simple method of achieving this.

I have now worked on multiple projects where this functionality would save a huge amount of time.

#3

Version:6.x-dev» 7.x-dev

new features go into HEAD

#4

Navi
    Testmenu1
        Testmenulink -> Links to node/1213
    Testmenu2
        Testmenulink -> Links to node/1213

If I got it right, it should be able to generate a menu like this with it?
If that's the case, it's absolutely needed!

Is there any way so I could do that in Drupal 6 already?
For me, if I create a menu like that and "Testmenulink" in "Testmenu1" was the first one created, drupal expands this one, even if I click the "Testmenulink" in "Testmenu2". This is also the case if the links have different names, though...

#5

x3cion, yes you got it right, thats what I meant

#6

Updated for Drupal 7 UI

AttachmentSizeStatusTest resultOperations
menu-settings-default-d7.png40.34 KBIgnored: Check issue status.NoneNone
menu-settings-mockup-d7.png44.13 KBIgnored: Check issue status.NoneNone

#7

I'm very interested in this feature and would love to see it in core. In fact, I requested it myself over a year ago (#219851: multiple menu locations, multiple weights). Many of the sites I've worked on have had pages that needed to be listed in multiple places within the menu structure.

How do you propose handling the path displayed when a node has more than one parent? Should their be a way to designate one parent as the "real" location of the node? You could simply add a column of radio buttons to your form and let the user choose which location they want to use.

#8

Personally I think that most node types should only have a single URL, so your suggestion makes sense to me.

#9

Another use case you should consider is a node being its own parent. I've come across many cases where a section in my menu hierarchy does not really need a landing page, but instead just redirects the user to a sub-page.

For instance, take a current case I have where the site has a "Plan Your Visit" section under Primary Links. Under this section are several pages, including "Hours & Admission," "Maps & Directions," "Planning Tips," etc... There's no need for an actual "Plan Your Visit" landing page. Instead I want anyone clicking on that link to automatically go to the "Hours & Directions" page. To accomplish this I would first select Primary Links as the parent of this page and give it the menu title of "Plan Your Visit." Then I could select "Plan Your Visit" as a second Parent for the same node, give it the menu title "Hours & Admission," and set this as the true location of the page.

This would add a great deal of needed flexibility to the menu system. The possibilities are endless!

#10

That seems to be entirely possible based on the last mockup I did, and my original intent for this feature request.

Although you would need to take care when deleting menu items, to not delete a parent, and hence orphan your remaining menu entries.

#11

@#2:

This should definitely be developed for use in the core if for no other reason than most other popular CMS systems have a simple method of achieving this.

Would be nice to see some screenshots or explanation of how those other popular CMS system solve this in their UI.

#12

Subscribing

#13

What about how http://drupal.org/project/nodesymlinks is handling this issue? It appears to have some advantages from an SEO perspective, which is often cited as a pitfall of multi-parented menu items.

#14

Can you explain how nodesymlinks approach is advantageous from an SEO perspective? I know from a website analytics perspective, I would much rather have two menu links pointing to the same place than one page with two unique URLs.

All that aside, looking at this from the user's point of view, there should be a way to manage all of a node's locations in the menu structure directly from the edit page for that node. Whatever solution is settled on, I should not be required to go to another config page, or create an "alias" node in order to achieve this result.

#15

Hmm, nodesymlinks will generate content in two places, but one of them will have meta no-index so at least the search engines won't see the content twice.

this might work to solve some of these problems, but adding an option to add a page to the menu in multiple places would be more fantastic.

also, nodesymlinks is still in DEV status so I am hesitant to install it on a production site.

#16

jstoller #15:

Reason to have multiple URL is for example to have multiple breadcrumb or multiple menu with same content. Drupal menu can't handle that and users are confused when they jumping from one menu navigation branch to another.

Imagine you have this menu structure:

Menu Services No.1
- Service A
- Service B

Menu Services No.2
- Service C
- Service A

Service A appears in two places, what happend if you click on the Service A under menu 2? Both menu will be opened and Service A will be highligthed. Maybe there is some use cases when this is desired behaviour, but there is a lots of use cases when it is not. Additionaly only one of them can appear in the in the breadcrumb. Ok there is a way how to do it in with the Drupal Menu module - make two nodes and fill them with same content - but in this case you need to maintain two separate copies of the same content and site will get SEO penalty...

NodeSymlinks solves that.

#17

@wojtha

I don't think anyone is talking about a node being in two places at once. We're just talking about a node being listed in multiple places. One of the locations would be it's "real" location. All menus and breadcrumbs would reflect that location. While the ability to place a page in multiple locations should be used with care, in many cases any confusion you might cause by jumping from one section in the site hierarchy to another is more than made up for by making it easier for users to find the information they need.

Another use that involves no user confusion at all is the ability to place a node in multiple menus. For instance, my site has a footer menu where I put a selection of links to pages that otherwise are more buried in my site hierarchy. Why shouldn't I be able to add a node both to my primary navigation menu and to my footer menu?

The idea of a symlink is interesting and I can see many uses for it, but it is not always the desired behavior. For instance, my example in post #9 above, where I have a node that is it's own parent in the hierarchy. In that case I want clicking on the second location to redirect the user to the real menu location. A symlink would make things even more confusing. Same thing with my footer menu links.

I'd love to see this symlink function included in the menu system, but it should be an optional behavior that can be turned on or off for each menu instance. Also, I would rather see multiple menu support included in core without any symlink support than have to wait even longer to get the basic multiple location functionality. As I've said before, the key thing is this must be configurable within the standard menu controls on the node edit pages. There shouldn't be any need to go to a different admin screen just to add a second menu location for a node.

#18

@jstoller

I don't think anyone is talking about a node being in two places at once. We're just talking about a node being listed in multiple places. One of the locations would be it's "real" location. All menus and breadcrumbs would reflect that location. While the ability to place a page in multiple locations should be used with care, in many cases any confusion you might cause by jumping from one section in the site hierarchy to another is more than made up for by making it easier for users to find the information they need.

I have to say that I disagree with all menus and breadcrumbs reflecting the setting, although I strongly support this being a configurable option. The most confusing thing for a user is when they are surfing levels 2+ of the navigation (clicking top to bottom on the links) and are then jumped unexpectedly to a new section.

We face this situation with a church website we are working on. Levels 2+ of the primary links appear in left block. They have a music program for kids. It falls underneath "Opportunities for Children" and "Music Programs". If someone is clicking through the five music programs and then suddenly jumps to "Opportunities for Children" they get puzzled. How are they to know that it "really lives" there? We could also use taxonomy terms to organize the pages, but sometimes there are cases where there is a need to double-post content in two different sections without diving into the taxonomy fray (which is overkill for small non-profits who only have a 20-30 page site.)

And simply adding a no robots tag on one of the pages would keep search engines from indexing it and penalizing for duplicate content, if that were a concern.

#19

@Digital Deployment

I'm not suggesting that jumping someone to a completely different place in your site hierarchy is always ideal. However...

  1. There are some situations (like my footer menu, or a node that is it's own parent) when such behavior is expected and desirable.
  2. If my choice is between a multi-location menu system that jumps people around and a single location system, like what we have now, then I'll take the jumping menu any day. Let me, as the designer, determine when such a system is appropriate to use and when it will cause too much confusion. A more context aware multi-location menu could always be an evolutionary enhancement, but we need to start somewhere.

#20

FYI, a module to enable editing multiple menu links is awaiting a CVS account, so hopefully we can move forward a little with this feature without needing to touch the core.

#21

#20 Awesome.. what will it's name be?

#22

It's "Multiple Node Menu", available by CVS or the download should be there after the nightly script runs.

#23

I also discovered an alternate way to do this describe at http://drupal.org/node/524252#comment-1918806

#24

Version:7.x-dev» 8.x-dev
Component:menu system» node.module

#25

Here are some slides I submitted on this topic to the Drupal Core Developer Summit at DrupalCon 2010.

#26

I think this would be a great feature. I have a situation similar to the footer menu idea. Also this may not be the best place to ask, but since user confusion was brought up, how much user testing(HCI) is done when it comes to core features and the UI in general? Just curious, I'm really impressed with the progress Drupal has made.

#27

I marked #219851: multiple menu locations, multiple weights as a duplicate of this issue. Technically it was posted first, but this issue has more discussion around it.

#28

The Menu link module uses fields for menu links. It's not too stable right now. But I think this approach should be followed for Drupal 8.

nobody click here