Menu tree with tokenised item expanded on <front> page

I could not reproduce this in Drupal 7. It looks like menu never gets expended at all even for links of pages.

I had the same issue in D7, here are the steps to reproduce

Select the source for the Secondary links. An advanced option allows you to use the same source for both Main links (currently Main menu) and Secondary links: if your source menu has two levels of hierarchy, the top level menu links will appear in the Main links, and the children of the active link will appear in the Secondary links.

So set the
- "Source for the Main links" to main menu under /admin/structure/menu/settings
- "Source for the Secondary links" to main menu under /admin/structure/menu/settings

How to reproduce.

navigate to admin/structure/menu/settings set both primary and secondary menus to the same menu then in that menu.
- create a level 1 menu item at user/[current-user:uid]
- create a level 2 menu item childe of user/[current-user:uid] to any other page (this must be the child of the item above)

navigate to user/x and your secondary level menu items are missing.

I have a customer experiencing this issue in Drupal 6. The active menu item using a menu token is receiving the "active" class on the anchor tag, but is not receiving the "active-trail" class on the list item tag.

This is causing problems with styling in the theme where styles need to be applied to the active list item or to all menu items in the active trail.

The previously submitted patch would not be an acceptable solution, because it does not allow for expanding of the menu tree and further interferes with the expected behavior of menus.

Illustration of the issue: https://skitch.com/sheenad/gyxdc/community-guidelines-realtime-reactor

Hello at BlueSpark we had a project where installed menu_tokens and experimented the problem of no active-trail class for menu items. After some dive in menu.inc code this problem is easy to explain:

The function menu_link_get_preferred($active_path, $menu_name) at menu.inc is the responsible to detect for the current request URI which menu items will be marked as active trail this is done via a query:

    $query = db_select('menu_links', 'ml', array('fetch' => PDO::FETCH_ASSOC));
    $query->leftJoin('menu_router', 'm', 'm.path = ml.router_path');
    $query->fields('ml');
    // Weight must be taken from {menu_links}, not {menu_router}.
    $query->addField('ml', 'weight', 'link_weight');
    $query->fields('m');
    $query->condition('ml.link_path', $path_candidates, 'IN');

But the problem is that this never will return items using menu_tokens because the link_path = because we don't know the real URL so when the above query is executed doesn't retrieve any active item.

Fortunately there is a possible solution for this using a hook_preprocess_menu_link we could load the child elements for all the menu tree an iterate over the childs so doing the same verification that does the t() function to set the active class we can know if a child is active and if TRUE then set the parent as active-trail.

I attach the patch with the implementation but I only tested with a menu with 2 deep levels so is appreciated testing with deepest menus.

Update version to 7.x to match patch, and marked needs review.

Warning:
Primary/secondary menu linking feature is not working on D7 core, altough it is still advertised in help text:
#410646: "Secondary menu" exists but is no longer the default source for the secondary links
#950034: Using the same source for main/secondary with a custom menu doesn't work

Patch re-rolled and committed to 7.x-978948

Updated patch attached, feedback is welcome. Let's make it RTBC!

Not sure if you are considering this the same issue. But if you have one menu with tokens and then put another menu item underneath that item with tokens, there is no active-trail applied.

Hmm, I misread post #8. He said he "committed" this and so I assumed it was committed to DEV and its not. I had to manually apply this patch to DEV and it seems to fix my issue.

@iLLin: He sayed he commited it to 7.x-978948, this is not the dev branch! You need to checkout the issue-branch manually with git, if you want to use it. It's not commited to dev yet, it's on needs-work status.

For me the patch looks good, but does not solve my issue (not related to this one sadly), so I can not really estimate, if the patch fixes the issue.

@Hydra, can you test the patch against dev?

I tried using the steps to reproduce in the issue summary, and applied the patch in #8, but I think the steps to reproduce might be incorrect or something, because I'm not seeing a difference. If I have time, I'll come back to this one.

Ok, this patch and issue is pretty old, and the module has changed a lot, nobody reported this bug again or I'm unable to find it, so just closing it.