Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
When the "access" component of the $router_item array does not exist, php 5.4 spits out a notice to that effect. This code fixes that by not trying to access (no pun intended) the index if it doesn`t exist.
Comment | File | Size | Author |
---|---|---|---|
#5 | drupal-undefined-index-access-in-menu-inc-1847382-5.patch | 550 bytes | pingwin4eg |
#2 | 1847382.diff | 487 bytes | thehong |
menu.inc_.patch | 438 bytes | MisterSpeed | |
Comments
Comment #2
thehong CreditAttribution: thehong commentedComment #3
pingwin4egFirst, you're doing wrong check in patches: 'access' is key of an array not a value.
Second, $router_item['access'] already should exist by that moment (at least in D7.17), it comes from _menu_check_access().
Need more info. What version of Drupal you are using?
Comment #4
MisterSpeed CreditAttribution: MisterSpeed commentedAccess may be created in _menu_access_check but not necessarily. For example line 635 will fail if for some reason the custom access function has a typo in it. This was not our case, so I am running an implementation to figure it out. In any case though as you can see in _menu_access_check, there is an execution path (and perhaps more) that can lead to the access key not being created at all, and the error message that results is not a useful piece of information to the user.
Comment #5
pingwin4egOh, you're right. I didn't notice that at first.
OK. But there's one more call to _menu_check_access() and check for item['access'] element in _menu_link_translate(). So I guess it would be better to explicitly set $item['access'] = FALSE in _menu_check_access before all checks.
Comment #6
MisterSpeed CreditAttribution: MisterSpeed commentedYup, that works
Comment #7
David_Rothstein CreditAttribution: David_Rothstein commentedLooks good... committed to 7.x - thanks! http://drupalcode.org/project/drupal.git/commit/82a360d
I verified that the bug does not exist in Drupal 8 (or, interestingly, Drupal 6 either). The function_exists() check which allowed this situation to occur appears to only be a Drupal 7 thing.