Original message by rimen:
http://drupal.org/node/1382060#comment-5779392

Active menus are stored in system variable menu_default_active_menus and returned by menu_get_active_menu_names(). Custom menus are added to this variable when menu is saved, in menu_save(). But sometimes custom menus are not getting to this list. The reason is unknown and I can't reproduce it. If you can, please post steps starting from menu creation.

Comments

I can confirm this issue

I had the strange behaviour that on site1 the module was working and on site2 with simular configuration it wasn't .

Next, I tested the module on a clean install, and it didn't seem to work. I used a new menu for this.
After reading this issue, I added the terms to an 'original' menu 'navigation' and now the module works.

Any idea to get the module working with custom menu's?

Looks like we need a quick fix for this. The reason of problem is still unknown. I'm going to add editor for the list of active menus (to add custom menus to this list). If you know the module implementing such an editor, please let me know. I'll try to search for it too. Probably I'll have free time to do it on this weekend.

Isostar,
Which module and Drupal core versions are you using? On both site 1 and site 2. If you have Menu Block module enabled, please specify its version too.

On both websites I used the same versions:
- Drupal core 7.12
- Taxonomy menu trail 2.0
- Taxonomy menu
- (no menu Block)

Website 1 was updated from Drupal core 7.11, website 2 was installed as 7.12.
Apparently this makes a difference.
Website 1 did have the variable 'menu_default_active_menus', website 2 didn't.
This is also mentioned: http://drupal.org/node/1447466#comment-5676712

After changing the schema version of the menu module to 7002 and executing the update the variable appeared on website 2

To see the active menus and order:

<?php
$active
= variable_get('menu_default_active_menus');
drupal_set_message('<pre>' . print_r($active,1) . '</pre>');
?>

I noticed that the active trail is only applied on the active menu which is the first in the list to have the term path.
In my case I had links of term pages in multiple menu's. In order to show the active trail in the correct menu I had to adjust the order:

<?php
$active
= variable_get('menu_default_active_menus');
$active2 = $active;
$active2[5] = $active[8]; //switch order
$active2[8] = $active[5];
$active2[6] = $active[9];
$active2[9] = $active[6];
drupal_set_message('<pre>' . print_r($active2,1) . '</pre>'); //verify order
variable_set('menu_default_active_menus',$active2); //run this only once!
?>

Confirming that I'm seeing this issue as well.

Did it on a sandbox site with standard Drupal installation and only Taxonomy Menu and Taxonomy Menu Trails installed - specifically:

  • Drupal (7.12)
  • Taxonomy Menu (7.x-1.2)
  • Taxonomy Menu Trails (7.x-2.1)
  • (no Menu Block module installed)

My steps were:

  1. Fresh installation of D7.12
  2. Installed and enabled Taxonomy Menu and Taxonomy Menu Trails modules
  3. Created taxonomy "Category" and added terms to it two levels deep (ie Term 1, Term 1-1, not Term 1-1-1)
  4. Went to menu and created new menu named "Catalog menu"
  5. Back to Category taxonomy and set Menu location to "Catalog menu", links were generated, etc.
  6. Went to Basic page content type and added term reference to Catalog, set standard Taxonomy Menu Trails settings (can post, but didn't change these when it started working with Main menu so doesn't seem relevant)
  7. Displayed "Catalog menu" block in right sidebar (noticed that Taxonomy Menu defaults to all links with "Show as expanded" enabled, tried turning on and off with no active-trail or menu expansion seen)
  8. Created basic page nodes with terms chosen both first and second level taxonomy terms
  9. Went to various created node pages and saw o expanded menu or active-trail classes
  10. Stumbled across this thread, so switched the Catalog taxonomy to use "Main menu" which only had link "Home" already in it
  11. Showed that block in right sidebar and voila! (I did have to turn off the "Show as expanded" setting for level one terms to do proper expansion

Hope that helps a bit! I'll keep my sandbox environment setup and can even export and send your way if that would be helpful.

Yup, menus schema update fixed it for me too. I've got the database and site files dump to go along with it if that helps, Dmitriy.trt.

With both this module and i18n_menu running into this I'm starting to wonder if a core bug. Or at the least an API shift that both of these modules aren't accustomed to.

Looks like this is also the same thing "-sam-" ran into and just got around by switching to use Main menu (http://drupal.org/node/1413080#comment-5694664).

covenantd,
Thanks for a detailed instruction about reproducing this problem. I'll dig into it on Sunday. Your sandbox would be helpful. Could you please post DB and files of the sandbox here (using some file sharing service)? If you don't want to publish it, please send it to my email.

Emailed!

On a fresh website the variable "menu_default_active_menus" will never be created, because in menu_save() function the default value contains all custom menus, new menu is not added to the list and variable is not saved. But menu_get_active_menu_names() still returns only system menus, because menu_set_active_menu_names() uses different default value for that variable.

But this is not a problem for Drupal menu system, because the list of active menus is used just for menus order and menus are expandable even if they're not in list returned by menu_get_active_menu_names(). So, this is a bug in TMT and it will be fixed. Sorry for not providing a fix right now, don't have enough time. For a quick fix use suggestion mentioned above: launch menu_update_7003() once after creating at least one custom menu. I'll fix it on the next weekend. Patches are welcome, as always.

Priority:Normal» Major
Status:Active» Fixed

Fix committed. I'm going to release the next stable version (7.x-2.2) tomorrow.

Awesome! Great module maintainership right here!

Thanks!

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.