I'm trying to retrofit features into an existing site for deployment, and need to support up to 8 different menus with it. I'd also like to be able to do so without selecting individual links.

To me it looks like the uses cases for the current support for individual links in a single menu, vs. maintaining several entire menus in code are a bit different, so I'm not sure how best to proceed. It seems like there's two main options:

1. Extend the current support to allow for multiple menus (probably with a 'select all' checkbox). This could get very unweildy IMO.
2. Rename the current menu support to 'menu links', and add separate support for exporting an entire menu separately.

I've started work on #2 in a custom module, will post a patch here once I've resolved some niggles.

I also noticed there's currently doesn't seem to be support for reverting menus, plid/weight information etc., that opens up a fairly large can of worms unfortunately.

Either way, opening this to track status, and just in case there's some code around somewhere which supports this which I've not found yet.

CommentFileSizeAuthor
#19 633804-19-custom-menus.patch11.72 KBjohnalbin
#18 633804_custom_menus.patch12.28 KByhahn
#9 menu_features.module.txt3.31 KBdawehner
#2 menus.tar_.gz1.33 KBdawehner
#1 menus.module.txt2.15 KBcatch

Comments

catch’s picture

catch
he/him
Primary language English
commented
Status: Active » Needs work
StatusFileSize
new menus.module.txt2.15 KB

Since menu hierarchy and lots of other things depend on mlid, exporting hierarchies relying on that is a no go for features - works for my use-case but not safe across different sites or deployments. That at least partially explains why the current code avoids all of this.

That makes this altogether trickier, however posting what I have so far for reference.

Major todos:

Figure out if there's a viable workaround for plid - maybe trying to use link_path, which isn't guaranteed to be unique, but often is at least per-menu (similarly for replacing items).
Create custom menus if they don't exist.
Consider whether it's possible to also delete menu items that have been removed from the feature, I'm thinking not though.

I've posted this as a .module rather than a .patch since I'm not sure it can even live in features.module at all without dealing with at least the first two of the above, and it's also unlikely I'll have time to work on those.

dawehner’s picture

dawehner
Primary language German
commented
StatusFileSize
new menus.tar_.gz1.33 KB

Here is a module, which is based on the above file. It added support to create the menus, too. But missed the second TODO.

rapsli’s picture

rapsli commented

going to try it out...

rapsli’s picture

rapsli commented

oky, I've tested this module. It seems to work just fine, but there's one tweak I had to make, but unfortunately I can't find it anymore. Would love to see this feature get into the module

q0rban’s picture

q0rban commented

Hmm.. interesting.

Anonymous’s picture

Anonymous (not verified) commented

following

catch’s picture

catch
he/him
Primary language English
commented

By the way I got this working for hierarchy but forgot to post back here and don't need this any more at the moment. If you're interested in taking it further find me in irc and I'll try to dig it up.

rapsli’s picture

rapsli commented

is nobody taking this further?
@catch: would be nice if you could post your running version here

dawehner’s picture

dawehner
Primary language German
commented
StatusFileSize
new menu_features.module.txt3.31 KB

Here is the dev version of catch.

Sadly i forgot about this issue

rapsli’s picture

rapsli commented

how are we going to proceed here? Creating a new module for this :S ... I think it would be better suited in the features module itself.

rapsli’s picture

rapsli commented

... this did not work with my menu

rapsli’s picture

rapsli commented

never mind, it actually did work ;) I didn't actually enable the menu_features on the target system. It should probably also have a dependency in the feature

jmseigneur’s picture

jmseigneur commented

Yes, the dependency with menu_features should be added. In addition I've successfully used the package attached to #2 but when I updated that package with the code in #9 only the Primary menu was imported. With the code in #2 all menus were imported including custom menus.

Nick Robillard’s picture

Nick Robillard commented

#2 is successful for me. Menus export and import properly so far.

lelizondo’s picture

lelizondo commented

subscribing

yhahn’s picture

yhahn commented
Assigned: Unassigned » yhahn
Priority: Normal » Critical

On my list.

yhahn’s picture

yhahn commented

I took a look at this tonight and here's my plan for the patch:

  1. The patch currently expects each menu to be exported as an entire unit. I would like to see support for exporting individual menu link instances so that different features can provide menu links into the same custom menu.

  2. To accomplish this, I think we should use menu_name:link_path as the identifier for each exported menu link. This would disallow the export of two links using the same link path in the same menu but generally speaking this is a serious corner case and probably a bad IA decision for someone to make in the first place.

  3. To support parenting, I propose replacing the plid reference with a similar menu_link:link_path identifier.

  4. We will need a separate component for menus themselves (menu_custom table, we can use menu_name as the identifier).

  5. Given that there is existing (and severely lacking) "menu" integration in Features at the moment we'll want a way to eat existing exports, let any features using the current integration get their exportables up to date, and then deprecate the old stuff.

Will get going on this next.

yhahn’s picture

yhahn commented
Status: Needs work » Needs review
StatusFileSize
new 633804_custom_menus.patch12.28 KB

As promised, here is the patch.

johnalbin’s picture

johnalbin
they/他
Primary language English
Location Taipei, Taiwan
commented
Status: Needs review » Needs work
StatusFileSize
new 633804-19-custom-menus.patch11.72 KB

I tried the patch in #18. The menu export seems to work fine. But menu links don't get exported at all; when you click a checkbox next to a menu item, you don't get that ajaxy-icon of it doing work like other feature exports, so the menu links don't appear in the generated module.

Looking at the patch, it seems that only the link path and link title are supposed to be exported. IMO, this must include the options as well. There are contrib modules that add attributes to menu links; menu_link_save() puts attributes in the "options" column of menu_links. And features should support those options as well.

Here's the patch re-rolled to apply to -dev instead of 1.0-beta8, since I couldn't get the above patch to apply to -dev.

johnalbin’s picture

johnalbin
they/他
Primary language English
Location Taipei, Taiwan
commented

Also, individually clicking on each menu link when you want to export all the links in a menu is OMG awful. Perhaps add a checkbox for "all links" in a menu?

yhahn’s picture

yhahn commented
Status: Needs work » Fixed

Thanks for rerolling.

I'm guessing when you applied #18 you didn't have this commit? http://drupal.org/cvs?commit=386952. I ran into this as well and it was because the form API key for these elements included characters that conflicted with the AHAH js handling (they were being confused for some jQuery selector syntactical elements). The commit above fixes this by encoding and then decoding such characters.

The patch does indeed handle the options key as well as nearly all the other columns in the menu_links table except for plid which it makes portable by converting to the link path of the parent and relinking on install.

I've now committed the patch here: http://drupal.org/cvs?commit=395030. Let's deal with adjustments and other issues in separate tickets.

kalis1’s picture

kalis1
Location Lyon
commented

subscribing

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.