question/request for extended primary links block

Hi,

Thanks for your feedback.

The philosophy behind submenutree is to keep things simple. I think trying to accommodate everything you have described would break that, and possibly all those extra options will confuse people.

However, you could certainly use other modules (possibly with in conjunction with submenutree) to achieve what you want. You might also want to look at Local Menu which might help.

If it seems like I'm not being helpful, it's because I get the impression you haven't fully decided what you want yet. Perhaps once you've decided on the final form of your navigation scheme, we can revisit this issue?

G'day,

Thanks for your quick reply.

I guess I made things look complicated by going on some tangents, aka rambling, instead of getting to the point directly.
What I'm thinking of would in fact seem to make things simpler, so I'll try to explain it a bit better, or at least differently.
Right now, you've got three different blocks, siblings, submenu and extended primary links.

The first one shows the siblings of the current page plus their respective submenus (assuming you use "menu"), the second just shows the submenu of the current page, and the third shows the submenu tree from below the primary menu (or secondary, if enabled).

To me this looks like three special cases of one more generic type of functionality, which is to show a submenu tree (sic!), only starting at different points. So rather than having to use one of three pre-defined points, and using one separate block for each, I was wondering if that could just be combined into one - that would immediately simplify things by throwing out two of the three blocks and one of the two configuration masks in the page itself.

The remaining configuration mask would need a few more options in order to accommodate for the combined functionality, however it would still not be too complex, though much more flexible. Basically it would keep the four elements that are there now (enabling checkbox, title, display choice, weight), however there would be only one set of those rather than two, which would get any or all of the following in addition:

1) an option to choose where to anchor the submenu tree.

If one selected the level of the current page, functionality would be the same as for the siblings menu.
Selecting the immediate child level would give the same result as the submenu option now.
Selecting first child level of the primary would give the same as extended primary links with secondary menu disabled.
Selecting second child level of the primary would be the same as extended primary links with secondary menu enabled.
(Only the latter two could be chosen independently of the secondary menu, for example replicating the chosen secondary menu item in the generated menu, like in the first example in my original post.)
Further, selecting the level above the current page would include the parent of the current page, selecting the level above that would include the grand-parent, etc.
Implementation could be as simple as a pop-up menu to choose a number between 1 and 9, one representing the root of the menu containing the page (doesn't need to be the primary links menu, but could be), 9 its farthest leaf (as far as I understand menus are limited to 9 levels deep, however the menu could potentially accommodate any number).
Or it could be more sophisticated and offer either an absolute level, as in counting from the menu root, or a relative one, i.e. counting from the current page (- for counting up, + for down: -1 = parents, -2 = grand-parents, etc, +1 = children, 0 = siblings).
Wouldn't need to be, though, a simple pop-up with numbers would do.

2) an option to choose whether to show siblings at the top level, or just the chosen option.

This might make sense both with the extended primary links block as it is now, and with a flexible anchor block as proposed in 1).
Implementation could be as simple as a check-box.

3) an option to choose how deep to extend the generated menu.

So if there are six more levels of submenus, one could choose to show only one or two, so that one only gets to see the rest once one gets there.
Implementation would probably be a pop-up menu with numbers from 1 to the maximum remaining depth of the menu hierarchy under the current page.

4) an option to choose whether to show siblings' submenus or not.

This is the same as the current choice between "Menu" or "Titles only", so in fact it's already there.

So overall, adding all of the above functionality in the simplest possible way would result in one block instead of three, one set of options in the page editing form instead of two, with that one set having two additional pop-up menus (containing numbers 1-9 each for choosing menu anchor level and nesting depth) and one additional checkbox (for choosing whether to show siblings of self or/and ancestor(s)).
In terms of overall complexity and interface clutter that seems more like a net gain to me, besides being more flexible.

I understand that you think I might not quite know what I want, however I do. I set up the site I referred to above to explore different options to organise my site, and what I ended up liking most is a structure as shown in the first address in my post above, and sub-items:
spiritofdiscovery.com.au/content/one-point-one-point-four

You can see that the secondary menu is enabled, and the menu on the left has an overlap with it, in that it starts with the currently chosen item on that menu. Also it only extends one level deep. So in terms of my suggestions above, the menu would start at level 2 (of the primary menu, in that case), not show siblings, and extend to level 3, or one level deep. (Ignore the page under 1.1.3 as that is for testing, I would want things to look like with 1.1.4).
I cannot replicate that structure with the siblings menu, because that would show 1.2 (the other secondary menu item) as well, nor with submenu, because that would not show 1.1. Nor with extended primary links, because that would not show 1.1 either, because it already appears in the secondary menu.

Now if you look at 1.1.4, the menu at the right could at this stage be replicated with submenu. The ones in 1.1.4.2 and 1.1.4.3 could be substituted with siblings menu. However for the one in 1.1.4.3.1, there is no simple substitution. With the functionality as suggested above, I could replace the menu in all those pages with one that extends from levels 4 to whatever depth I choose (or is available) and be done, same setup for all.

Thanks for pointing me to Local Menu, I had a good look at it. It can only be configured at the block level, unfortunately, and not per page, and even so it does not quite seem to do what I'd expect it to (e.g. setting it to show menus from parent level, it still seems to always generate the same menu for pages at different levels).

The reasons why I felt compelled to make my suggestion for the submenutree project are that most of what I am suggesting already seems to be there and I think they would make it simpler to use. I just thought that the situation might occur frequently that access not only to siblings or submenus is needed, but also just to the parent of the current page. Like "Ok, I went into the submenu and explored the siblings, and now what?". Extended primary links would in such cases extend much further up than required, so why not, instead of using three blocks, use one and make it configurable per page?

Anyway, just my thoughts on the matter - of course it's all up to you but I hope I have at least explained more clearly what I had in mind. If you were to implement some or all of my suggestions then I would definitely find that great, if not then that's fair enough and I'll just keep building my menus by hand. :-)

Cheers,

Ronald

Hi,

Ah, now I see what you're getting at.

I never thought of unifying the 3 types of menus, and it's good that you've alerted me to the possibility.

Historically, I never considered sibling menus, and didn't think there was any need for them, until an individual or two specifically requested them, so I added it in as a quick addition.

Now that Extended primary links has also been added in, perhaps there is a bit too much duplication.

However, while I agree that the general idea has merits, I'm not sure I'd do the unification any time soon. Firstly, it's going to require a dramatic change in the database tables used to store the configuration, and secondly, I can't quite justify making the time available to do it, amidst everything else that I (and by extension, ThinkLeft) am doing at the moment.

It's worthy of doing for the future (perhaps as a 2.x rewrite), but I judge that, right now, it's not worth doing yet. Of course, that is not to say that my opinion won't change.

Finally, there might be a small number of users out there who use both submenus and sibling menus together, and unifying the blocks will break their site. I don't know if there actually are any, but Murphy's Law will probably mean there is at least one.

Thanks,

Hi,

Thanks for your comments.

Firstly, great that you like the idea! :-)

Of course, if you don't have the time to do it, or/and don't think it's worth doing now, then it's not going to happen and that's fair enough. After all I am not in a situation to make a request - I made a feature request but it was more respectfully requesting that you think about it, which you have obviously done. So thanks for that, and for your feedback.

I agree that a fundamental change such as that may break someone's installation. I guess the cleanest way around that might be to make the changed version a new project and give current users of the current system ample notice to convert their sites before any major upgrade would be necessary. Anyway, that's just my guess, there may be other ways and you probably know better how to handle such changes.

Thanks again & best regards,

Ronald

Hi,

Just came across this one which looks pretty promising (haven't tried it yet):
http://drupal.org/project/menu_block

Cheers,

Ronald