Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
If I create menu items with the same name (a link in the header called Home, and one in the footer called Home) I end up with duplicate id tags on the li elements in the menu. This is because the mlid value is automatically generated based on the text in the link. This occurs even with different menu blocks. I've seen other menus where a unique 4 number id is added to each of the mlid values so you would end up with a unique id, something like id="menu-mlid-1023". Is this the way this is supposed to work, and is it something that can be easily patched?
Thanks.
Comments
Comment #2
jmoruziComment #3
Jeff Burnz CreditAttribution: Jeff Burnz commentedDid you see that in a Drupal 8 theme, or a Drupal 7 theme? I've struggled to get something like an actual mlid out of D8, so I'd be very interested to see how someone else might be doing that.
Comment #4
Jeff Burnz CreditAttribution: Jeff Burnz commentedWhat I could do is add the menu name as a prefix - so for example if you had a Main menu and a Footer menu and two links for "Home", they might look like this
Thats a pretty big change for existing themes, which is my only real concern.
Comment #5
jmoruziOn one of my sites (Omega for D7) I have a Superfish menu in the header which gives menu ids like this: id="menu-218-1".
In the footer is a menu block which has the same menu (not Superfish) that does not have an id but has the class: class="menu-mlid-218"
So it looks like it's the Superfish module that generating the id because I have a few D8 sites that use the Basic theme and there are no ids on the menu items, only classes. Does there need to be an id or could you just have a class on the menu item?
Comment #6
Jeff Burnz CreditAttribution: Jeff Burnz commentedYou don't need an ID, there are always ways of targeting a menu item using CSS, however it's probably the most efficient and easiest way.
EDIT - I should have been more clear, I meant you don't need an ID for styling, however it is used for accessibility - see below.
Comment #7
jmoruziWould removing the id affect accessibility? In the menu.html.twig file, line 64:
I don't see how the menu id attribute is used, or would have any effect on usability.
Comment #8
Jeff Burnz CreditAttribution: Jeff Burnz commentedIt is used for accessibility - to bind the click handle in responsive menus to the menu item.
Comment #9
Jeff Burnz CreditAttribution: Jeff Burnz commentedI'm favouring this pattern:
<li{{ item.attributes.addClass(item_classes)|without('role') }} id="{{ 'menu-name--' ~ menu_name ~ '__' ~ item.title|render|clean_id }}">
Which results in output like this:
<li class="menu__item menu__item-title--home" id="menu-name--main__home">
While the menu classes are:
<ul class="menu odd menu-level-1 menu-name--main">
The id is therefor a modifier pattern on the unique menu name class (in the example it's
menu-name--main
, which kind of makes sense given it's current usage (for binding click handles).I doubt that many themes are using the ID for styling, and if they are it will be a very minor update to fix any issues. The upside is we fix the duplicate ID issue and overall it's easier code to modify (by not using
setAttribute
).Comment #11
Jeff Burnz CreditAttribution: Jeff Burnz commentedComment #12
jmoruziThanks Jeff, much appreciated
Comment #13
jmoruziApologies Jeff, perhaps I was not clear enough. The problem still exists. The issue is not just with the anchor text, the problem occurs when placing a menu in 2 places using the block system. If use a menu in 2 different places, the menu name is still the same. I have a main menu in the header, here's the actual code generated on the page:
I've placed a block in the footer with the same menu, here's that code:
The nav id is unique, but because the menu name is the same the li ids are still the same.
Comment #14
jmoruziComment #15
Jeff Burnz CreditAttribution: Jeff Burnz commentedOK, yes good point, I'll have to see if I can pass something from the block - the block instance is different (so the unique block ID is coming from the block system, but calling the same menu etc).
Comment #16
Jeff Burnz CreditAttribution: Jeff Burnz commentedThis might have to fall into the "good enough" category, basically because I have run out of time to figure out how this could work - the menu nor menu items have any such thing that makes them unique other than the block plugin id, and getting that into the menu template seems very problematic (suggestions more than welcome).
Styling wise you can style them, by using the block ID, however I am very reluctant to just remove the ID's due to a duplicate ID warning etc, because they do, in most instances, provide context for the click handles for screen reader users.
I can accept this a bug, because technically it is, but how to fix it seems quite problematic, I might try asking on Stack Exchange to get someone more familiar with the menu system especially SystemMenuBlock.php and the final build process.
Comment #17
jmoruziOK, thanks. I'll need to see if I can come up with a workaround because I can't just remove the the ids for the same reason. This site needs to meet accessibility requirements.