Add API to obtain raw menu data (not the render element)

The patch doesn't apply to HEAD (7.x-3.x) or to 6.x-2.x, so I'm not sure which branch you mean.

If you actually look at the existing code in the menu_block 7.x-2.x/7.x-3.x, you'll see that menu_tree_build() doesn't return HTML; it returns a renderable array like all good d7 modules should.

There's also hook_menu_block_tree_alter() which allows you to get at the data you say you want. Have you tried that? Its documented in menu_block.api.php. There's also a boat load of theme hook suggestions documented in the README.

The patch looks redundant to me.

Although it’s not obvious in the diff patch, menu_block_tree_build() is really just hooking in to the original version of menu_tree_build() before it does its rendering work. Yes, I suppose I could create a hook_menu_block_tree_alter() hook, invoke menu_tree_build() and then pull the data out at the hook, but then menu_tree_build() would proceed to repeat what else I needed to do to the data,

I still don't understand the use-case. What data do you need out of menu_tree_build() that you aren't getting with the existing hooks?

A use-case for this feature can be seen in accordion_menu module which is looking for an array of links as would be returned by menu_tree_build prior to the render tree code (as mentioned by the OP in #6). I also believe that jquerymenu has a similar requirement.

@Daniel Norton thanks for the patch.

Ok. I understand what you want now. You want access to the raw menu data, like core's menu_tree_all_data() and menu_tree_page_data(). And you don't want the render element that menu_tree_build() returns because you want to create your own decorated render element from the raw menu data.

What about this patch?

@JohnAlbin - Is #913632: Make the altered menu tree available to other modules before rendering a duplicate of this issue?

I've commited the patch. Let me know if you feel something needs to be tweaked in order to make 3rd party module integrate better with the new API.

@john, in response to #11, the patch could definitely be tweaked "to make 3rd party module integrate better."

The patch committed split up menu_tree_build() into:
- menu_block_get_current_page_menu() and
- menu_tree_block_data()
but left code that should have been moved.

So, for a 3rd party module to use the "new API," it needs to duplicate the code in menu_tree_build() before the renderable array is created, to wit:

  // Retrieve the active menu item from the database.
  if ($config['menu_name'] == MENU_TREE__CURRENT_PAGE_MENU) {
    $config['menu_name'] = menu_block_get_current_page_menu();
    $config['parent_mlid'] = 0;

    // If no menu link was found, don't display the block.
    if (empty($config['menu_name'])) {
      return array(
        'subject' => t('The menu selected by the page'),
        'subject_array' => array(),
        'content' => array(),
      );
    }
  }

  // Get the default block name.
  $menu_names = menu_block_get_all_menus();
  menu_block_set_title($menu_names[$config['menu_name']]);

  // Get the raw menu tree data.
  $tree = menu_tree_block_data($config);
  $title = menu_block_get_title($config['title_link'], $config);

This is not a robust API to latch onto.

Compare this to the simple patch for version 2.3 suggested on #1452660: Support a sub-menu API by separating code for tree building and tree rendering and included here. All that was and is needed is to split menu_tree_build() at the point it generates the renderable array. The latter approach allows a contributed module to write:

  $menu_block_config = menu_block_get_config($config['block_source']);
  $tree = menu_tree_build($menu_block_config);

and go off and render the tree as it sees fit.

Please consider this approach.

Is #13 likely to be considered?

Wow, 5 years old issue that became active again 2 years ago...

Any chance to see that implemented (or do you have another module to suggest to generate menu tree that would be compatible with third parti module ? (example jquery Menu)) ?