I feel that the creation of menus and menu items should still be in Version 2.
I'm working in a situation now that is a prime example of why this is important.
We have a platform that shares many features. But as new sites are rolled out on this platform, each site has it's own completely unique primary and footer menus. There are multiple team members working on the same site, which uses a base profile to install features and sets variables. We are extending this base profile with a subprofile which covers all these site specific needs (dummy nodes, blocks, menus, menu-items). The items in this subprofile are not going to be shared on other sites and only needs to be executed once, during the install.
By using dummy nodes we were able to build internal menu items in Primary menu. But since Drupal doesn't ship with a Footer Menu by default profiler is unable to create this for us. External linked menu-items do not get created for either menu.
It's much easier to define menus and menu-items in profiler than it is to build them into a feature. Also, profiler can be created prior to ever building a site. If there's a way to programmatically build the .info file for profiler (example: by scraping the live site) then this saves a lot of time, instead of creating the menu in Drupal UI then exporting to a feature. This also cuts down the chances of human error.
Comments
Comment #1
q0rban CreditAttribution: q0rban commentedHmm, I'm definitely torn about this. I'm going to keep this issue open, but in the mean time, you should be able to add these functions (along with adding a install_profile_api dependency) to your base profile and get this working:
Comment #2
lefnire CreditAttribution: lefnire commented+1 for menu_links available to profiler info files. Might add menu-item defaults a la https://gist.github.com/1355255#L49 so info doesn't have to declare all menu-item keys?
Comment #3
jessehsI also was looking to do this. The main problem I was having was that the main menu is created as flat, rather than hierarchical, due to us not knowing what to specify as the parent menu link id (pid) for the link.
The following code in the my_profile.profile file will create a whole slew of pages, each of them having menu links. The cool thing is that the whole main menu hierarchy is set up during the site install. I don't know if this will work during the actual hook_install, but I'm running it after the site is installed, using an additional submit handler on the site configuration page:
Comment #4
q0rban CreditAttribution: q0rban commentedI'm still leaning towards Features handling this sort of thing. Please give me a strong argument if you think otherwise. :)
Comment #5
lefnire CreditAttribution: lefnire commentedOne reason against features is that people may want to use the profile to simply setup some dummy content, including menu-links -- but the client will likely change this dummy content off the get-go, and we don't want that to cause feature-overrides. Aka, the initial content isn't as set-in-stone as some perma-content that a feature-based module might manage.
Comment #6
q0rban CreditAttribution: q0rban commentedI'm now in favor of bringing this back. I've never used the menu_links component in Features before, but it's being used on the current project I'm on, and it's nothing but headaches all around. This should be worked on for 7.x first.
Comment #7
jessehsMarking as duplicate of #1921880: Support hierarchical menus on node creation.
Comment #8
jessehsOn second thought, menu links pointing to external paths or non-node paths (like taxonomy term pages) cannot be created in the way linked above. Reopening issue.
Menus, however, can be created using Features.
I believe this patch may be necessary:
#995156: Use vocabulary machine name for permissions (#31)