Inaccessible menu items in navigation links cause "Notice: Undefined index: localized_options"

this is the offending part, in my case:

// Create a single level of links.
$router_item = menu_get_item();
$links = array();
foreach ($tree as $item) {
if (!$item['link']['hidden']) {
$class = '';
$l = $item['link']['localized_options'];
$l['href'] = $item['link']['href'];
$l['title'] = $item['link']['title'];
if ($item['link']['in_active_trail']) {
$class = ' active-trail';
$l['attributes']['class'][] = 'active-trail';
}
// Normally, l() compares the href of every link with $_GET['q'] and sets
// the active class accordingly. But local tasks do not appear in menu
// trees, so if the current path is a local task, and this link is its
// tab root, then we have to set the class manually.
if ($item['link']['href'] == $router_item['tab_root_href'] && $item['link']['href'] != $_GET['q']) {
$l['attributes']['class'][] = 'active';
}
// Keyed with the unique mlid to generate classes in theme_links().
$links['menu-' . $item['link']['mlid'] . $class] = $l;
}
}
return $links;

the error is come from "Add content" but why only inner page have error..

(just found that even menu hided, it will also loaded)

Subscribe

I also experience this problem when I change my Menus -> Settings -> Source for the Secondary links from "User menu" to "Navigation".

I changed it back again to "User menu" and the error is now gone.

Subscribe.

When I correct as jhayzhon explain, the error disappear.

Subscribe.

#5: menu.patch queued for re-testing.

Did a "handwise patch" by changing the lines as mentioned in the patchcode manually in the file menu.inc:
$l = $item['link']['localized_options'];
was replaced by
$l = !empty($item['link']['localized_options']) ? $item['link']['localized_options'] : array();
Uploaded the "new" menu.inc to the server: problem solved! So I don't know if the patchfile works but the solution is OK.

subscribe

#5: menu.patch queued for re-testing.

I have exactly the same error (see attachment). In addition, there is now an extra "empty" menu item.

The problem began when I changed the title of the main page.

You can try at http://lesjoyeuxcolibris.be/

I have cleared all the caches; the problem still exists.

Thanks for the fix cappersg, it worked for me.

jhayzhon's post of January 21 solved it for me, too. Thanks.

Cappersg's patch fixed the problem for me too. Thanks for that. I'd about gone out of my tree thinking I'd missed a setting somewhere.

cappersg's fix worked for me as well, thanks.

#13, #17, #19, #20 fixes are from my patch at #5 and all said worked, so i change to RTBC.

subscribing... horridly annoying having to patch a fresh Drupal 7 core for a simple use case.

+1

I can confirm that the partch from post 5 fix the problem. Thanks!

#5: menu.patch queued for re-testing.

Yup, the patch in post #5 fixes it. Thanks!

In summary (in case anybody here who doesn't know how to read these patches):
1) Edit file includes/menu.inc
2)
Replace line 1780, which should be currently:
$l = $item['link']['localized_options'];
with:
$l = !empty($item['link']['localized_options']) ? $item['link']['localized_options'] : array();

chx (the menu system maintainer) wants to take a look at this.

I wonder whether we are hiding a problem instead of fixing it. _menu_item_localize sets localized_options and both _menu_translate and _menu_link_translate both call this function. So how do we end up with non-localized items?

i took a good, long look at the history of this and it did not reveal anything. Is $element['#localized_options'] = !empty($data['link']['localized_options']) ? $data['link']['localized_options'] : array(); necessary, even? Also, I wonder how none of thought to add the obvious: we need tests. That will show where this fails.

Same with a fresh 7.2 install. Plus, if secondary menu set to main menu, it shows nothing (no main menu at the place of the secondary menu).
I have everything on localhost, so feel free to ask me to do any testing (if any needed).
Specs: Drupal7.2, Windows 7 x64 SP1, IIS7.5, PHP5.3.6

Leave this at 8.x, fix will be backported. Bugs always needs to be fixed in the newest version. Trust me this will get fixed sooner if you leave at 8.x.

problem is that _menu_link_translate will "Skip links containing untranslated arguments." but _menu_tree_check_access will leave it in the tree for items in the active trail even if there is a % in there. Something like the attached patch fixes that but it might require even further research... like, why does _menu_tree_check_access leave those item there?

#907690-55: Breadcrumbs don't work for dynamic paths & local tasks #2 added this line.

As @chx already mentioned, let's start with tests first.

Yuck. I've forgotten the details about what caused us to keep certain untranslated links in the tree, and I apparently #failed to properly document the underlying reasoning in code. All I remember is that it is required to make certain links to correctly appear in the breadcrumb. I hope that this is at least mentioned/documented somewhere in the issue summary or comments on it.
The block of code right above the "Skip links containing untranslated arguments" is related to that though, and likewise a block of code in menu_set_active_trail(), which is the only location that passes the $translate = TRUE argument to _menu_link_translate().
Well, separate issue: #1189310: Document why some links in a menu tree are kept untranslated for building breadcrumbs

I tried patch #33 as patch #5 only fixed one of two notices that I got in account settings (Drupal 7.8) . Both original notices were fixed by #33, but now I have "Notice: Undefined index: in_active_trail in _menu_link_translate() (line 915 of /home/quickstart/websites/gdutch.dev/includes/menu.inc)." on the Reports page (admin overlay). The line refers to this code:

    if ($item['access'] || $item['in_active_trail']) {
      _menu_item_localize($item, $map, TRUE);
    }

After setting up a view for taxonomy items got the error..

Notice: Undefined index: localized_options in menu_navigation_links() (line 1782 of F:\xampp\htdocs\ic4ever\includes\menu.inc).

for every taxonomy page. eg. /taxonomy/term/4 . I hard coded the fix as did #13 based on the #5 patch.
Thanks to all posters. So far so good, seems an instant fix in this case.

Got to get this issue fixed in next drupal release.

I'm at the Boston Initiative. We're testing and rerolling patches. This patch still applies cleanly as of commit ec0f197e3c (last release 7.9). Just FYI.

#5: menu.patch queued for re-testing.

Leave this at 8.x it will be backported...

#33: 1018614_33.patch queued for re-testing.

Argh I shouldn't retest this, will fail anyway

For me the error merged when i display the image of the gallery as a full page

the patch worked
thanks

I had this error a while ago, but I can't remember how to reproduce. I'd write the tests, when someone can provide steps to reproduce this from a fresh installation.

Error back suddenly (Edit: Oh ... it depends just on the page you're on). That gave me a chance to manually test (and reroll) the patch. See attached.

I'll go for the test case now.

As chx predicted there is more work and research to be done on the fix. It seams to break a lot of things.

Meanwhile here's a test. Setting to needs review to see it fail. Questions here:

1. I am not sure about the names of the testing method.
2. I am not sure if this is the right class to add the method to.
3. Not that we need a single assertion to see the notice - but we should have an assertion. Does the assertion make sense? Other things that should be checked?

Yay! Test failed for the right reason.

#5: menu.patch queued for re-testing.

subscribe

@wermfud: You don't have to post "subscribe" notices anymore, you can just click the lovely green Follow button at the top-right of the page :)

I had the notice when editing taxonomy terms and after applying the patch I have this one on the admin/structure/taxonomy/modeles page :
Notice : Trying to get property of non-object dans taxonomy_admin_vocabulary_title_callback() (ligne 381 dans /var/www/[…]/modules/taxonomy/taxonomy.module).

And this one x2 when editing a term : Notice : Trying to get property of non-object dans taxonomy_term_title() (ligne 1550 dans /var/www/[…]/modules/taxonomy/taxonomy.module).

@ ethnovode same problem w/taxonomy pages as you. I have applied the fix by poster #13 a few times now for different installs and it works 100%.
Let me know ..

Thanks romanse, I reverted the patch and used solution provided in #13 with success.

Also I couldn't edit views anymore with the patch : PHP Fatal error: Call to a member function get_human_name() on a non-object in /var/www/[…]/sites/all/modules/views/views_ui.module on line 259, referer: […]/admin/structure/views

I hope this get fixed and if I can help to find the real cause of this please let me know. I don't understand a thing here :)

Confirming the bug exists in 7.14
Just to confuse things, I am not using translation at all. Although I guess the translation functions are still being called.

#33 is working for me on this case.

EDIT : some messages are gone… but new ones are there now, so patch #33 is not working at 100%
New messages:

Notice : Trying to get property of non-object in node_page_title() (line 2109 in /www/modules/node/node.module).
Notice : Undefined index: in_active_trail in _menu_link_translate() (line 926 in /www/includes/menu.inc).

I've go the same issue in the current version of D7

subscribe

Notice: Trying to get property of non-object in taxonomy_admin_vocabulary_title_callback() (regel 381 /public_html/modules/taxonomy/taxonomy.module).

subscribe

Problem still exists in 7.15. I resolved it a slightly different way after poking around and went with using a reference as opposed to #5's solution.

Replaced:
$l = $item['link']['localized_options'];
With:
$l = &$item['link']['localized_options'];

I'm thinking this might be a better solution since it appears the $item['link']['localized_options'] array actually exists, it just doesn't know the appropriate scope. I haven't thoroughly investigated whether or not this breaks somewhere down the line but figure since this issue has been open so long an alternative interpretation might be useful in moving a patch into a production release.

The #65 solution seems to work very well to me.
I'm using Drupal v. 7.14

#65 worked for me as well. I've been trying various "solutions" for two weeks now and this is the first one that worked for me. At Drupal 7.15.
Will be on the watch for other issues that might crop up.

#65 fixed it for me too. Using Drupal 7.15.

Drupal 7.15 fixed with solution from #65

#65 does the same as #5, it simply prevents the error from displaying.

A quick look seems to indicate that the localized_options are not there because for performance reasons inaccessible items are not localized.
But it appears they are added to the menu_navigation_links which incorrectly assumes all items have been localized.

Attached patch is an attempt to fix that.

For the D7.15 people wanting to hack core:
includes/menu.inc line 1855:
if (!$item['link']['hidden']) {
change to
if ($item['link']['access'] && !$item['link']['hidden']) {

Issue is still persistant in the latest 7.16 release. I like #71's solution as opposed to what I suggested prior. I'm hoping that flagging this back to v7 might get someone looking at it and including it in future updates. I hate hacking Drupal core!

Can confirm that problem still exists in 7.16 and also that #71 appears to work well :)

Also confirming it's still there and patch in #71 solves the issue!

@jlancaster: We'll need to fix it for 8.x first and then backport to Drupal 7.

This has a lot of confirmations already. Thanks, JvE, for the patch! I think all we need is some tests. I had a simple one ready in http://drupal.org/node/1018614#comment-5481040 but by now (instead of trying to get that applying) we should probably just go and write a better one from scratch.

The solution proposed in comment #7 worked for me in Drupal 7.

@axle_foley00 that is not a solution.

Clarify issue in title. I've also updated the summary.

Restoring Needs tests tag.

This is no longer an issue in D8.

The current menu_secondary_menu() calls
menu_navigation_links('main', 0) which calls
menu_tree_page_data('main', 1) which calls
menu_build_tree('main', $parameters) which calls
menu_tree_check_access(&$tree, $node_links) which calls
_menu_tree_check_access(&$tree) which rebuilds the $tree without any links that do not match
if ($item['access'] || ($item['in_active_trail'] && strpos($item['href'], '%') !== FALSE)) {

Therefore the $tree used in menu_navigation_links should never have any items with $access == FALSE and thus without localized_items.
(unless an item you do not have access to ends up in_active_trail and has a % in it's href)

Sigh. Check twice, submit once :(

While this is a notice, it's not a sign of a more serious bug, so downgrading from major. Could still use tests here I think.

Sorry, completely wrong status...

I was having the same issues on mine version 7.18. The patch fixed all the errors.

Thanks, works perfectly.

Works for me, thank you!

#83: drupal-menu_navigation_links-1018614-83.patch queued for re-testing.

#83: drupal-menu_navigation_links-1018614-83.patch queued for re-testing.

work for me ..its ok

It seems that other things changed in D8 that caused the patch to no longer be necessary. However, as of 7.22 I can still recreate the error by changing the secondary menu from User to Navigation.

What is the status of this patch? Does it correctly address the issue? Is it going to be committed to D7?

Note: In my case I am using menu_token to place the user id in the path. When people visit the site as anonymous the token gets resolved to "not yet assigned". link['access'] = TRUE, link['hidden'] = 0 for these items and there are still no localized_options. So, even adding the code would not fix the situation for me.

Is this a bug in menu_token? Should it be setting access to FALSE or hidden to 1?

EDIT: I resolved this by adding logic to my custom access callback function (used in my mymodule_menu) to check whether the user is signed in ($user->uid). Thus, an anonymous visitor gets access = FALSE now. So, perhaps this was really a bug in my own code.

What happened to the tests? (For example, the ones written in #50.) They seem to have gotten lost somewhere along the way...

And at least the tests should go in Drupal 8 too, even if the bug doesn't exist there (especially because getting tests for this passing is the way to prove/guarantee that the bug no longer exists).

"needs backport to D7" tag didn't seem to stick...

Update summary.

Is there any way to get the simple patch in D7 already and then write tests for both versions as a follow-up in the same issue?

Thankyou for this. This fixed my problem too. :-)

Here's a D7 version of the patch from #83.

#83 is a D7 patch.
D8 does not have the issue due to changes in the way menus work.
David_Rothstein wants to have a test for D8 first and then a test for D7 before the D7 patch can go in.

Apologies @JvE. I misread the issue. Thanks for the clarification (and for your patch!)

Comment #7 (jhayzhon) fixed it for me too!

99 worked for me.

For anyone working on this issue in the future, see David_Rothstein's comments in #95.

Tests need to be added to D8 before the fix and tests can go into D7. #50 has tests for D8 already, but I don't know enough about the issue to say if they're sufficient. #50 will need to be rerolled.

Since it's pretty long since #50, let me summarize the changes I made in the reroll.

• The test now lives in core/modules/menu_ui/src/Tests/MenuTest.php. The method name is the same.
• Some of the class properties have changed ($this->big_user became $this->admin_user).
• The menu names have changed - main-menu is now just main and navigation is now tools.

These are the relevant changes. I have changed the function call to drupalPost to the new method (drupalPostForm).

I am hiding all other patches for now to avoid confusion. Please show the relevant patches once the test is proper and the fix needs to go to Drupal 7.

I tested this locally and there is a failure in the test. The test expects the "Add content" link to appear twice - once in secondary menu and once in tools block. But the block is not placed for the test and the text appears only once (from the secondary menu). I have to check this once on a fresh install of D7 to be sure of what was expected. For now, I am just attaching the patch for review.

I compared the block in D7 and D8 and they are in the same position, so the test is still valid. I have modified the test to place a block and it all passed for me on my local. Here it is.

For D7, #83 works great! Thanks.

A very small change. Git took care of rebase all by itself.

I do not understand, why we need to use a core patch?

I assume it is a misconfiguration of the website, isn't it? I get this notice only on one of the multilingual sites:

I copied a multidomain, multilingual website in a new webspace and deleted all domains (domain1, domain2 and domain3) and their content, except one domain (domain4). After that I am getting this noice.

I deleted this domain (domain4) on the original website and there is no notice about that when using (domain1, domain2 and domain3) .
.

If it is not a misconfiguration why is there an nearly 3year old unfixed issue? That's not drupal like

If it is not a misconfiguration why is there an nearly 3year old unfixed issue? That's not drupal like

It is a bug. But not a very big one. And Drupal issues that are not super urgent and critical usually take a long time.
Take the latest D7 bugfix release (7.33):
Issues from 2005 fixed: 1
Issues from 2008 fixed: 1
Issues from 2009 fixed: 5
Issues from 2010 fixed: 10
Issues from 2011 fixed: 14
Issues from 2012 fixed: 12
Issues from 2013 fixed: 14
Issues from 2014 fixed: 25

#83, thank you!

This is ridiculous.
7.39 and still not fixed.
Used #83 and worked fine for me.

Maybe, but doing service for dozens of sites its no way to patch and test the sites after each drupal core update ....

If anyone wants to see this go in, the list of what's left to do is in #106.

#83 works for me. :)

Needs a reroll of #83 against D7.53. I believe the errors I'm seeing are from this patch, or the lack of this patch doing what is necessary to fix the issue.

Nevermind the reroll, I think patch #83 did work properly when applied to D7.54. Thanks.

Fixed the coding standard of short array, applying the patch.

My logs are full and ONLY log this error message every few second. Why the heck is the on liner from #83 still not committed to in D7? I do not care about all the back and forth here. This is a serious issue to everyone and core maintainers need to put priority on fixing it. With test or without - I do NOT care. Bug is bug.

#50 + #83 combined. Unbelivable that core maintainers cannot combine and commit two very small patches within 7 years.

Reroled D8

Still needs tests... there's a starting point in #50. I'm not sure how the patch here corresponds to the issue in the summary, either. Was the wrong patch attached?

Also not a critical.

You are right. I attached the wrong D8 patch.

Can we please get this committed to D7 and D8? It looks to me like D7 already has a test written, so can someone fix the issues with the D8 patch hass posted since it failed testing?

It's the end of 2019 and I had to apply this fix #135 to Drupal 7.61 - problem solved now (can't imagine a life without Drupal 7, it's support and its many modules).

I've been using the (seven years old) D7 patch #83 for two and half year without problems.
#135 is the same patch with added tests.

So in my opion this could be commited to D7.

So in my opion this could be commited to D7.

Agreed. The Drupal community came together and made a solution, but the powers that be are unwilling to do anything, despite the drupal.org site itself still running on D7...

The days of Drupal 7 are pretty limited, so the odds of this being patched to Drupal 7 ....not so good.

The fact that a patch WITH TESTS exists makes your point irrelevant. The issue is essentially fixed, with a few people standing in the way of it actually being merged.

Does Drupal care more about its users, or its agenda?

Agreed. Using patch in #135 for some time. Drupal policy is shooting itself in the foot.

Tagging. Hope that will help to gain some attention before the next Drupal 7 release preparation.

As it stands now the last patch failed. So at a minimum a new patch needs rolled.

I just patched #135 against 7.x-dev successfully... there's literally no change needed. It's the D8 patch that failed.

@StevenPatz what patch and failure are you referring to? The last several comments have been about the D7 patch in #135 that applies without difficult to D7.73 and has tests and has been RTBC. Sure D8/D9 is a different story and that's what's holding it up. Policies before code.

Does the issue reproducable on Drupal 8/9? Followed steps to reproduce described in the patch and those looks like outdated.

The test coverage based on steps to reproduse from Drupal 7 issue for Drupal 8/9 make no sense as those steps not able to reproduce (At least for me). So, if I'm wrong and someone experienced issues in Drupal 8+ with the same symptoms, then the test for Drupal 8/9 need to be updated. In the other case this issue is the only Drupal 7 issue and patch #135 can resolve it with the test coverage.

Set proper status, as currently this issue need some additional feedback.

Set proper status.
The patch is at #135 comment.
Patch contains a test (based on steps to reproduce) and the one-line fix.

Added "backport policy" statement about why D8/9 doesn't need to be covered.

Removing the "Pending Drupal 7 commit" tag for now per my comment #1007746-215: Reordering fails with more than 100 items in a menu which I won't repeat in full here.

Same patch as #135 plus a test_only (which I suppose is a reroll of #50).

Ok, I think this LGTM (on the basis of the note on the backport policy in the IS).

RTBC + 1

+1 RTBC (because it's the same as 135, which I tested a while ago.)

Thanks everybody!