No active-trail in main menu LI class

My problem is just the other way round... I use custom build menus for both primary and secondary, and the theme DOES assign an active trail (since it's NOT the main menu, as you mention). But having .active-trail assigned stops the top-bar working you navigate from a sub page – the respetive 1st level can not be opened anymore, the triangle does not appear anymore.

e.g.
Section 1
- Section 1 Sub 1
- Section 1 Sub 2
- Section 1 Sub 3 (current page – the section 1 first level button is not active anymore, the section 2 first level works)
Section 2
- Section 2 Sub 1
- Section 2 Sub 2

@museumboy: as far as I see: yes. And in case it does (non-main menu), the menu entry is not clickable anymore.

Got a solution where I use menu_get_active_trail() inside the _zurb_foundation_render_link() function to plunk the active trail in there.

You can anonymously check out the code, I believe.

Hi museumboy,

What do you meant that you "have no access to patch the main theme"? You don't need any special access unless you're on a system running on multisite or something and you only have access to the subtheme.

Do you know how to apply a patch to your Drupal project?
- https://drupal.org/node/620014
- https://drupal.org/patch/apply

If you have to do this in your subtheme, you have to be aware that the patch affects helper functions that are called by hook functions.

I think you'll need to copy all the following functions from the base theme template.php into your subtheme template.php.

• _zurb_foundation_links()
• _zurb_foundation_render_link()
• zurb_foundation_links__system_main_menu()
• zurb_foundation_links__system_secondary_menu()

Then you'll have to manually apply the patch code, because it won't automatically apply since you're applying to a different file then it's intended for.

Then you'll need to rename theme replacing "zurb_foundation" with the name of your subtheme. Finally, you'll have to look for any places where the helper functions (starting with underscore) are called and then update the names there as well.

Then clear the cache and try again. I think that will do it, though of course I haven't tested it at all.

I tested raychaser's patch and it works fine. It has some differences from the markup you get with the core Bartik theme, but some of that markup makes no sense to me. I have a different patch that takes a different approach based on the way the core Toolbar module does it. It is a fair bit longer, but it has what I think is a bit closer to Bartik with the correction that it doesn't give an 'active-trail' class to an item that is actually active.

I'm not particularly attached to any given approach, either in terms of code or output. Here's me table with differences from Bartik bolded in each case. I originally was adding 'active-trail' in more places, similar to Bartik and changed my mind and that explains why the function _zurb_foundation_in_active_trail() creates a $classes array and uses return statements to stop at certain points. It's perhaps unecessarily complex for what it does now, but it's flexible.

I'm sure there are better ways to do this, but FWIW a patch is attached.

I seem to be physically incapable of getting a patch right the first time. I forgot to check out a new branch after my last patch. So #11 is all messed up.

#12 patch is working perfect. Thanks!

I think I can get rid of the array_unique() call - I had that in there from before doing the chart comparing Bartik to other options and I mistakenly thought that Bartik had "active active-trail" in the "active child with parent" condition, so I was ending up with two "active" class mentions in some cases.

In the worst case, removing the array_unique() results in the doubling of the active class, but I don't think with the current version that would happen. If it does, it's just minor bloat as opposed to a PHP Notice.

I'll reroll the patch as soon as I can (but probably not today).

Can you elaborate? Are you referring to a menu item that points to a piece of content that has an alias, or to the menu that displays if the current piece of content you're looking at has an alias?

Also, what does it mean to not work? What behavior are you seeing (no classes added, wrong classes added, etc?)

Thanks museumboy - that's plenty of detail for me to try to replicate and fix. I think I'll have some time this week, so hopefully I'll be able to figure this out and fix my patch.

PS - the patch needs to be fixed one way or the other,but I wonder if your situation wouldn't be helped for the time being by https://drupal.org/project/menu_trail_by_path

It sounds like your site has the right kind of structure to use it. I'm not sure what would happen, because that results in a lot of irons in the fire messing with those menu items, but it might be worth a try as a stopgap.

Thanks for that - I can look at Superfish and Menu Block and see how they handle it. Should have thought of that earlier anyway.

Thanks @ergophobe

Sorry for letting this drop. I just got back from 7 days with no internet and hope to put together a proper patch for this once I get dug out of the backlog.

museumboy, I am unable to reproduce your issue. Here's what I did

- set a pathauto pattern as "content/testing/[node:title]"
- create a top-level menu item "Testing"
- create a node with a menu entry as "Tokenized Path" nested under "Testing"

When I visit the new node, it has the "active-trail" class on "Testing" (both A and LI) and the "active" class on the "Tokenized Path"

Do you have a sandbox install to play with? On a bare install with just Drupal, Foundation, Token and Pathauto running, can you set up a simple test case and see if you still have the issue? There might be something else stepping in there.

And for reference, there are a lot of issues related to active-trail, usually when using a custom menu. Are you using a menu that you created yourself or Main?

Some references (mostly notes to myself for future reference):

• #942782: Custom menus never receive an active trail (341 comments and the longest issue summary I've ever seen) - despite being marked as fixed, many users still report issues with custom menus, especially with multi-lingual sites. A fix was committed in and rolled int0 Drupal 7.12, but some problems still crop up.
• As a result of issues that persist after the above fix a new and as yet unresolved issue has been opened: #1710744: Custom menus never receive an active trail (but system menu does)
• This has been reported to create issues for Menu Block
  • #1017142: except for one menu, all other menus (including books) never receive an active trail - original issue with workaround pending fix in core.
  • #1017122: Core bug work-around: add active trail to custom menus - dupe of previous
  • #1425342: Drupal core upgrade from 7.10 to 7.12 causes menu block to fail - definitive fix for Menu Block after fix committed to core

Adding a new patch, but all it does is get rid of the array_unique() call.

I looked at how things are done in Menu Block and Superfish, but this ends up being a fairly different situation so I fell back to the way the core Toolbar module does it.

This fixes it for me and ishworthapaliya.

museumboy - if you could test on a clean install, that would help because it works in every test I can think of on a clean install.

So I would probably commit this which should fix it for most people and then have museumboy open a new issue for his specific situation.

And just noticed this is marked as major. Changing to normal. See https://drupal.org/node/45111

ergo, you're last patch has changes to a .gitignore in it - not sure if that is intended to be in there or not.

I have no idea why the previous comment says I deleted a file - I didn't.

The patch(es) are hard to navigate in the context of Foundation template.php. The dev version already has the line with $rendered_link being set - where/what are we actually changing? Can we generate a clean patch?

Ah, sorry. I missed that this was with views and panels pages that you're having the issue.

Sorry about getting the .gitignore in there too. I ended up doing that because every time I work with it, if the starter theme is involved, you have to change STARTER.info.txt to STARTER.info for testing... separate concern.

As for the rest

$rendered_link is actually set three times in the current version and three times in my patch. The only difference is that on the third occurrence it is set later.

The problem with the $rendered_link in the current version is that it is set before figuring out whether or not the current menu item is in the active trail and before merging #attributes into the #localized_options array.

In other words this call
$rendered_link = theme('zurb_foundation_menu_link', array('link' => $link));

was coming before the $link variable had the needed classes added, so it needed to come later in the flow, after checking the active trail and after merging with $link['#localized_options']

So basically what's changing (in order) is
- postpone the theme() call that sets $rendered_link
- find out if we need to add a "active" or "active-trail" class and store it in an array
- if there are other classes in the localized options, merge the localized options array with our new values
- new set the $rendered_link with a call to theme().

I hope that clarifies.

Let me see if I can figure out why Views cause a problem.

OK, I still can't replicate that, but I did change the way I get the active trail items that I hope will be a bit more robust.

Thanks for all your help testing patches. I hope you have the patience for at least one more go 'round. To simplify it a bit for you for testing, I also attached template.php.txt so you can just download it instead of applying a patch in case you're not testing with the latest version from git.

Also kevinquillen, I added a lot of comments. The patch doesn't change very much except as noted above, but hopefully the added documentation makes that more clear rather than less (because of course it increases the size of the patch - I think there's now about 2x comments to code!).

Do you have a live URL I can look at?

I have broadened my tests and I still cannot get it to fail. Works 100% for me.

Do you work on an IDE that allows you to set breakpoints? If you set a breakpoint on line 257 of template.php in my current version:

$output .= '<li' . drupal_attributes($link['#attributes']) . '>' . $rendered_link;

Is the active-trail class present in the $link variable?

If you don't have an IDE that lets you look at things like that, you could use the devel module and do the following just before line 257

dpm($link['#attributes']['class'], $link['#title']);

Do the right ones have an array element for 'active-trail'?

I may be misunderstanding, but it looks like the target page in question ("new-article") doesn't have a menu entry, so it won't have an active trail generally speaking unless you do something based on path. Does "Articles" have a dropdown submenu that includes a link to the page in the /articles/new-article page?

If not, then you wouldn't normally have an active-trail class in D7.

It's not been a bad process, but one particular issue had been vexing us: how to set the active trail for nodes
and pages that don't have menu items.

src: http://designhammer.com/blog/active-trails-menu-items-drupal-7

AFAIK, you would have to do something based on path/breadcrumb. Probably easiest would be Menu Trail by Path, which lets Drupal search the URL parts to see if they correspond with a path for a displayed menu item

https://drupal.org/project/menu_trail_by_path

Menu Trail By Path sets the active-trail on menu items according to the current url.

You can also take the Menu Position approach

This module allows for the creation of rules that will dynamically add the current page into the menu system at the requested spots.

I could change my patch to recurse through the path and set as active based on path, but I don't think that belongs in a theme distribution since it depends on people having a hierarchical URL structure that matches the menu structure, which is not necessarily the case and who knows what URL structure people might end up with using Pathauto and how those relate to menu structure. It could create a lot of headaches for people. So if I understand your use case (and I'm not sure I do from the screenshot, since I can see if the menu has hidden subitems that I'm not seeing), I think it would be bad to make the Zurb Foundation theme handle that out of the box.

Please do the following tests

• Check Bartik and Garland. Do they BOTH have the menu behavior you expect?
• Install Menu Trail by Path and test again in Bartik, Garland and Zurb Foundation. How about now?

Just to give you an example, imagine a site where you have content types posts, galleries, and events and you have pathauto set to create paths like
post/first-post
event/test-event
gallery/vacation-pics

But the navigation has
Home
Ergophobe's Blog
Museum Boy's Blog

If you think of a structure like that, I think you can see why you can't force the behavior where an article automatically makes the Articles menu item part of the active trail.

I just did some additional tests.

In my tests, my patch works substantially the same as the Bartik and Garland themes with the differences noted in #11 .

None of the core themes have an "active" or "active-trail" class on menu items unless the current path is also present in a menu item. If the path of the current page is represented by a menu item, then the parents of that item will be in the active trail

Supposedly both menu_position and menu_trail_by_path will set the active-trail class on menu items if the menu item path is part of the path for the current page, but neither one worked for me. However, if *both* are installed, they do work and apply the active and active-trail classes in the type of situation described by museumboy. I didn't look further into it b/c why those modules both need to be enabled is not relevant here since the behavior is the same in Bartik, Garland and ZF.

So in short, to the best of my ability to test it
- Zurb Foundation with this patch works substantially the same as Garland and Bartik, and so I would consider that "fixed"
- Menu Position + Menu Trail by Path should address museumboy's needs. You would just create a Menu Position Rule for articles/* for example and it should work like you're thinking.

At this point, this has been tested by me (extensively!) and reported to work by ishworthapaliya in #13.

So once museumboy confirms that I've understood his situation correctly, I would move this to RBTC.

Sorry, moving to needs review.

Can you post code and show the observed behavior and the expected behavior? I don't understand the verbal description.

OK, now I understand.

That's a separate issue entirely and not really a Zurb Foundation issue at all. Menu Position is injecting that menu item. ZF is rendering the menu exactly as it should given that menu structure, and my patch correctly adds the active and active-trail classes given that structure. So the issue is really how to generate the structure you want.

You might be able to get help as a Menu Position support issue or handle it yourself in your own subtheme as a sort of custom thing specific to your site.

It would be possible to handle as a Foundation feature request too, but it's something that people should default to off since most people probably do not expect that behavior.

So the initial issue reported is fixed and I'm marking this as RTBC and suggest that for the specific issue of not actually having the dropdown, you either do some custom overrides in your subtheme or see if that behavior is available in Menu Position.

I created a feature request for you, though realistically it's probably not going to happen until someone has a need or some spare time.

#2207095: Set active-trail class if menu item path included in current page path

[edit]Truly, though, this should be handled Menu Trail by Path - see my comments in the linked Feature Request issue[/edit]

Accidentally replaced array_merge_recursive() with array_merge() which meant that the 'class' array element could get blown away.

So this is the same patch, except for using array_merge_recursive when merging $link['#attributes'] and $link['#localized_options']['attributes']

Great. With my last bug fix and your confirmation, I'm moving this back to RTBC

I've been using this patch for quite a while on a couple of sites. I found that in some circumstances the 'link_path' element of the $active_trail array item is not set, so it needs a simple check for !empty($item['link_path'])

Patched against a git pull from today on the 7.x-4.x branch.

Any reason this has not been committed?

I'll take a look at this and get it into the 4.x branch. Do you know if this affects the 5.x branch?

@ergophobe I've applied #55 to the dev branch. Thanks for the contribution. If you have a chance it would be awesome if you could take a look at the 5.x branch for the same issue.

I queued it up in my task manager so it will keep nagging me every few days. Ditto with the other issue you flagged.

I'm opening this issue back up. I ran into this same issue on the 7.x-5.0-rc5 release branch. The patch from #55 appears to be working without issue.

I would like to have others confirm that the patch works for them on the Foundation 5 theme before committing. Any feedback would be greatly appreciated.

      if(isset($link['#localized_options']['attributes']['class'])) {
        $link['#localized_options']['attributes']['class'][] = 'active-trail';
      }
      else {
        $link['#localized_options']['attributes']['class'][] = 'active-trail';
      }

What is the point of this?
Do you mean
$link['#localized_options']['attributes']['class'][] = 'active-trail';
or

if (empty($link['localized_options']['attributes']['class'])) {                                                            
         $link['#localized_options']['attributes']['class'] = array('active-trail');                                              
       }
       else {
         $link['#localized_options']['attributes']['class'][] = 'active-trail';                                                   
       }

?

I am not able to patch the file on 7.x-5.0-rc6. I am getting following errors:
Patching file template.php
Hunk #1 FAILED at 223.
Hunk #2 succeeded at 303 (offset 48 lines).
1 out of 2 hunks FAILED -- saving rejects to file template.php.rej
Could you help me out with this?

Thanks