Warning: Invalid argument supplied for foreach() in menu_unserialize() if unserialize returns non-array value

bugs need to be fixed in 7.x first

Simple roll of the patch above.

I may have misunderstood this issue, but I don't think we need to handle incorrect data returned by module code. The hook system (which hook_menu() is a part of) works by a "contract" interface, ie. the implicit assumption that the data returned by the hook implementation will be valid. There's no way for menu_unserialize to unpack a non-array value as long as all hooks are implemented correctly.

Not necessarily arguing for the patch, but I think that the point is to make it easier to develop modules. I know that I have implemented hooks wrong and then couldn't figure out where the message was coming from. This would change current behaviour to fail more gracefully when a new (or experienced at 4am) dev writes a bad hook.

The downside of this is if this type of code is implemented all over drupal, it could increase the size and complexity of the code significantly. It also might be a performance hit, although I am not sure what the performance of an is_array call is.

A better way to do this IMHO would be to change the api to send an unserialized version of $data to the function and then use type hinting. This, of course, would only work in D7.

In fact, I think if we care about preventing this error, we should be checking when we do a menu rebuild (i.e. just once before the data is serialized) , NOT when the data is being unserialized. In general I'd agree with Arancaytar that we cannot babysit code to this extent. So this is pretty close to a 'won't fix'

Peter and I discussed this in IRC. Core has a policy of "not babysitting broken code," so I'm not too hot on committing patches like this. However, the fact that it spews errors everywhere points that the system is not being quite as fail-safe as it could be.

Peter suggested and I agree with moving the validation to when the rows are inserted into the database, rather than when they are read, since the former happens once in awhile and the latter happens on every page load. Let's take a look at what a patch like that might look like.

Wrote the following short test program to find problems in my database:

$dev = new mysqli('localhost', 'user', 'pass', 'database');
$res = $dev->query('
SELECT path, access_arguments, page_arguments, title_arguments FROM menu_router
');
while ($row = $res->fetch_assoc()) {
  foreach (array('access_arguments', 'page_arguments', 'title_arguments') as $field) {
    $path = $row['path'];
    $raw = $row[$field];
    $data = @unserialize($raw);
    if ($data && !is_array($data)) {
      $string = var_export($data, TRUE);
      print "$path $field unserialize('$raw') === $string\n";
    }
  }
}

Perhaps something similar could be written as a menu_requirements() function?

bumping version.

Marked #1914974: Invalid argument supplied for foreach() in menu_unserialize() (line 400 of includes/menu.inc). as a duplicate, which has a different solution to the problem:

function menu_unserialize($data, $map) {
  if ($data = unserialize($data)) {
+    if ((!is_array($data)) && (!is_object($data))) {
+      return $data;
+    }
    foreach ($data as $k => $v) {
      if (is_int($v)) {
        $data[$k] = isset($map[$v]) ? $map[$v] : '';

Updated issue summary.
As discussed in #4-#8: the proposed patches may be helpful for individual programmers to locate an error, but non of them will be committed in core, since the solution must be found in another location.
Hence, setting this back tot 'Active'.

Updated issue summary.

Is the patch in #3 doesn't end up logging a proper response and $data_s isn't defined.

i didn't follow the post but i got the same error and turns out it was just that i gave 'access arguments' a string instead of an array in my hook_menu function...

   'access arguments' => 'my permision',  

to

   'access arguments' => array('my permision'),  

So at this point, I think this issue should probably be closed - I don't see how this is anything other than accommodating broken code.

I we do want to address it (and given the routing changes in D8) I would consider either that values expected to be arrays are cast that way before being serialized OR an exception should be thrown if a scalar is supplied when an array is expected.

The suggested changes here refer to menu_unserialize in menu.inc. That function was removed from Drupal 8 in #2107533: Remove {menu_router} in 2014. That makes this outdated for Drupal 8 but still relevant for Drupal 7.

Seven years ago, in #15 it is suggested that this is a won't fix. There has been no further comments so I am taking that suggestion and marking this as won't fix. If you disagree, reopen the issue, by setting the status to 'Active' and ideally a patch.

Thanks.