Menu Block support UUID

What steps should I take to test this patch?

Lampson, this patch has been running in production for quite some time. If we upgrade to 1.8 we would lose the patch, as it's been removed. We'd have to re-apply the patch.

This patch has been tested by creating many menus and adding them to a feature on the source site and reverted it on the destination site. No issues. Please add this patch to next release.

Ok, we need that patch refactored, however it only applies on the old revision of menu_block

the patch needs to be refactored for menu_block v7.x-2.4 currently used by wetkit_core
projects[menu_block][version] = 2.4

the patch previously only applied on 7.x-2.3+37-dev
projects[menu_block][download][revision] = 32ab1cf

but it no longer applies

Sylus, can you please refactor this patch for us? :)

diff --git a/plugins/content_types/menu_tree/menu_tree.inc b/plugins/content_types/menu_tree/menu_tree.inc
index 1b75582..f89c1cd 100644
--- a/plugins/content_types/menu_tree/menu_tree.inc
+++ b/plugins/content_types/menu_tree/menu_tree.inc
@@ -129,6 +129,9 @@ function menu_block_menu_tree_content_type_edit_form_submit(&$form, &$form_state
   foreach (array_keys($form_state['subtype']['defaults']) as $key) {
     $form_state['conf'][$key] = $form_state['values'][$key];
   }
+  if (!empty($form_state['values']['parent'])) {
+    list($form_state['conf']['menu_name'], $form_state['conf']['parent_mlid']) = explode(':', $form_state['values']['parent']);
+  }
 }

this is the diff between 2.4 and 2.3 dev hash 32ab1cf

I've refactored the patch we were previously using for menu_block v 2.3
the new refactored patch will apply for menu_block v2.4 , we'll have to do a test on it, but I'm very confident that having run the patch for several months in production that the bulk of it has been tested, just two lines of code were refactored in the patch. See the last part of the menu_block_menu_tree_content_type_edit_form_submit function, the last two lines come from v2.4 that were not present in v.2.3

See attached patch: (patch 13 is for wetkit 1.8 (probably also wetkit 4.x)) for menu_block v2.4
the original patch 1 is for wetkit 1.4 (which used menu_block v2.3)

the patch from comment #13 will not apply if you previously are using the two other patches specified in witkit_core.make
so I made a new patch that will apply after the other two patches have been applied.

projects[menu_block][version] = 2.4
projects[menu_block][subdir] = contrib
projects[menu_block][patch][2199997] = http://drupal.org/files/issues/fix_menu_system-2199997-14.patch
projects[menu_block][patch][2199998] = http://drupal.org/files/issues/fix_menu_language-2199997-20.patch

there should be a third patch added
projects[menu_block][patch][2282933] = http://drupal.org/files/issues/uuid_menu_block-2282933-14.patch

see attached patch for uuid support with menu_block for wetkit

As per comment 15

Ok, had another look at this patch....

Here's the API documentation for ctools_uuid_is_valid.

if a valid uuid is passed into ctools_uuid_is_valid then true is returned, otherwise false.

but yet in the patch there's this section of code:

diff --git a/plugins/content_types/menu_tree/menu_tree.inc b/plugins/content_types/menu_tree/menu_tree.inc
index 5a113dd..0242d62 100644
--- a/plugins/content_types/menu_tree/menu_tree.inc
+++ b/plugins/content_types/menu_tree/menu_tree.inc
@@ -75,6 +75,15 @@ function menu_block_menu_tree_content_type_content_types() {
  *   object An object with at least title and content members.
  */
 function menu_block_menu_tree_content_type_render($subtype, $conf, $args, $context) {
+  // UUID Handler.
+  if (ctools_uuid_is_valid($conf['parent_mlid']) && module_exists('uuid')) {
+    $mlid = entity_get_id_by_uuid('menu_link', array($conf['parent_mlid']));
+    if ($mlid) {
+      $conf['parent_mlid'] = current($mlid);
+      $conf['parent'] = $conf['menu_name'] . ':' . current($mlid);
+    }
+  }
+
   // Ensure the delta is unique.
   $ids = &drupal_static(__FUNCTION__, array());
   if (empty($ids[$conf['menu_name']])) {

I think this function call "ctools_uuid_is_valid" in this case will always return FALSE , unless there's a UUID somewhere inside $conf['parent_mlid']

I'm just wondering if $conf['parent_mlid'] will ever contain a UUID, it'd be handy to watch the variable $conf['parent_mlid'] during menu link creation.

We should have a closer look at this, it might be why PTS's patch is not working in my last test.

I suspect this patch might not be doing what its intended and might be causing the patch in "Menu link translations are not being linked together" to fail

oh yes of course, in the case that uuid is enabled the plid should actually contain the uuid of the parent menu link item.
just looked strange, thanks for clarifying. I'll look at the related issue "Menu link translations are not being linked together (2394485)" as a seperate issue. Should be fun debugging that one.

Re-roll #14 via menu_block-7.x-2.x-dev

This looks promising! But did I miss something or how do menu items/links get UUID's? The latest uuid module doesn't seem to support it and besides that I only found not actively developed sandbox projects to create UUID's for menu items.