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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Status: Needs review » Needs work

The last submitted patch, menu.inc_.patch, failed testing.

thehong’s picture

Version: 7.17 » 7.x-dev
Status: Needs work » Needs review
FileSize
487 bytes
pingwin4eg’s picture

Status: Needs review » Active

First, 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?

MisterSpeed’s picture

Access 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.

pingwin4eg’s picture

Title: Spurious notification under php 5.4.x » Undefined index: access in includes/menu.inc (when custom access_callback does not exist or not get included)
Assigned: MisterSpeed » Unassigned
Status: Active » Needs review
FileSize
550 bytes

Oh, 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.

MisterSpeed’s picture

Status: Needs review » Reviewed & tested by the community

Yup, that works

David_Rothstein’s picture

Status: Reviewed & tested by the community » Fixed

Looks 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.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.