Port Menu attributes to Drupal 8

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

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

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.

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.

Once this issue is resolved we can look at this with better certainty:
#2256521: [META] New plan, Phase 2: Implement menu links as plugins, including static admin links and views, and custom links with menu_link_content entity, all managed via menu_ui module

Looks like this is no longer blocked since 5 months.

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

thanks

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.

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

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 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.

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: http://www.agoradesign.at/blog/add-custom-menu-item-attributes-drupal-8

@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 drupal.org, 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 :)

@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.

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

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

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?

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.

please merge ...

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?

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

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).

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.

#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?

@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.

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.

Made a comprehensive issue summary update.

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.

@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:)

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

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.

@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.

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.

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.

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: https://gist.github.com/awasson/fcc44fc6cba6f4b90ff5

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

Cheers,
Andrew

@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

Once #2656534: Provide a way to extract a menu plugin from a menu form and #2660486: MenuLinkDefaultForm::extractFormValues() does not include the plugin ID are committed/released, the patch in #47 can be cleaned up considerably.

@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.

Cheers,
Andrew

@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.

@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.

@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.

Go for it.

Committed accesskey and here's the remaining code.

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.

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!

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 !

I created a GitHub repo for this as my WIP: https://github.com/robdecker/menu_attributes/tree/d7-to-d8-port

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.

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

@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.

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

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 (https://www.drupal.org)

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>
                <li id="go-to-drupal" class="foo bar menu-item" style="color: goldenrod; font-family: Courier">
        <a href="https://www.drupal.org" 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>
                <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>
              </li>
        </ul>

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.

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

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('http://en.wikipedia.org/wiki/Access_keys')]),

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?

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://...'].

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.

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" https://www.drupal.org/node/2660486 and https://www.drupal.org/node/2656534 are in progress and one of them was fix.

Should we try to enable again the form?

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.

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).

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.

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

@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.

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.

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

#2760557: LinkItem::getUrl ignores the value of options

Product of my hacking is here https://www.drupal.org/project/link_attributes - it may meet your needs - for custom link fields and for menu link content's link field too.

Updated issue summary to reference it.

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

So https://www.drupal.org/project/link_attributes functionality-wise covers the same functionality as D7 Menu attributes and all the other solutions, except it also works for for custom link fields?

Just to clarify because I had to install https://www.drupal.org/project/link_attributes 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.

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

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('plugin.manager.menu.link'), 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.
http://cgit.drupalcode.org/simple_megamenu/commit/?id=f225722

You can use my module : https://www.drupal.org/sandbox/pankaj1433/2873280

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) 💪

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.

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-)

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.

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 :)

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

<li><a><!--svg-->....</li>

is poossible improve this module about this position / hook ?
Thx

Please correct me if I am wrong: I did read the source code of https://www.drupal.org/project/menu_attributes's Drupal 7 branch and then I looked at the code of https://www.drupal.org/project/menu_link_attributes and https://www.drupal.org/project/link_attributes. It seems that the last two modules cover all of the logic implemented at menu_attributes's Drupal 7 branch, right? If so, shall we reference this at the description of https://www.drupal.org/project/menu_attributes and close this issue?

I played with these two modules:

Menu Link Attributes: https://www.drupal.org/project/menu_link_attributes
Link Attributes widget: https://www.drupal.org/project/link_attributes
They are very similar.

With regards to this issue, I tested the dev branch for the D8 port and I think it works good enough to have a Dev release, would you mind creating that?

OMFG, additionally to #90, ther's also https://www.drupal.org/project/menus_attribute...

Also https://www.drupal.org/project/link_attributes takes an even broader (and imho very elegant) approach...

Please cut an 8.x-dev branch with the patch in #64.
So we can start using this with composer!

Please also see #3136829: Duplicate menu item settings with menu_link_attributes which makes it even more useful to have one well maintained module for all menu item attributes and share commonalities / benefits with the https://www.drupal.org/project/link_attributes module.

This seems to have lost momentum, as I guess we're all very busy currently. Anyway I think it's still a very good idea and combined solution for Drupal 9. We should come back for this as soon as someone has some time or a project where it could be helpful (which I think is in most cases ;))

wondering if there has been any progress.

The repository has a 8.x branch. Can someone make a release please?

#92 menus_attributes just looks like a straight copy of this. They should have collaborated and supported an 8.x branch on this project. Its confusing having the same exact thing with the same exact copy on it - especially when this has 100k reported installs.

When things aren't being done people start their own versions; that's just how open-source works. We're approaching Drupal 10, but maintainers haven't even created a dev release for the 8.x branch. It's totally fine for developers to prioritize their projects, and it's clear this project wasn't prioritized and has not been actively developed in some time. Consequently others who needed a functioning module created something new. Further upthread, link_attributes and menu_link_attributes were also mentioned as paths forward; they also had similar functionality.

Menu attributes was -- and still is, for D7 sites -- a great module that filled a need. At this point I think it should be marked as no further development, and maintainers (if they wish) can designate one of these or other projects as a suggested option for D8+ sites.

@rootwork++