Menu item linked to <front> doesn't know its active

I reopen this issue, because the problem partly still persists.

The 'active-trail' class is not added to menu items that link to '<front>' while the front page is displayed.

When sub items of it are displayed, the 'active-trail' class is added (to the parent that links to '<front>').

Regular menu items always have the 'active-trail' class added when they are active.

In other words, considering the following menu structure:

• home (<front>)
• sub-page1 (node/x)
• sub-page2 (node/y)
• page1 (node/z)

Not ok: When 'home' is active, 'home' will not have the 'active-trail' class added.

Ok: When 'sub-page1' or 'sub-page2' are active, 'home' (as well as the active sub-page) will have the 'active-trail' class added.

Ok: When 'page1' is active, 'page1' will have the 'active-trail' class added.

It is because the mlid of the <front>-item (>0) will never match the trail of the front page (just 0).

I created a (very small) patch that fixes the problem. I'm not sure if it the most appropriate way, but to me it seems reasonable and it doesn't modify/affect the trail itself.

I wouldn't have thought that 'link_path' might not be set. Here is an updated patch that includes a check for that.

This has more consequences ("1." being the matter in comment #2):

2.)
The parameters that identify a menu tree cache entry (that make the cache id) for a menu containing a link to <front> is the same for the following cases:

• <front> is displayed
• Any page that has no item in the menu is displayed.

As a result the cache entry will have a different content (regarding 'active-trail' for the <front> menu item) depending on at which page it is being generated at first. And thus it will be (incorrectly) the same for both cases above.

I fixed it by adding an 'is_front_page' parameter to the parameters that make the cache id. This happens only when the front is actally displayed.

3.)
I erred when I thought the trail itself would not be affeced. The <front> menu item will be added to the trail and thus appears in the breadcrumbs for example. Which is undesired (duplicate 'Home' entries).

I fixed it by ignoring the <front> menu item while generating the trail.

4.)
There is another thing I noticed. The menu item that links to <front> will not be expanded when it has sub items and <front> is displayed. Regular items will do this. When the sub items are displayed the (parent) <front> item will be expanded however.

I spend a while tracking this down. I found that menu_link_get_preferred() will not find the correct menu item when <front> is displayed. I tried to find a solution but gave up for now, because for me there is currently no urgency for that. I might get back to this later. Is there any interest for this being fixed? Or any idea for a solution?

--
So this patch does the following:

1.) Properly add 'active-trail' class to menu items that link to <front>.

2.) Make the menu tree cache consider menu items that link to <front>.

3.) Exclude the menu item that links to <front> from the trail (e.g. breadcrumbs).

I figured that this issue is really not that serious. I had problems css styling when using the 'active-trail' class only. The <front> menu item would never be styled right. But by combining the 'active' and 'active-trail' classes in css selections anything can be done.

Is is still unlogical or inconsistent behaviour in a way. But I don't know if there is need to fix this.

Anyone with a fix for this front page active trail issue?

Raising to normal.

My theme requires CSS for the active leaf. It would be great any leafs with <front> page should be marked as active.

As a workaround I changed the menu item to link to the node directly, rather than the front page.
But now I have the root path and node path linking the the same thing.

Thanks!

@mmilo: Here it does add the 'active' class to menu leafs with '<front>' when they're being displayed. It only does not add the 'active-trail' class.

I'm not sure if I entirely understand your situation and requirements though.

@jox Concerning the issue of parent menu with the link of will not expand by default when on the front page.

While it is true that dealing with the css element of the problem is negligible, I think the behavior for "Show as expanded" for a menu link to is important.
See #6 part 4.)

How far away is that patch from being usable? I just want a home page link with a couple of children expanded on the front page. I'm not even sure how to work around it short of having an independent group of html for the main page. I'd rather it work with the menu system. I appreciate your work. Thanks.

This is a regression from Drupal 6 and it is not a trivial problem. I hope that it will get some attention.

I have just upgraded from Drupal 6.26, where the menu system was working perfectly. Now the numerous child menu items associated with the home page are never displayed unless I force the Home menu to be permanently expanded -- thus breaking the expanding menu system. I have applied patch #5 but with no success.

See also possible related issue or duplicate: #1578832: [already commited but followup for CR?] <front> menu links are missing active trail classes

#5: menu_system-1063278-5.patch queued for re-testing.

See #1578832: [already commited but followup for CR?] <front> menu links are missing active trail classes