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.

CommentFileSizeAuthor
#6 d7-menu.patch1.21 KBpillarsdotnet
#4 menu.patch1.86 KBpillarsdotnet
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

reubenavery’s picture

OK 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.

xmacinfo’s picture

Question, are you using admin menu? And if so, which version?

reubenavery’s picture

I 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

pillarsdotnet’s picture

Version: 6.13 » 6.x-dev
Status: Active » Needs review
FileSize
1.86 KB

Patch to resolve the root problem.

Status: Needs review » Needs work

The last submitted patch, menu.patch, failed testing.

pillarsdotnet’s picture

Version: 6.x-dev » 7.x-dev
FileSize
1.21 KB

I'm sorry; must patch the current version first, then backport.

pillarsdotnet’s picture

Status: Needs work » Needs review
sun’s picture

Status: Needs review » Active

Of course, this patch won't fly ;)

pillarsdotnet’s picture

Version: 7.x-dev » 6.x-dev

@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.

crifi’s picture

I 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...

pillarsdotnet’s picture

@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.

crifi’s picture

Ahh 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... :-)

Dave Cohen’s picture

Version: 6.x-dev » 7.x-dev

I 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. ;)

pillarsdotnet’s picture

@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.

pillarsdotnet’s picture

Status: Active » Closed (duplicate)
deeve’s picture

Assigned: Unassigned » deeve

I'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.

pillarsdotnet’s picture

Assigned: deeve » Unassigned
  1. Don't comment on issues that are closed unless you intend to re-open them.
  2. Don't assign yourself to an issue unless you are taking responsibility for fixing it.
  3. See http://drupal.org/patch
deeve’s picture

My 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.