After upgrading to menu views 2.0, there seems to be a conflict with menuperformance, a module that allows better handling of huge menus. It works well with the 1.x branch of menu_views.

Parent item becomes empty, resulting in an illegal choice and then we are unable to save the menu item.

Any toughts on this issue?

Comments

szantog’s picture

The same is with hierarchical_select. I don't need to set up new menu views item too often, so I just simple disable the menu_views form alter in my module (I can turn back in a settings page).

function hm_hook_module_implements_alter(&$implementations, $hook) {
  if ($hook == 'form_alter' && variable_get('hm_condition_disable_menu_views', 1)) {
    unset($implementations['menu_views']);
  }
} 
markhalliwell’s picture

Title: Conflict with menuperformance module » Support menuperformance module
Category: bug » feature
Status: Active » Closed (won't fix)

Due to the small number of installs of that module and my current time constraints, I'm marking this as "won't fix". Please provide a patch if you wish to re-open this.

RunePhilosof’s picture

Issue summary: View changes
Status: Closed (won't fix) » Needs review
StatusFileSize
new3.38 KB

I have rewritten szantog's suggestion of a workaround as a patch

markhalliwell’s picture

Status: Needs review » Closed (won't fix)

I'm really not willing to entertain the idea of disabling the form alterations. This would introduce the possibility of a menu item getting re-saved and losing the menu_views data. I'm re-closing this issue unless a patch can be created regarding the actual issue at hand, not some workaround like this.

RunePhilosof’s picture

Status: Closed (won't fix) » Needs review

A better patch would include avoiding setting the `$element['parent']['#options']`
Why do you do that?

markhalliwell’s picture

Status: Needs review » Closed (won't fix)