After updating to 7.x-2.5 yesterday, I've begun seeing a ton of these PHP errors on multiple sites:
Recoverable fatal error: Argument 3 passed to menu_tree_prune_tree() must be of the type array, boolean given, called in /var/www/sitename/public_html/sites/all/modules/menu_block/menu_block.module on line 375 and defined in menu_tree_prune_tree() (line 671 of /var/www/sitename/public_html/sites/all/modules/menu_block/menu_block.module).
Reverting back to 7.x-2.4 makes the error stop.
This error completely brought down one of my sites that utilizes menu_block on almost every page; on another site that uses it less the error occurred but the site stayed up. Still seems fairly serious, though!
Comments
Comment #1
jackalope commentedI've checked Menu Block updates on five sites now; two were affected, three were not. The two sites that had the error described above are both on servers running PHP version 5.4.36-0; the sites that aren't affected are running earlier versions of PHP. I'll report back if I find any exceptions to that rule!
Comment #2
dave reidIt looks like one of the new typehinting was wrong, since menu_item_load() returns FALSE and not NULL on failure.
Comment #3
dave reidA better version that also adds some watchdog logging as to what is wrong, since this is something that would need to be fixed in the menu block configuration.
Comment #4
bradallenfisher commentedI am seeing this on php 5.3
Comment #5
bradallenfisher commentedpatch in #3 worked for me.
Comment #6
ismail cherri commentedpatch in #3 worked for me too. Many thanks.
Comment #7
widukind commentedpatch #3 confirmed to be working for us on multiple sites. thanks!
Comment #10
dave reidCommitted #3 to 7.x-3.x and 7.x-2.x.
Comment #11
erykmynn commented#3 solved our problem!
But as a side note, I don't understand how i'd address what the new watchdog message is telling me. The parent item is the menu itself (starting at level 1)...
Comment #12
erykmynn commented#3 solved our problem!
But as a side note, I don't understand how i'd address what the new watchdog message is telling me. The parent item is the menu itself (starting at level 1)...
Comment #13
dave reid@erkmynn: What is $config['parent_mlid'] in your case then?
Comment #14
erykmynn commented@dave reid: Menu block ctools-menu-admissions-1 is set to use parent menu link menu-admissions:0 but the menu link was not loadable or does not exist.
so
menu-admissions:0 (also confirmed via DPM)
Comment #15
dave reid@erkymynn: Interesting. Can you provide any more information about how the menu block is configured? Normal block? Panels? Panelizer? If this configuration is exported to code anywhere is there a chance you could copy/paste it here?
Comment #16
erykmynn commentedPanelizer. Here is the config screen https://www.dropbox.com/s/ozjkup0osfmwtix/Screenshot%202015-02-12%2016.0... looks to be same settings as when I initially looked at the block config. Has not been exported in code.
Comment #17
dave reidHrm, I can't seem to reproduce this. Can you somehow provide an export of that config just for here?
Comment #18
erichomanchuk commentedI was having the same issue as @erkymynn in comment #14. I had a mini panel that had a menu block that was starting at a second level menu item that I include on the page. I found that re saving this mini panel updated the code in my features and fixed the error. Here is a screen grab of my diff.
Comment #19
dave reid@erichomanchuk: Oh thanks, that's super helpful - we can see in the diff that the old export had the incorrect values and the new export has the correct format and values.
Comment #20
anybodyThanks for your quick solution here.
Updating to latest .dev fixed the problem with 2.5 for me.
So if possible please create a new stable release asap to get the bug away from the stable releases.
Thanks a lot :)
Comment #21
widukind commented+1 for a new release. Please.
Comment #22
dave reidTo be clear, this is a bug in exported menu blocks that needs to be fixed. The fact that we see this error is something that would need to be fixed on individual sites. That said, I'll get a new release out soon.
Comment #23
crystaldawn commentedThis should not be marked as "Fixed" since it's not actually fixed in the tagged version which is a release version. It is however fixed the the development version. Patch in #3 works well enough to be considered RTBC. Once you roll a new release, it could then be marked fixed so that others will know to simply upgrade to the latest version. Since this was marked as fixed, I thought the release version had the fix which it did not. Or change the version of this to 7.x maybe, idk, but the tagging was confusing none the less.
Comment #24
dave reidOn Drupal.org, issues are marked fixed when they are committed. That's the standard across all projects and we're not going to deviate here.