It seems that when one disables a module which has a customized menu item (for example, I moved the menu item for Advanced Profile settings to the Users admin menu), a situation occurs where menu corruption starts to take hold. First, the custom menu item remains for the disabled module. Then when I clicked "Reset" on the item wanting to remove it, the result was a duplicate item of "Site configuration" was created.
I then tried re-enabling the module, and the module's menu item was recreated but at the root of /admin, rather than where it was defined in admin/settings. There is no "reset" option here, either. And the bogus duplicate of "Site configuration" is still there, also without any Reset or Delete functionality.
Flushing the cache and executing devel's "rebuild menus" seems to have no effect.
Comment | File | Size | Author |
---|---|---|---|
#6 | d7-menu.patch | 1.21 KB | pillarsdotnet |
#4 | menu.patch | 1.86 KB | pillarsdotnet |
Comments
Comment #1
reubenavery CreditAttribution: reubenavery commentedOK so I just restored from a backup, and then went and re-enabled the module whose customized menu item I wanted to remove. I then went and tried "reset" on the menu item, and the result was that again the bogus dupe of "Site configuration" was created. Unlike the use case above, however, the actual menu item seems to be now missing.
Comment #2
xmacinfoQuestion, are you using admin menu? And if so, which version?
Comment #3
reubenavery CreditAttribution: reubenavery commentedI first encountered this behavior on a site running admin menu, but can readily reproduce it on other sites that do not have admin menu installed.
Basically, I think it's along these lines:
1. Enable a module that has menu items
2. Modify any of those menu items (moving to other menus, changing weight)
3. Disable said module
4. Altered menu items of that module will remain. Try clicking the "reset" links in the menu manager will then result in that menu link being renamed to its parent item. Unable to delete through system, have to go directly to the db
Comment #4
pillarsdotnet CreditAttribution: pillarsdotnet commentedPatch to resolve the root problem.
Comment #6
pillarsdotnet CreditAttribution: pillarsdotnet commentedI'm sorry; must patch the current version first, then backport.
Comment #7
pillarsdotnet CreditAttribution: pillarsdotnet commentedComment #8
sunOf course, this patch won't fly ;)
Comment #9
pillarsdotnet CreditAttribution: pillarsdotnet commented@sun -- Whaddyamean? Testbot is green; patch worked beautifully! now to backport...
Seriously, though:
When a module is disabled, obviously there is code somewhere that deletes that module's menu entries. Seems like that code doesn't correctly handle menu entries which have been customized. So one possible workaround would be to reset all the module's menu entries to defaults just before disabling the module. 'Course, that assumes it is possible to identify, via the database, which module a particular menu entry belongs to. If someone smarter than me thinks this approach might be feasible, I'd be willing to invest some time into it.
Comment #10
crifi CreditAttribution: crifi commentedI think sun disagrees because we should patch that menu items created by a module aren't deleted correctly when removing the module.
There is no argument to hold a (changed) module menu item when the module is uninstalled. Under the assumption this bug is reproducible we should fix the cause (in the function drupal_uninstall_modules?!) instead of showing warning messages...
Comment #11
pillarsdotnet CreditAttribution: pillarsdotnet commented@crifi -- Of course, the patch and sun's response were both meant as a joke, not to be taken seriously.
As for the approach I mentioned, it probably belongs in 8.x rather than 7.x.
Comment #12
crifi CreditAttribution: crifi commentedAhh okay, until now I believed that the bug tracker is only a workplace for serious issues. 'Cause people like me are looking around here to help out and it also takes time to look into such abnormal patches... :-)
Comment #13
Dave Cohen CreditAttribution: Dave Cohen commentedI find that when I develop a custom module, implementing hook_menu(), if I create a menu item that way. Then later, change the path of that item, the first path stays in the menu. I can't find any way to delete it. Is that the same issue?
P.S. I don't see anything wrong with patch #6. ;)
Comment #14
pillarsdotnet CreditAttribution: pillarsdotnet commented@Dave Cohen -- I dunno; you probably need to talk to someone smarter than me.
If there is a Drupal API function to modify a module's menu items on update, and you're using it, and it doesn't work as expected, open a separate bug report against that API function.
If no such API function exists, then open a feature request against 8.x-dev. Preferably with a patch that applies cleanly against CVS HEAD.
As for patch #6, I've already applied it to my own site. I eat my own dogfood.
Comment #15
pillarsdotnet CreditAttribution: pillarsdotnet commentedI believe this is a duplicate of #550254: Menu links are sometimes not properly re-parented
Comment #16
deeve CreditAttribution: deeve commentedI'm running D7 & experience this bug/error now. I would give patch #6 a go but as a newbie am unsure as how to apply - can anyone please advise, or has it been solved elsewhere?
Thanks.
Comment #17
pillarsdotnet CreditAttribution: pillarsdotnet commentedComment #18
deeve CreditAttribution: deeve commentedMy apologies.
1. I only thought to re-open the thread as couldn't find a definitive solution to this bug on here.
2. I didn't realize to assign was to take responsibility; I thought it was the way of being subscribed to the thread - not very clear on this forum on how to achieve such a simple task ..& yes, I have asked before.
3. Thank you for the link.