The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem._uswds_mark_menu_items needs to check that it has an array before passing to the foreach
THis seems to occur when the footer menu is placed, but is empty.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 3051475-3.patch | 622 bytes | brian.seek |
| warning-footer-array.png | 163.17 KB | swirt |
Comments
Comment #2
fskreuz commentedCouldn't reproduce this bug. I added an empty menu to the footer region and I didn't get the warning. In fact, the function doesn't even get called at all. I have a feeling something outside Drupal and the theme is involved.
- Do you have modules that modify menus in any way?
- Do you have modules and/or code that renders menus outside of the built-in block layout?
- Do you have code in a module/in a theme that programmatically renders menus?
Additionally, if possible, can we have the full stack trace and maybe a dump of the contents of
$variables['content']?Comment #3
brian.seek commented@fskreuz did you add the footer menu block to the region? Seems like this is being triggered from the pre-process that runs on that menu block specifically.
The following patch clears up the issue.
Comment #4
swirtSorry I missed responding to your question fskreuz.
brian.seek nailed it.
Thanks fskreuz for looking into it and brian.seek for the patch.
Comment #5
fskreuz commentedI'm just curious why this happens because
_uswds_mark_menu_itemsis called in 5 different places.-
uswds_preprocess_block__system_menu_block__footer_menu-
uswds_preprocess_block__system_menu_block__primary_menu-
uswds_preprocess_block__system_menu_block__secondary_menu-
uswds_preprocess_block__system_menu_block__sidebar_first-
uswds_preprocess_block__system_menu_block__sidebar_secondIf this issue broke all 5 menus when they're present, then yes, the patch makes sense. But if the issue breaks just the footer menu and NOT the other menus, there's something else going on and putting an
isset()would just be hiding the real issue. It's also odd that#itemswould be missing from the render array.Comment #6
brian.seek commentedfskreuz I agree with that assessment. I will dig in a little deeper to see if I can figure out why the footer is the only menu that seems to generate this error.
Comment #7
swirt@fskreuz I don't recall testing for all of the menus breaking if not present, only the footer. Did you test all of those?
brian.seek's fix would account for any and all of them. Making sure you have something to work with before jumping into a foreach is kind of a standard safety check in php. It certainly solves the red php warning. I don't think the fact that we have not found a deeper rooted cause should get in the way of this bering merged in.
A better modification would be to check if it is set AND that it is an array since foreach's get cranky if your feed them something that is not an array.
In the case I am reporting, #items is missing because there are no items in the menu. It is unpopulated, which is an acceptable state for a user controlled menu that should not throw php warnings because a user removes the last item from the menu. The code should be able to handle that gracefully.
Comment #8
brian.seek commented@fskreuz I dug in a little more. In normal cases the block containing an empty menu wouldn't render, so this would never crop up. On this project, we are using the menu_block module. That module causes the block to render with empty items. I think so that it can dynamically render depending on the page context and depth.
Like @swirt mentioned, my patch is a good safe guard for non-core provided menu block instances.
Comment #9
swirtTested this out and resolves the issue I reported.
Comment #10
fskreuz commentedLooks good to me. Ship it! ^_^)b
Comment #12
irisibk commented