Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
This module and the Block Reference module work fine together provided you’re doing the normal theme rendering, but I had a need to obtain the unrendered menu block tree like that returned by menu_tree_page_data(). This module’s menu_tree_build() function will provide a rendered menu block tree, but not the tree data.
This patch adds two API functions to this module:
menu_block_tree_build($config) - build tree data from a configuration
menu_block_get_delta($bid) - return block delta, given block ID
Comment | File | Size | Author |
---|---|---|---|
#9 | 907292-9-raw-api.patch | 8.83 KB | JohnAlbin |
#4 | menu_block_tree_build.patch | 5.03 KB | Daniel Norton |
#1 | tree_data.patch | 5.25 KB | Daniel Norton |
tree_data.patch | 5.25 KB | Daniel Norton | |
Comments
Comment #1
Daniel Norton CreditAttribution: Daniel Norton commentedCorrection to previous patch.
Comment #2
JohnAlbinThe 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.
Comment #3
Daniel Norton CreditAttribution: Daniel Norton commentedIt doesn't align with any specific source right now, except my own, which is 6-x with the patch at #898616. I'll post something normal in a day or so.
Do you have a preference as to 7-x or 6-x?
Comment #4
Daniel Norton CreditAttribution: Daniel Norton commentedPatch for 7.x-2.x-dev attached
Comment #5
JohnAlbinIf 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.
Comment #6
Daniel Norton CreditAttribution: Daniel Norton commentedAlthough 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, namely:
The value of $tree at the end of this code fragment is what I’m after, and it’s what menu_block_tree_build() returns.
Perhaps this is a very unusual need, but I don't think so. Perhaps instead of what I wrote, a hook could go here in the original code and accept a return value to tell menu_tree_build() to not bother to proceed with its rendering:
But such a hook seems a lot more complicated than adding a new function that simply returns the needed data at the point that it’s already prepared.
Comment #7
JohnAlbinI 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?
Comment #8
tklawsuc CreditAttribution: tklawsuc commentedA 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.
Comment #9
JohnAlbinOk. 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?
Comment #10
gmclelland CreditAttribution: gmclelland commented@JohnAlbin - Is #913632: Make the altered menu tree available to other modules before rendering a duplicate of this issue?
Comment #11
JohnAlbinI'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.
Comment #13
solotandem CreditAttribution: solotandem commented@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: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:and go off and render the tree as it sees fit.
Please consider this approach.
Comment #14
rooby CreditAttribution: rooby commentedIs #13 likely to be considered?
Comment #15
zmove CreditAttribution: zmove commentedWow, 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)) ?