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.
I noticed that the state of a menu item that is associated with a node (via the integrated menu on-the-fly feature) gets resetted if the node is updated. That means for example, if you set the "expanded" flag in the menu administration, and then edit the node, this flag is not preserved but resetted.
Comment | File | Size | Author |
---|---|---|---|
#11 | menu-otf-settings-4-7.patch | 804 bytes | kkaefer |
#9 | menu-otf-settings.patch | 806 bytes | kkaefer |
Comments
Comment #1
Egon Bianchet CreditAttribution: Egon Bianchet commentedCan't reproduce it in 4.7.0
Comment #2
JoshLangner CreditAttribution: JoshLangner commentedI have been able to reproduce this problem in 4.7.2. This is a serious problem for me, because my site uses drop-down menus to operate. If one of the primary links gets edited, the expanded status gets reset, and the drop-downs no longer appear.
Comment #3
JoshLangner CreditAttribution: JoshLangner commentedNOTE: This bug is similar to, if not identical to, the bug found here: http://drupal.org/node/48178
Comment #4
JoshLangner CreditAttribution: JoshLangner commentedCorrection:
This bug is similar to, if not identical to, the bug found here: http://drupal.org/node/18351
(copy-paste isn't exactly as smart as I sometimes think :) )
Comment #5
kkaefer CreditAttribution: kkaefer commentedAnother report of this bug: http://drupal.org/node/79881
Comment #6
JoshLangner CreditAttribution: JoshLangner commentedHere is a related bug: http://drupal.org/node/77569
I'm not certain if this is the Category module's fault or just the built-in menu-on-the-fly's fault.
Comment #7
venkat-rk CreditAttribution: venkat-rk commentedCategory_menu relies on the core menu system (which includes menu_otf since 4.6), so I would bet it's probably menu_otf
Comment #8
kkaefer CreditAttribution: kkaefer commentedThis bug does still exist in HEAD.
Comment #9
kkaefer CreditAttribution: kkaefer commentedI finally could track down this bug: In the menu fieldset on a node editing form, you can’t specify whether the menu item should be expanded by default or not. That means, the
expanded
index in the$edit
array was missing. However,menu_edit_item_save
just checked for$edit['expanded']
. If it’s false or not set, theMENU_EXPANDED
constant will be removed from the menu item. Now, this function checks first if theexpanded
index is present or not before altering$type
.Comment #10
profix898 CreditAttribution: profix898 commentedCode looks good and works as advertised.
Comment #11
kkaefer CreditAttribution: kkaefer commentedThis patch is specifically for 4.7! For HEAD, use the patch above.
Comment #12
gemini CreditAttribution: gemini commentedNot sure if this is the right place to post.
In my case I have top menu and side navigation which is set to be available in the post authoring form. Every time I go to edit a node that linked from top menu - menu item from the top menu appears in the menu settings and the parent item is restricted to side navigation. By updating the node it creates the menu in the side navigation which makes is redundant (it is already in top menu). By removing menu item name - it removes it from the original top navigation. So, restricting parent items in the administrative menu settings only to one menu still affects other menus that so not appear on the node creation/edition page. Can this be avoided?
Comment #13
kkaefer CreditAttribution: kkaefer commentedIt is not. Your problem is entirely different.
Comment #14
drummCommitted to HEAD.
Comment #15
kkaefer CreditAttribution: kkaefer commentedComment #16
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedapplied
Comment #17
(not verified) CreditAttribution: commented