First of all, i've searched everywhere and couldn't find a solution for this. I'm quite sure it's a bug and gotta be fixed for drupal 5.x , because it's the most recent version.
Note: This problem happend with me when i created two blocks, set the 'view permission' of that for 2 kinds of roles: X and Y. When i created a menu and tryed to expand it on Y, it was expanded on X.
I think this is how it works...
The Drupal menu system has being very similar to the traditional concept of a sitemap. A traditional sitemap lists every link available on the site, usually grouped together.
- link
- link
- link
- link
- link
The menu system is such a list of links, but this time with your Drupal paths(links) (such as nodes).
- [node/1]
- [node/3]
- [node/4]
- [node/2]
- [node/5]
It is key to differentiate between menu items and paths. Drupal's menu system (or sitemap, as I like to think of it) is based on paths (so, if change this 'paths' to menu itens, this problem would be solved.). Menu items are more or less just labels for paths. Parent/child relationships are based on paths, not menu items.
A common source of the behavior you are noticing is having two menu items pointing to one path, ie:
- [node/1]
- [node/3]
- [node/4]
- [node/4]
- [node/5]
So now Drupal has to decide which menu to display: the child [node/4], or the parent [node/4]. Which to display as currently selected? Which to display as expanded? How can the child of [node/1] also be the sibling of [node/1]?
Well, from what I can tell, Drupal will determine this based on ranking in the menu system. Those earlier in the menu will be chosen. So in the example, the child [node/4] is displayed. The parent [node/4] is all but ignored and not expanded. So:
- [node/1]
- [node/3]
- [node/4] DISPLAYED
- [node/4] IGNORED, because the 'node/4' listed before, is already expanded. thus, this 'expanded menu item' will not be expanded
- [node/5]
I've got the text above and made my own modifications from: evo. Post: http://drupal.org/node/87649
What i think would be the solution for this problem:
As said above, the 'Menu Items' are not items, they are only PATHS, that once opened in one menu, is ignored in oneother because it's already opened on the first.
So, if *someone* set Menu Items to be created as ITEMS with diferent ID's(and you put to this ID's the path you want), once clicked it 'call' his sons(with oneother ID seted automatically by Drupal), the problem of showing/not showing would be solved.
I got the 'project' of how to fix that all on my mind. I just don't know HOW to DO that on Drupal(once i'm not a Drupal Master).
Contact me:
e-mail: sanlucas@triang.com.br
ICQ: 251-233-647
MSN: lucas-boaventura@hotmail.com
Comments
Comment #1
stevenpatzComment #2
sanlucas commentedPriority: critical » normal
I don't think that a MENU problem, that is the 'soul' of a website, is not a critical problem, but as you want to think like that, its not my problem.
Status: active » active (needs more info)
What kind of info? I sended you and email asking for what kind of info you want. I'm all ears.
Comment #3
stevenpatzIs it still an issue for 6.1?
Comment #4
sanlucas commented6.x I'm *quite* sure that won't be done for this year, or at least for the middle of this year, and once that this is a CRITICAL(because its a menu bug, and menu is everything on a website) bug. I don't know if thats and 6.x issue, I only KNOW that it's a BUG on 5.x version that can be corrected and would be great if someone else read this...
I don't think that shoulda only be corrected in 6.x, its not that hard to give each menu item an diferent ID and stop 'reading' it by path.
If someone wannna know an 'alternative way' to solve this(because drupalers masters don't seem to give *nothing* for that)
get:
Comment #5
Conditi0n commentedhttp://drupal.org/project/taxonomy_menu_trails