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.
Oddly enough, if you point the menu item to /taxonomy/term/[id]/all,
menu subitems won't expand! I don't know how to fix this.
Comment | File | Size | Author |
---|---|---|---|
#13 | drupal-6.19-menu-not-expanded.patch | 567 bytes | setvik |
#8 | drupal-6.15-menu-not-expanded.patch | 574 bytes | Dmitriy.trt |
Comments
Comment #1
joric CreditAttribution: joric commentedFor now i've just changed modules/taxonomy/taxonomy.pages.inc:
-function taxonomy_term_page($str_tids = '', $depth = 0, $op = 'page') {
+function taxonomy_term_page($str_tids = '', $depth = "all", $op = 'page') {
It includes all levels by default, so I don't need "/all" anymore.
The taxonomy_forceall module is kind of even worse - it ruins the whole menu highlighting by overriding the url.
Any suggestions?
Comment #2
gatiba CreditAttribution: gatiba commentedSame problem here, on Drupal 6.9.
Comment #3
sultancillo CreditAttribution: sultancillo commentedThe problem is in the _menu_translate function in the way it constructs the href element of the $router_item
right here:
it assumes that anything after a forward slash is a page argument, so when a menu item contains the '/all' argument it goes to the $link_map array separate from the term id argument. Since the size of the $link_map is smaller than the $path_map array, the '/all' part of the path never makes it to the href and then the menu system can't find a matching menu element for the href and therefore no secondary links are generated. i wrote the following patch
it checks first if the $path_map contains more elements than parts set up for this menu item, if this is the case, it adds them at the end.... Can someone review and see if this is Drupal worthy????
Thanks in advance for pushing this to the core
Comment #4
-Anti- CreditAttribution: -Anti- commented> Can someone review and see if this is Drupal worthy????
Sorry, I can't help you take this forward regarding scripting, but I agree that this does need to be fixed in core.
Can I just check though... I assume that the menu highlighting and 'active trail' aren't just affected by /all,
but also the other parameters like /1+2+3 and /1,2,3 and combinations like /1+2,3
Are they included in the fix?
Comment #5
sultancillo CreditAttribution: sultancillo commentedThis one works in all those cases.... The '+' is internally interpreted as a blank space and therefore the href did not match any of the menu items.... did a str_replace to get those + signs back
It's kinda kludgy i think, but should provide a starting point for someone that is in charge of maintaining this in core....
Comment #6
-Anti- CreditAttribution: -Anti- commentedHow does this fix get taken forward to be included in D6.13? Does anyone who works on core realise what a frustrating bug this is for people who use menu highlighting/expansion to keep their users informed where they are on the site, and to give an illusion of 'sections'?
If you've got a taxonomy like:
- news
-- announcement
-- event
-- bulletin
You'd probably want a menu like:
- taxonomy/term/1/all
-- taxonomy/term/2
-- taxonomy/term/3
-- taxonomy/term/4
However, this bug means you have to build a view just to mimic the taxonomy/term/1/all list
Very frustrating!
Comment #7
Dmitriy.trt CreditAttribution: Dmitriy.trt commentedProblem is not only about taxonomy. Same problem appears on each page where number of arguments more than number of router path parts. For example, I create view with url "cars" and add argument to it (path doesn't have % at the end, but it still works, view still receives argument). This creates router item "cars", but not "cars/%". Then I create menu items with paths:
- cars
-- cars/1
--- cars/2
-- cars/3
And you'll never see this item:
--- cars/2
because href of ALL items will be "cars".
Fix from #5 breaks tabs in some cases, for example, on the page "node/1/edit" tab "View" will point to "node/1/edit" instead of "node/1".
Bug still exists in 6.14.
Here is my fix. In menu_get_item() after line
$map = _menu_translate($router_item, $original_map);
insert
$router_item['href'] = $path;
So, for current menu item we'll have full href, but tabs still can have truncated href to function properly. Fix is not optimal for performance, we should prevent _menu_translate() from constructing href, if it was called from menu_get_item().
Comment #8
Dmitriy.trt CreditAttribution: Dmitriy.trt commentedPatch contains only one change described in my previous comment. Looks like it works and fixes long standing bug. Patch was made for Drupal 6.15
Comment #9
bloke_zero CreditAttribution: bloke_zero commentedPatch above works for be - I have a link to directly edit a block and the parent was not expanded, but after the patch it is - thanks!
Comment #11
Summit CreditAttribution: Summit commentedHi, Shouldn't the patch be succesfull? Now it is not committed, right?
greetings,
Martijn
Comment #12
Boarder CreditAttribution: Boarder commentedThe change that patch #8 applies worked for me. I finally have my taxonomy/term/n/all menu links back. Thank you. Using Drupal 6.19.
Comment #13
setvik CreditAttribution: setvik commentedChanging to major for reasons listed in #7.
Patch in #8 worked for me. Rerolling for 6.19
Comment #14
setvik CreditAttribution: setvik commentedComment #16
Murli CreditAttribution: Murli commentedI've got Drupal 6.19 and this patch doen't work for me. Any other Ideas? The problem occurs, if I put the Taxonomy-Menu into Primary Links. on Navigation.Menu it works pretty well. but on Primary-Links it doesn't expand, no matter If i select to show the descendents or not.
Comment #17
Murli CreditAttribution: Murli commentedNoboy here who can help me?
Comment #18
Summit CreditAttribution: Summit commentedHi, I have the same problem, same settings using taxonomy_menu, and not expanding, no matter what I do.
greetings, Martijn
Comment #19
Dmitriy.trt CreditAttribution: Dmitriy.trt commented2 Murli:
Please, try to use http://drupal.org/project/menutrails
Comment #20
crifi CreditAttribution: crifi commentedFor information: A similar issue is reported for Drupal 7 here #251868: Menu doesn't play well with taxonomy/term/%/all pages. The discussion in this issue is to backport the patch to Drupal 6.
Comment #21
EvanDonovan CreditAttribution: EvanDonovan commentedPatches are made against the highest version of Drupal core currently in development, and then backported. Thus, this issue is actually a duplicate of #251868: Menu doesn't play well with taxonomy/term/%/all pages, unless it is not the same problem causing it.
If isn't the same problem, then this issue still needs to be turned into a 7.x bug, and a patch for 7.x, then backported.
Sorry if this is inconvenient for you all, but it is the policy.
Comment #22
tamsoftware CreditAttribution: tamsoftware commentedHi,
My two cents - I had a taxonomy menu system working fine under 6.20 and after upgrading to 7.0 it's broken, so I'd think it's precisely linked to 7.x.
In Primary links, menu item "References" linked to a book page
Taxonomy menu adding the clients to the "References" menu.
In 6.20, click on "References" opens the book in contents and expands the menu.
In 7.0, click on "References" opens the book but the menu never expands. When looking at the menu structure all menu items are present, and if I set the "References" menu to be expanded, its contents appear.