Work on a Drupal 8 port of Menu Attributes has happened in a few places:

  • A sandbox project by user shanethehat. Hasn't been worked on since May 2013.
  • A custom module by @bobrov1989 (#14). Does not work with the current D8 (#16) and author isn't currently able to update it (#18).
  • A custom module by @agoradesign posted in this blog entry. This only provides the ability to add a class attribute (#16). Does not work with the current D8 and the author is not planning to update it (#19).
  • A new module by @yannickoo, Menu Link Attributes. Currently on beta1 and working with the latest D8 release. Author is interested in merging that module back into Menu Attributes (#25).
  • A new link widget by @larowlan - Link attributes widget - that works for link fields on other entities too


While the earlier projects might provide helpful information (and their authors might be interested in helping to port the module) it seems like Menu Link Attributes is the furthest along in terms of features and being in working order. As @yannickoo is interested in merging the module back into this one, that seems like a viable path.

Next steps:

  1. See what can be merged in from the link module, there may be some gems or tests that could be ported
  2. Get the config form showing up on it's settings page with what we had in D7 (items and links)</li>
  3. Ensure the menu and menu link form alterations are showing up as configured
  4. Ensure the menu link altering is actually feeding the menu output
  5. Try to enable and adjust the existing tests and get them to work
  6. Check if we need to add any cache contexts

Original issue:

When I looked for a Drupal 8 port, I found this sandbox project using Google. But there is no mention about this (unofficial?) port in the issue queue.

Are there any plans to port menu_attributes to Drupal 8?

Members fund testing for the Drupal project. Drupal Association Learn more


me-valia’s picture

We (@InternetDevels team) would like to help with development of D8 version if maintainers not against.
Thanks, ksis.

Schoonzie’s picture

I am planning to work on a D8 version and have a dev branch ready within the next month

Schoonzie’s picture

Assigned: Unassigned » Schoonzie
judahtanthony’s picture

Any progress update or ETA? This is a handy little module, and I'd love to use it on a project I'm currently working on.

Dave Reid’s picture

Status: Active » Postponed

Menus and menu items are such in flux right now in D8. There has not been any progress yet that I have seen, nor should I think there should be any progress until at least the beta1 release.

joelpittet’s picture

hass’s picture

Status: Postponed » Active

Looks like this is no longer blocked since 5 months.

sachbearbeiter’s picture

would be wonderful to have this module as a d8 port - is there some progress?


joelpittet’s picture

Assigned: Schoonzie » Unassigned

Nope, maybe this weekend at the sprint I can find some people to help do an initial port and see what we can take from sandbox in the IS.

sachbearbeiter’s picture

good luck - if a (really) small bounty via paypal helps -> send me a pm ...
thanks sb

joelpittet’s picture

Oh I found out on IRC yesterday there is still a bit of flushout to happen with the menu in D8 and that there is a group of people in NJ Camp that are planning to try to resolve for us.

I'll be keeping tabs and discussing a bit with Angie still on the weekend and may still discuss and experiment on Sunday but I'd not expect much until the menu entity underpinnings are under control.

Thanks for the offer @sachbearbeiter

bobrov1989’s picture

Is there some progress in porting module to d8? I can start porting from 7.x-dev version.

bobrov1989’s picture

67.85 KB

I've started to do it, but there is a lot of work. May be we can start from this point and create issues for each task.

bobrov1989’s picture

67.84 KB
rootwork’s picture

@bobrov1989 I recommend you start a sandbox project or create a project elsewhere (like GitHub) so those who are interested can start collaborating with you. That said you should definitely keep updating folks here -- since ideally some or all of the work you do could be pulled back into a development branch of the official module. But several other D8 modules are being developed this way, some because the maintainer doesn't have time to work on a D8 version yet, and some just as a way to do easier/quicker collaboration on an unstable D8 version until it solidifies.

agoradesign’s picture

Thanks @bobrov1989 for the port - but unfortunately I've to tell you, that it isn't working (any more). Maybe it's related to some core changes that took place in the last months.

First, I tried to get it to work by myself, but different kind of problems and errors appeared, so that I ended up with creating a tiny custom module, offering only the possiblity to add a class attribute to all menu items, that are created by menu_link_content (core) module. I've summarized the solution in a blog post:

rootwork’s picture

@agoradesign Do you anticipate continuing to update your custom module? (e.g. if you're using it in client sites and expect to follow D8 releases through the RCs and to 8.0.0.) If so, I'll make the same recommendation I did to @bobrov1989 -- create a sandbox project on, or create a repo on GitHub. That way you can point people to it, easily make updates to the code (and receive bug reports if a new D8 release changes anything), and potentially be a place for menu_attributes to look for ideas for their port.

On the other hand, if this is just a one-off thing and you don't expect to continue to maintain it, then thanks for your code :)

bobrov1989’s picture

@rootwork, Sorry I'm very busy with the projects now, I'll continue when I'll have some free time.

agoradesign’s picture

@rootwork: I was planning to do so, but as already mentioned I failed on getting menu_attributes to work. And I had far too few time to keep on trying. That's why I did the custom module workaround. I'm not planning to update, only to use in different projects, as long there isn't a better solution available.

However, as far as it's possible for my in terms of having time, I'm of course willing to contribute/help. Before we move on to any D8 implementation, we should clarify, where and how we want to store the options. If you read my blog post mentioned above, you'll see that in D8 you have 3 possibilites:

  • write in menu_tree table
  • write in menu_link_content[_data] table
  • use fields

When trying to implement the first solution (menu_tree), I had the problem of losing the values on cache clearing. this may be a bug in core, or may be it's by design - I don't know. The developer of Menu Badges module ran into the same problem, was he wrote in a comment to my blog post.

yannickoo’s picture

Hey guys, I have created the Menu Link Attributes for Drupal 8 – give it a try :)

hass’s picture

Why are You not helping here? We have enough modules on d.o and do not need duplicates.

axe312’s picture

Yannickoo's attempt is much simpler. But as far as i can see it covers all the functionallity. I still see a chance of merging these modules.

@yannickoo: does your attempt cover all functionality of menu_attributes?

yannickoo’s picture

Menu Link Attributes provide a form where available attributes can be set and then you can use them in menu link edit form. I only see one missing feature: setting menu attributes in node forms but I think this is okay.

sachbearbeiter’s picture

please merge ...

yannickoo’s picture

I would really appreciate a merge. My attempt was to port that module so I can use it in my Drupal 8 projects and I think we can use this as a base for porting this module.

Can we get some input here from the maintainers?

klokie’s picture

Title: Port to Drupal 8 » Port Menu attributes to Drupal 8
deepakaryan1988’s picture

I am totally agreed with @sachbearbeiter and @yannickoo
Please merge it.

rootwork’s picture

It sounds like @yannickoo is interested in merging it, we just need some feedback from this module's maintainers -- looks like there hasn't been any in almost a year, so not sure where they are in their own work to port things. In the meantime, I think @yannickoo's module is a good stopgap (sort of like Meta Tags Quick did when the Metatag port to D7 was taking awhile).

joelpittet’s picture

Has anybody tried #14 in Drupal 8? This issue is 'active', so I'm assuming it's not quite ready.

I wanted to discuss this with @pwolanin as he did a bunch of work into making menu item's entities but didn't get a chance to at badcamp.

I'll open a D8 stub dev branch likely today or tomorrow. In the mean time please test #14 and get this to RTBC.

rootwork’s picture

#16 suggests #14 no longer works, and I'm guessing given all the changes in D8 since June 15 that's accurate. I haven't tried @yannickoo's module but I will and report back.

@joelpittet are you saying you'd prefer that module in the form of a patch to the D8 dev branch you're creating?

joelpittet’s picture

@rootwork no that's fine as a zip for now. Just want people to try it out if they haven't. I'm not going to commit broken code, I will commit working yet WIP code. And even if it doesn't work right now I'll commit a module stub to start the ball rolling at least.

joelpittet’s picture

I've opened up a 8.x branch with no real code there yet as a stub to build up from. Working through merging and upgrading as much as I can.

rootwork’s picture

Version: 7.x-1.x-dev » 8.x-1.x-dev
Issue summary: View changes
Status: Active » Needs review

Made a comprehensive issue summary update.

  • joelpittet committed 551deae on 8.x-1.x authored by bobrov1989
    Issue #2174435 by bobrov1989, joelpittet: Merge zip menu attributes to...
joelpittet’s picture

I've merged most of the zip file into head, it was looking pretty good and fairly straight forward. It's currently not working quite right but we can look at massaging from there.

Also stubbed in the tests from 7 and commented out the un-working parts till we sort out the config form and storage.

joelpittet’s picture

@rootwork thanks for updating the issue summary! That's a nice summary update:)

Next steps:

  1. See what can be merged in from the link module, there may be some gems or tests that could be ported.
  2. Get the config form showing up on it's settings page with what we had in D7 (items and links)
  3. Ensure the menu and menu link form alterations are showing up as configured
  4. Ensure the menu link altering is actually feeding the menu output
  5. Try to enable and adjust the existing tests and get them to work
  6. Check if we need to add any cache contexts

One step at a time, we'll get there:)

  • joelpittet committed 5eb04c9 on 8.x-1.x
    Issue #2174435 by joelpittet: Fix config form
joelpittet’s picture

Issue summary: View changes

  • joelpittet committed 1a41c75 on 8.x-1.x
    Issue #2174435 by joelpittet: Fix config form save to config
joelpittet’s picture

Feel free to assign yourself and work on this issue. I'll commit and credit on this issue.

axe312’s picture

So you checked in not working old code from a zip file while there is already a working port which covers almost any functionality?

Sorry, but i simply do not understand why.

joelpittet’s picture

@axe312 I fixed a lot of what wasn't working from the zip and ported the test code coverage so we can make sure things worked at least as well as they did in D7. The zip was more inline with the code from D7 and I'm aiming for a straight port as much as possible so that gives us a decent base and a way to test progress by uncommenting the relevant tests as we go to ensure it's working.

Was kinda hoping one of you who are looking forward to using this in D8 would help this along but nobody's jumped in yet... That's why I wrote #36 and #40. @axe312 please feel free to port the port code that works as a patch if you feel it's the right approach for D8.

joelpittet’s picture

FYI, the admin UI for choosing the attributes is working in HEAD last time I checked and there is nothing further needed from the zip file to merge. So merging parts of menu_link_attributes would be the next step unless you know there is a better way to do it.

rrrob’s picture

I've been working on this port quite a bit, and have the menu_link_content items fully working.

However, the other type of menu links are a different story. As it currently stands, there is not an easy way to save attributes for a system menu link (Drupal\Core\Menu\MenuLinkDefault), which is similar to how Views creates menu links. So Views based menu links are out of luck at the moment too.

There are two issues in progress that will make altering these two types of menu links easy. I've added them to the issue summary.

So, there are a couple options that I see:

  1. Wait until the two patches are committed to core and released
  2. Put together a solution that bypasses the existing Drupal\Core\Menu\MenuLinkDefault to save attributes
  3. Release a half baked solution that only supports user created menu links and let users know that the remaining functionality will come later

I can upload the patch for a fully working menu_link_content if you'd like.

awasson’s picture

Hi rrrob,
We've been working on this as well and patching against the latest D8-dev release where we're picking away at a variety of minute bugs.

In the most recent patches, we've resolved the fatal error that initially occurred when saving a node with a menu link and we've also got the menu attributes showing up on form_menu_link_content so that it shows on main menu link editing as well as any custom menus.

I've been working on making the menu attributes show up on the node editing form but I can't yet attach it to the Menu Settings horizontal tab on the editing page. Here's a Gist of what I've been doing there:

Can you patch your work against the latest dev so we're all on the same page?


joelpittet’s picture

@rrrob Please do upload a patch and maybe we can get those two related patches into core too. I'll review and mark as contrib blockers. Thanks for helping!

We found a couple small fixes over the sprint weekend for the menu item edit forms to get them to work with custom menu links and the built in ones like home/<front> #2659710: Menu attributes not rendering on menu link content form

rrrob’s picture

10.93 KB
rrrob’s picture

awasson’s picture

@rrrob: You've made pretty great headway with your patch. Nice work!

I've applied the patch and have done a cursory run through on the Main navigation menu and the attributes are saving and rendering. I haven't dug into the code but I'll do that as soon as I can (hopefully this afternoon).

This is a pretty huge push forward.


joelpittet’s picture

@rrrob the tabindex to accesskey change at the top of the patch. Could you explain that one?

@awasson & @rrrob Also, one thing @pwolanin was mentioning on IRC a while back is maybe we should target the menu block plugin for the display of the menu attributes instead of letting them 'infect' the toolbar, admin_menu and breadcrumb links like they do in D7. Could have some performance benefits too.

rrrob’s picture

@joelpittet the project page says:

The module currently allows you to set the following attributes for each menu item:

  1. Id
  2. Name
  3. Target
  4. Rel
  5. Class
  6. Style
  7. Accesskey

The tabindex was added to the d7 version to show off how to use the supplied hook. I was restoring original functionality. Interestingly, the .module code referenced accesskey and not tabindex, so my patch aligns the settings.yml and schema.yml files with the .module file.

joelpittet’s picture

@rrrob oh that's good sleuthing. I wasn't aware those had been different. I'll commit that piece soon if you don't mind and we can hack away at that patch till everything is committed.

rrrob’s picture

Go for it.

  • joelpittet committed f054e3e on 8.x-1.x authored by rrrob
    Issue #2174435 by rrrob: Move tabindex to accesskey
joelpittet’s picture

Committed accesskey and here's the remaining code.

delta’s picture

Status: Needs review » Reviewed & tested by the community

I apply the patch in #55 to the 8.x branch of menu attributes, that cleanly apply.

After that I try to create some links with a try on random attributes on the link and on the parent item.

Works really well. Thanks for all the work.

joelpittet’s picture

Thanks for the enthusiasm and testing it out @delta. Did you need the patches mentioned in #48? I'd be surprised but happy if you didn't!

delta’s picture

thanks ;)
No I didn't use the patch above in #48 and the menu items have the attributes as expected. However I noticed a number of warnings on the site I using this.

Warning: htmlspecialchars() expects parameter 1 to be string, object given in Drupal\Component\Utility\Html::escape() (line 407 of core/lib/Drupal/Component/Utility/Html.php).

Warning: strpos() expects parameter 1 to be string, object given in Drupal\Component\Utility\UrlHelper::stripDangerousProtocols() (line 346 of core/lib/Drupal/Component/Utility/UrlHelper.php).

Warning: array_filter() expects parameter 1 to be array, null given in menu_attributes_preprocess_menu() (line 291 of modules/contrib-dev/menu_attributes/menu_attributes.module).

Notice: Undefined index: item_attributes in menu_attributes_preprocess_menu() (line 291 of modules/contrib-dev/menu_attributes/menu_attributes.module).

So I suppose this need works, but also postponed by : #2656534 and #2660486
I let you choose the good status.

Thanks again for all the works here !

rrrob’s picture

I created a GitHub repo for this as my WIP:

As of this comment, menu_attributes works for both menu_ui created links and menu_link_content links. Both the <li> and the <a> are working.

Still need to do the form alter for node add/edit links.

Note that you need to be on D8 head, and apply the patch at #2656534-19: Provide a way to extract a menu plugin from a menu form for this to work.

joelpittet’s picture

Even if it's not a bug or not the right bug, I'm relating @rrrob's other issue here too.

#2679008: Module weight is not taken into account after module installation

joelpittet’s picture

Issue summary: View changes
Status: Reviewed & tested by the community » Needs work
50.3 KB

@rrrob I noticed your work on the d7-to-d8-port branch works for home link by putting the field set in but they don't seem to have content and throw a bunch of notices. I'll see what I can pull out of that to get this further along.

rrrob’s picture

@joelpittet did you apply the patch that I mentioned in #59?

benjifisher’s picture

I did a little testing of the patch from #55. When I edit the "Main navigation" menu, I do not see any attribute options on the existing Home link, but I do for links I add myself:

  • internal link (/node/1)
  • external link (

I put in a bunch of silly attributes, and this is the markup I see:

              <ul class="clearfix menu">
                    <li class="menu-item">
        <a href="/" data-drupal-link-system-path="&lt;front&gt;">Home</a>
                <li id="go-to-drupal" class="foo bar menu-item" style="color: goldenrod; font-family: Courier">
        <a href="" title="The source for everything Drupal" id="link-drupal" name="Barney" rel="uncle" class="link-foo link-bar" style="font-size: large; border: 1px solid black" target="_parent" accesskey="D">Home, sweet Drupal home</a>
                <li id="node-1" class="foo bar menu-item menu-item--active-trail" style="background-color: red">
        <a href="/node/1" title="This is a link to node 1" id="node-1-link" name="Fred" rel="child" class="link-foo bar-foo" style="padding: 1em" target="_blank" accesskey="F" data-drupal-link-system-path="node/1">Test page</a>

So far, so good, except that the Home link is not configurable.

I also see the warnings and notice mentioned in #58. I will look into them.

rrrob’s picture

The patch in #55 is out of date. I'll make a reroll based on the Github project I linked to.

benjifisher’s picture

I have been working with the branch on d.o and the patch from #55.

I tracked down the errors mentioned in #58 (at least some of them) to this line:

    'description' => t('Specifies a <a href=":accesskey">keyboard shortcut</a> to access this link.', [':accesskey' => Url::fromUri('')]),

I may not have time to submit a patch before I get on a plane to go home. I will have to review the proper way to translate strings in D8: aren't we supposed to use Drupal::t() or something?

benjifisher’s picture

The attached patch (there is also an interdiff on top of #55) fixes the problems noted in #58 (at least some of them).

If we are building a link with t('... <a href=":url">...</a>...') rather than using Drupal::l() (or Link::fromTextAndUrl()) then I do not think we need to do anything fancy with the URL. Just use [':url' => 'http://...'].

benjifisher’s picture

The patch in #66 prevents an error when the menu-item-edit form is rendered, but there are also errors when the menu items are rendered. (If you do not see any errors, then try clearing caches.) The attached patch fixes this problem.

killua99’s picture

What could happen if we enable the edition link form? Now we're working on sites that are already on production or close to it and need to edit links more than create new one.

The "blockers" and are in progress and one of them was fix.

Should we try to enable again the form?

  • joelpittet committed 32f4069 on 8.x-1.x authored by rrrob
    Issue #2174435 by benjifisher, joelpittet, rrrob, delta: Port Menu...
joelpittet’s picture

I've committed #67. One of the two core patches are in so that's good news.

#2660486: MenuLinkDefaultForm::extractFormValues() does not include the plugin ID

The other one still needs some help.
#2656534: Provide a way to extract a menu plugin from a menu form

The form doesn't show on the home link at the moment. Let's try to get that working and saving on the home links.

joelpittet’s picture

Status: Needs work » Needs review

Considering an architectural change here at drupalcon NOLA sprints.

If I can get a unique identifier for both routing menu items (think same route in different menu links/menus) and content (entity) menu links. Then lets get a schema to store this and join instead of the serialized options cell.

The drawback will be that we will still need a serialized cell for extra attributes provided with the hook, but that should be minimal and only special use-cases. And we'd be doing a LEFT join on loading menu links and merging the attributes but it would be nice to keep them separate instead of overriding core or contribs options.

Anybody have any big concerns with maybe doing that? Or anybody want to take a crack at the schema? Thinking one table with the current attributes as their own columns, one serialized additional_attributes, one menu or menu link identifier and one type (menu link, menu item, menu).

joelpittet’s picture

Also this would allow us to *actually* clean up after this module is uninstalled because as it is in D7 the attributes changes will persist and we can't separate them from the original attributes provided by a module or core.

amateescu’s picture

@joelpittet, I wonder what would be the performance impact of that change. And being able to clean up on uninstall is the only benefit?

joelpittet’s picture

@amateescu the performance I'd hope would be better but don't know until we try. My theory is that a SQL join of a new table would be more performant than the unserializing the options (which happens anyway but hopefully less memory with actual attributes on there).

The other benefit is we don't have to wait for a core fix because we don't need to store options on a route generated menu link, just reference by plugin id.

larowlan’s picture

Just a question, but it seems to me that we ignored the first item on the action list

See what can be merged in from the link module, there may be some gems or tests that could be ported

By default core comes with a LinkWidget that just ignores the options of the URI.

I think we can ship an alternate widget that supports options and use that instead.

I'm gonna hack on that a bit.

larowlan’s picture

Doing it as a widget also means it works for any link field, not just menu links.

larowlan’s picture

larowlan’s picture

Issue summary: View changes

Product of my hacking is here - it may meet your needs - for custom link fields and for menu link content's link field too.

Updated issue summary to reference it.

stefan.r’s picture

#2760557: LinkItem::getUrl ignores the value of options is now in core.

So functionality-wise covers the same functionality as D7 Menu attributes and all the other solutions, except it also works for for custom link fields?

chrisshattuck’s picture

Just to clarify because I had to install to find out for sure, but that module only works for entities, it does not work for module-supplied menu items. I'm still looking for a solution that does.

Stephen Ollman’s picture

Anyone else experience attributes now missing after updating Superfish to 8.x-1.0-rc2

I've set the class attribute against the menu item and this was working prior to updating Superfish. Now the class is no longer added to the menu item

flocondetoile’s picture

For a module I'am currently working on, I need to save too some custom data into the options array of a Menu link item Plugin.

I succeed to do this task with the help of #2656534: Provide a way to extract a menu plugin from a menu form but with only a small piece of this patch needed.

Simply by adding the options Plugin definition into the $overrideAllowed variable in \Drupal\Core\Menu\MenuLinkDefault class and in the $expected variable in the \Drupal\Core\Menu\StaticMenuLinkOverrides::saveOverride method.

And then using $menu_link_manager = \Drupal::service(''), You can easily save/update options set into the Plugin definition from a submit function. The issue #2656534: Provide a way to extract a menu plugin from a menu form seems to do a lot more of simply permitting to override the Menu link item $options.

Below the code used for this issue.

pankaj1433’s picture

yannickoo’s picture

An update from my side: Menu Link Attributes is stable now and got support for adding attributes to containers (the wrapping <li> tags around your menu links) 💪

DamienMcKenna’s picture

Given that @yannickoo's module is now out and stable I'd like to suggest everyone collaborate to make it better and make it the "official" D8 version of Menu Attributes, there's no point in having two modules that do the exact same thing.

DamienMcKenna’s picture

Sorry, I hadn't seen the comment about larowlan's similar module, or realized that pankaj1433's promoted their module to a full project.

So we now have three options for assigning menu attributes, two of which seem to be identical. Doh X-)

larowlan’s picture

For the record link attributes isn't about menu links.

Its about providing a link widget that allows setting attributes - it supports any link field.

The fact that menu link content entities have a link field means it works for them.

In fact, in the LinkWidget that core provides there is even a @todo that says 'make this support collecting link options'. Link attributes widget module does just that. In essence it could be a candidate for inclusion in core (resolving that todo). And then it can be mothballed.

yannickoo’s picture

I also thought about stopping the development for Menu Link Attributes and starting to contribute to Link Attributes module but then I worked through the issue queue and realized that a feature like Container attributes should not be implemented in Link Attributes because the <li> elements around menu links are not related to link attributes.

A cool feature of Menu Link Attributes is that you can define available options for attributes (useful for class or target attribute) but I'm sure we can port this functionality to Link Attribute.

I'm definitely looking forward to see Link Attributes' functionality in core so that we just need to implement some code for the container attributes :)

landsman’s picture

Hello guys, I want some field where I can put svg icon (source code) and markup will be:


is poossible improve this module about this position / hook ?