Active menu trail breaks (menu_update_7003 creates inconsistencies).

Moving this to i18n.

I tried changing schema and running update (again) but does not solve it for me - the same items still fail to show secondary menu block.

Thanks a lot for this post,

i was getting headache trying to figure out why the same site features wasn't working on my fresh install and my old but up to date site.

excellent! worked for me :)

Why has this been changed to i18n? This is about the core menu module...

@vegardjo - what worked for you? I don't see a patch.

Did you just manually force this:

/**
 * Add missing custom menus to active menus list.
 */
function menu_update_7003(&$sandbox) {
  // Make sure all custom menus are present in the active menus variable so that
  // their items may appear in the active trail.
  // @see menu_set_active_menu_names()
  $active_menus = variable_get('menu_default_active_menus', array_keys(menu_list_system_menus()));
  $update_variable = FALSE;
  foreach (menu_get_names() as $menu_name) {
    if (!in_array($menu_name, $active_menus) && (strpos($menu_name, 'menu-') === 0)) {
      $active_menus[] = $menu_name;
      $update_variable = TRUE;
    }
  }
  if ($update_variable) {
    variable_set('menu_default_active_menus', $active_menus);
  }
  // Clear the menu cache.
  cache_clear_all(NULL, 'cache_menu');
}

@catch - why isn't this a Core issue if menu_update_7003() is missed?

The bug only exists when i18n_menu is installed, see the OP.

menu_update_7003() is an update, so should not ever run on a new install.

The fact that running menu_update_7003() makes i18n_menu work, does not mean that this is a core bug - it might be a core bug, but in that case steps to reproduce that involve core only should be possible, or it may be there is a core bug that i18n_menu exposes, but we won't know that without more information.

Please see: #1351678: Follow menu_link_get_preferred active trail handling for custom menus
http://drupal.org/node/1351678#comment-5582922
Running the following versions and this problem seems resolved:

• Drupal 7.12
• Multilingual - Internationalization (i18n) 7.x-1.4
• Menu Block (menu_block) 7.x-2.3

Are you seeing [in_active_trail] elements in the array as I tried to describe here:
http://drupal.org/node/1425342#comment-5667366

I tried your suggestion and it didn't work for me.

I'm using the config you're suggesting and am clearing cache & doing update.php

@mgifford, yes - I changed the "schema_version" field of the menu module the database to "7002" and executed update.php

Ok, so you just did something like:

UPDATE `drupal`.`system` SET `schema_version` = '7002' WHERE CONVERT( `system`.`filename` USING utf8 ) = 'modules/menu/menu.module' LIMIT 1 ;

I update it:

$ drush updb -y
No database updates required [success]
Finished performing updates. [ok]

Should I see any other changes?

Thanks for this tip, it solved this issue for me when upgrading to D7.12 from D6.25.

Though @catch is right, this is pretty weird.

Could anyone post the content of the variable 'menu_default_active_menus' before and after the update?

I mean when installing a new site using latest Core. As mentioned in #7, running the update on a new clean site fixes the issue.

Since the update creates the variable, shouldn't a clean Drupal install create it?

I'm not sure when/where the 'menu_default_active_menus' variable should be added, but currently it does not get created with a standard Drupal 7.12 installation.

In case this is helpful here's a test case I tried:

1) Standard Drupal 7.12 install.
2) Created a custom menu.
3) Created 2 pages, added them to the custom menu in a parent-child relationship. Placed the menu block in a sidebar. At this stage the 'menu_default_active_menus' variable doesn't exist, but the menu displays as expected.
4) Installed menu translation (using the latest i18n and variable dev versions) -> the variable still doesn't exist, but the menu is now broken.
5) Executed code in menu_update_7003() function -> the variable gets created and the menu now displays as expected again.

Some notes, looking at Drupal core code:

1. When coming from a clean install, the variable is not set, but it defaults to array('navigation', 'management', 'user-menu', 'main-menu'), coming from: array_keys(menu_list_system_menus());

2. Then every time a new menu is saved through menu_save(), it gets added to the variable. The menu name doesn't matter.

3. When running the update hook, the value is set to the previous array + any other custom menu that has been created (only if such custom menus exist, we check for 'menu-' in the menu name).

So I think the values may be different when creating menus with other modules whose name doesn't start with 'menu-'. Maybe features? Maybe others?

@Jose: yes I can confirm. I have a menu block using the book module (which has a weird half menu / half not way of doing things) and I'm seeing exactly the same issue (using Drupal 7.12, i18n 7.x-1.5, menu_block 7.x-2.3)
Any ideas what to do?

Just to prove your point I have added this piece of code:

function custom_mymodule_init() {
  // hack
  $menus = variable_get('menu_default_active_menus');
  if (!in_array('book-toc-5139', $menus)) {
    $menus[] = 'book-toc-5139';
    variable_set('menu_default_active_menus', $menus);
  }
}

and the problem is solved.

As explained in #18, the value of the variable is different with and without running the update.

1. If running the update, it 'forgets' all menus that don't start with 'menu-'.
2. If installed the version from scratch, it adds all the menus to the variable as they are being created.

So back to Drupal core. That update should be cleaned up (I don't know which of the two behaviors is the right one).

Update