Hi, I'm starting new issue about support of other callbacks than node_page_view as I've written here: #333202: Support non-node menu items
My new module NodeSymlinks allows that nodes can appear on multiple different places of the website navigation and has different menu driven breadcrumbs and active menu trails.
Because my module uses other page callback than node_page_view, NodeSymlink menu items are not listed on the SubmenuTree pages. Only type which is working now is a Menu view.
You have written that I can override SubmenTree in nodeapi. At first, I tried to do it in this way, but then I needed to copy two or three functions which generated the menu trees and overwrite some parts of them in my module. But I didn't like doing it this way, because it is duplicate computing of the same thing. So I begun to think about simple API which will allow to process different page callbacks with other modules before it is rendered in SubmenuTree.
Invoking API callback in your module:
function _submenutree_menutree_view(&$node, $type, $tree) {
...
$items = array();
foreach ($tree as $k => $v) {
// use page_callback == node_page_view to detect nodes
if ($v['link']['hidden'] == false && $v['link']['page_callback'] == 'node_page_view') {
$nid = substr($v['link']['href'], 5);
$child = node_load(array('nid' => $nid));
$items[] = array(
'node' => $child,
'weight' => $v['link']['weight'],
'title' => check_plain($v['link']['title']),
'path' => $v['link']['href'],
);
}
// launch submenutree hook
elseif ($v['link']['hidden'] == false) {
foreach (module_implements('submenutree') as $module) {
$function = $module . '_submenutree';
$item = $function($v);
if (!empty($item)) {
$items[] = $item;
}
}
}
}
...
}
// Small change - using $item['path'] allows to use any path, not only hardcoded node/nid
function theme_submenu_tree_titles($items, $title = null) {
$list = array();
foreach ($items as $item) {
//$list[] = l($item['node']->title, 'node/' . $item['node']->nid);
$list[] = l($item['node']->title, $item['path']);
}
return theme('item_list', $list, $title);
}
Current implementation of the new hook in NodeSymlinks module
/**
* Implementation of hook_submenutree
*/
function nodesymlinks_submenutree($menuitem) {
$item = array();
if ($menuitem['link']['page_callback'] == 'nodesymlinks_page') {
list(,$nid) = explode('/',$menuitem['link']['href']);
$node = node_load(array('nid' => $nid));
$node->path = $menuitem['link']['href'];
$item = array(
'node' => $node,
'weight' => $menuitem['link']['weight'],
'title' => check_plain($menuitem['link']['title']),
'path' => $menuitem['link']['href'],
);
}
return $item;
}
Patch against SubmenuTree 1.3 attached.
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | hook_submenutree_item.patch | 2.23 KB | mstrelan |
| submenutree.patch | 1.5 KB | wojtha |
Comments
Comment #1
bengtan commentedHi,
Interesting idea. With this post, I have a much better idea of what you are trying to achieve. However, I think the idea needs more thought.
Submenutree only works with nodes. That is by design because submenutree renders menu items as titles, teasers, and full text. Only nodes have an inbuilt teaser and full text view. Hence, submenutree only knows how to work with menu items which are also nodes.
Submenutree tests that a menu item's page callback is node_page_view() as a way to make sure the menu item is a node. Otherwise, there is nothing special about node_page_view().
If you want me to accept a patch for submenutree that generalises the 'things' that submenutree can handle, the patch will need to be able to handle 'things' which have a title, teaser, and full text view. So, your suggested hook_submenutree() will almost certainly need some sort of $op parameter so submenutree can retreive that 'thing's title, teaser and full text view.
However, before going down this generalisation path, I have a suggestion which may be simpler for us both.
As I said earlier, there is nothing special that requires submenutree to check that the page callback is node_page_view(). If there is another way to test that a menu item is a node, which also works for your module, then I will happily change the criteria.
For example, with Drupal 6.x, there is a menu_get_object() function that can be used to retrieve menu item's node (if it exists). If that works for submenutree, and works with your module, then we can use that instead.
Comment #2
wojtha commentedHi bengtan,
thank you for the fast reply. Yes, you are right with the $op parameter. I knew that something like that will be needed. My code was supposed as an initial concept to start discussion about that and it was also reason to mark this issue with 'code needs work' status.
I will try to test menu_get_object(), but anyway I like the idea to have more generalised SubmenuTree and I think that the implementation of the idea will be easy. And hopefully not much work for you ;-)
We only need to pass an 'abstract' item to submenutree themeing functions. Item will always have title, body and path, so it can be themed in a "universal" way. These values (title, body, path) can be rendered in the submenutree hook. Ordinary node will be always rendered by Submenutree directly so the speed will be same as before for ordinary nodes.
Alternatively in the submenutree can be defined theme functions which override default SubmenuTree item/node themeing functions.
Comment #3
mstrelan commented+1 on this issue. Most importantly I'd like to be able to see a View (page display) appear in a submenutree. Currently I am just making a node for each view and embedding the view on that node. This works ok but I'd rather not do that. Ideally when a view appears as a menu item I would like submenutree to handle it like this.
Title - display view title
Teaser - display view header / provide an additional field for teaser text
Full view - embed the view
Comment #4
bengtan commentedExpiring this issue as it is very old and I'm not sure if it is still applicable.
Comment #5
mstrelan commentedI would still love this feature! My "about" page has 4 sub pages. 2 of these are regular nodes the other 2 are "faq" and "testimonials". FAQ is the faq module, testimonials is a view. I would love for a textarea to enter a teaser for each of these. I think submenu tree could create the API, and provide implementation for Views and FAQ modules, similar to how Views provides implementation of various other modules to integrate with itself.
Comment #6
wojtha commented@mstrelan We can use at least menu item Title and Description.
Comment #7
devin carlson commentedMarked #1359318: Enable submenutree display for alternative view modes as a duplicate.
Comment #8
arski commentedNot 100% sure that's quite duplicate, but I guess it is if you look at it very abstractly.. Anyway, what I was looking for in that other issue is a way to configure submenutree to display its data in other $op's of a node, other than view, i.e. in print mode etc. Hope this fits here and will be figured out sometime.
Cheers
Comment #9
devin carlson commentedYes, it is definitely a bit of a stretch from your original request, but I believe that most of the past requests to allow Submenu Tree to deal with different types of content can be attributed to the same set of limitations (and a solution should be abstract enough to fit multiple usage patterns as bengtan explained).
Can you take a look at the work wojtha did on Submenu Tree Advanced and Submenu Tree NG and see if that suits your needs?
Comment #10
arski commentedhmm, not really, those allow one to control how each piece of sub-content is displayed. What I need is control over what states of the parent content have submenutree at all. That's why I thought these would be two different aspects of the issue, but anyway.
Comment #11
mstrelan commentedHere is an initial stab I took at implementing this hook. It will only work for menu and teasers, should only be a little more work for titles and full nodes.
This patch requires other modules to analyse the menu item and determine whether to return content for submenutree. It's a bit of a mess because the module implementing the hook doesn't know which submenutree style is being used. I don't recommend anyone attempt to use this patch, but that the idea of this patch be considered.
Comment #12
ivnish