Export Menu links with UUID

This module is not supposed to preserve node ids - and it wouldn't work if it did.

So although I haven't tried exporting nodes yet, i doubt this is a bug.

Node id's are a serial id from the node table and can not be used across multiple sites. Preservice nid's is not the answer. Perhaps exporting menu links against the UUID would be an anser.

So this module works by creating a UUID for the node using the UUID module. The UUID is unique per site, it's considered a GUID. We just need to create a patch that modifies the menu links as they are being exported, replacing the nid with a uuid for paths like 'node/[nid]'.

This is a show stopper for us at the moment. I think the whole point of having this in a feature is that you would expect it to link to a menu somewhere. Otherwise you just have content floating on in the abyss. I would like to help. Seems like we would have to patch the features module. It should check if uuid is being used. If so export the uuid. Then when we don the import it needs to do the translation. Doesn't sound to bad.

I tried to work on a patch. I modified features/includes/features.menu.inc. Might not be the best approach. It works but the content needs to be in place before the menu_link can be loaded. Otherwise the feature will show that it is overridden until the menu_link can be reverted. The only way to fix this would be to make uuid_content features get loaded before menu_links.

this patch is broken, I was working on it late and didn't upload the correct one. Looking for it now.

Found it.

Patch from #9 with a fix so duplicate menu links aren't inadvertently created. It patches the features module.

This is a patch against the Features module - Moving to the proper queue and reviewing today.

Here's some background on why I'm interested in this patch:

Goal: Export menu links that match a defined sitemap for the Conference Organizing Distribution (COD).

Challenge: We want to point to both arbitrary callbacks and Views based on their path alias. However, the nids of these node changes across sites.

For example, Looking at a slice of our primary links, we want:
/schedule (points to a node created during .install or exported by UUID Features )
/schedule/sessions (points to a view defined in a feature)

Here's a slight re-roll with

-    if (!$existing || in_array($link, $menu_links)) {
+    if (!$existing || !empty($menu_links[$identifier])) {

This conditional was preventing certain menu links from being saved. Specifically, the links that were not being saved were menu links pointing to a page view that was a child of a node+ menu link combo exported by uuid. The conditional was failing because the menu link in code refers to a parent uuid, which earlier in this function we change to the actual parent_path. Because the altered $link no longer matched the one passed in with $menu_links, it was never saved.

Note that this depends on the patch at http://drupal.org/node/860974#comment-3505484 .

Subscribe

This patch works great!

But say .. is it possible, that it doesn't take care of the second level menu/hierachy?

Now, every node and menu link shows up for the parent pages.
Just the child pages menu links don't show up.

I tried to grasp the problem within 968826-features-menu-uuid.patch but somehow I am a bit rusty I guess :-S

subscribe

@ezra-g - #12 (& dependent patch) seems to be working like a charm. Exact same use case, for deployment.

subscribe

re #12: just noticed node_get_by_uuid() is now called a few times without checking if module_exists('uuid')

added module_exists() check for the one part of the patch it is needed at. re-uploading.

Marking as needs review per #19.

The patch in #19 has a couple of obvious problems even before I apply it. It blindly assumes that the link_path is an internal Drupal link to a node (e.g., node/NNNN). Linking to anything else (a view, a module-generated page, an external link) would try to pull a node out of who-knows-what. Additionally, it blindly assumes that there is a $node->uuid, without checking if it exists. While the next check will catch it, this will throw a PHP warning on a node without a uuid.

subscribe

Looked at it also and saw what 21 saw, so needs work.

Moving most major feature requests to d7; is this relavent for d7?

Subscribed

Very relevant for D7.

I ran into this issue on a recent project and ended up coding my own solution for the 6.x branch. I've created an issue for it in the features uuid issue queue here #1283742: UUIDs for Menu Links.

My solution worked by looking for node and user auto load functions in menu router paths and switching out the arguments for their respective UUIDs.

Since the work so far is against 6.x it seems reasonable to leave this as 6.x unless a maintainer comments to say they want to follow the "fix in 7.x, backport" flow instead of a "fix in 6.x, forward port" flow.

The policy for features is that feature requests cannot go directly into 6.x without going into 7.x first (unless they are irrelevant to 7.x) :/

No problem - great to have that direction.

I would suggest this functionality to live in uuid_features module instead of features itself.

I have written a patch for Features 2: https://www.drupal.org/node/2353585

This was already "fixed" in #2353585: UUID export and import of menu items linking to nodes, terms and users.
The solution that was committed is far from perfect, but it does make this old issue obsolete.
Closing as duplicate.

Adding a link to the new Feature Menu UUID module.