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.
An active li.leaf
item in Drupal's menus behaves like a collapsible menu item li.collapsed
and gets expanded li.expanded
. This means its not displayed with a bullet but with an arrow (see screenshot).
Comment | File | Size | Author |
---|---|---|---|
#17 | menu_tree_output_with_tests_2.patch | 3.03 KB | derjochenmeyer |
Comments
Comment #1
derjochenmeyer CreditAttribution: derjochenmeyer commentedHere is a patch that solves it. Don't know if there is a better way to do this.
Comment #2
derjochenmeyer CreditAttribution: derjochenmeyer commentedMaring this a critical since there is no way to theme leaf items as bullets without the right CSS class.
Comment #3
derjochenmeyer CreditAttribution: derjochenmeyer commentedBetter screenshot.
Patch explanation:
$data['below']
is not empty for some menu items even if they do not have children within the displayed menu. So its not enough to check if$data['below']
is set. Example: Menu item "Modules" has the tabs in$data['below']
.Comment #4
derjochenmeyer CreditAttribution: derjochenmeyer commentedComment #5
sunNot critical. Please read and understand Priority levels of Issues, thanks.
Duplicate space here.
Also, can we flip the conditions, please? The second is the primary, actually.
Powered by Dreditor.
Comment #6
derjochenmeyer CreditAttribution: derjochenmeyer commentedNew patch with #5 suggestions.
Comment #7
sunAt first, I wasn't sure whether this really needs to be fixed in menu_tree_output() or not rather in one of the tree builder functions - but changing those would potentially break other use-cases.
To get this in, we want to put a short comment before this condition to clarify that 'below' may contain local tasks, which are not output in regular menu link trees.
Comment #8
sunFurthermore, I'd also like to see tests to ensure we don't break this logic/functionality again in the future.
Comment #9
derjochenmeyer CreditAttribution: derjochenmeyer commentedThis is actually a duplicate of #621758: Menu items erroneously get 'expanded' class.
This issue has also tests written by mooffie which slightly modified work here.
New patch includes suggenstions #7 and #8
Comment #10
derjochenmeyer CreditAttribution: derjochenmeyer commentedWho is wrong: the patch or the bot?
Comment #12
derjochenmeyer CreditAttribution: derjochenmeyer commented#9: menu_tree_output_with tests.patch queued for re-testing.
Comment #14
derjochenmeyer CreditAttribution: derjochenmeyer commentedBot doesn't like spaces in patch name?
Comment #15
derjochenmeyer CreditAttribution: derjochenmeyer commentedComment #16
sun1) The new comment wraps too early.
2) We can combine/rephrase the old with the new comment.
Missing class/function docblocks.
Do we really need this helper function?
Trailing white-space here.
1) That second path looks weird.
2) The menu item titles should summarize what's being tested.
Shouldn't we test local tasks?
107 critical left. Go review some!
Comment #17
derjochenmeyer CreditAttribution: derjochenmeyer commentedThanks for reviewing the patch.
New patch includes suggestions #16.
Comment #18
derjochenmeyer CreditAttribution: derjochenmeyer commentedAny ideas?
Comment #19
cwgordon7 CreditAttribution: cwgordon7 commentedPatch still applies with a bit of offset, and works to fix this problem, and the code looks good, so this is rtbc. Nice work!
Comment #20
Dries CreditAttribution: Dries commentedCommitted to CVS HEAD. Thanks.
Comment #21
andypostCommit http://drupal.org/cvs?commit=395108 missed hunks with tests
Comment #22
cwgordon7 CreditAttribution: cwgordon7 commentedAlso, for some reason, this patch does not appear working for paths like admin/structure/types. Not sure if that's a side effect of not having the whole thing committed or if it's just a fault of the patch.
Comment #23
andypostConfirm that admin/structure/block and admin/structure/types are displayed like holding children
Comment #24
derjochenmeyer CreditAttribution: derjochenmeyer commentedAt the time this patch was written $data['below'] was empty for links without children in the current menu. Some other modification apparently changed this.
I dont see any possibility to solve this with the current approach, because we cannot tell from looking at $data anymore whether a link has children in the current menu, or if these children are (e.g.) "action-links" (like "Add content type" below "Content types").
Any ideas where to start from? Where is the $data array beeing built?
Comment #25
sunI'd recommend to complete the commit first, because that work is valuable on its own.
Comment #26
derjochenmeyer CreditAttribution: derjochenmeyer commentedCan i contribute to making this commit work? If so, how?
Comment #27
cwgordon7 CreditAttribution: cwgordon7 commentedI do not think we should commit this test until we figure out why it is not catching the bug.
Comment #28
sunhm, true, too.
Comment #29
derjochenmeyer CreditAttribution: derjochenmeyer commentedAny ideas where to start from?
Comment #30
gooddesignusa CreditAttribution: gooddesignusa commentedI just ran into this issue and posted here first http://drupal.org/node/955378 (Menu items - "Has children" flag is not reset on menu reordering). Tried that patch and it didn't seem to help. Seems like this isn't the only thread of this issue. Going to try this one as well.
edit: sorry didn't realize this was for D7
Comment #31
JustMagicMaria CreditAttribution: JustMagicMaria commentedStill running into this in 7.7.
Comment #32
andypostdo we have the issue in d8?
Comment #37
vijaycs85Do we still need this issue? Seems committed to D8 7 years back.