i18n conflict - Menu reaction doesn't have any effect

subscribing

subscribe

Both context and i18n_menu are changing menu items by implementing hook_preprocess_page(). So the problem is about the order of execution. Changing module weights doesn't help because context is altering the theme registry to always hook right after template_preprocess_page() (see context_theme_registry_alter()). Now which module's weight should be changed and how? I think this is a question which maintainers of both modules have to decide.

In #1139722: context conflict - Menu are recreated in i18n_menu_preprocess_page even if they were already defined the maintainer of i18n suggested that a context patch would be more efficient, here is the first try.

This patch in #8 works like a charm and the problems are gone! THanx a lot for this fix!

Cheers

hctom

One of the problems with this is that context needs to preprocess the page early on, that is why it is splicing right into the preprocess stack immediately after template_preprocess_page, this patch however is now putting it after i18n_menu, which could be just about anywhere in the preprocess stack. This also does not handle the case where i18n_preprocess_page is not in the stack (if they change their implementation then this will stop working entirely)

Okay.. how about this approach?

/**
 * Implementation of hook_theme_registry_alter().
 */
function context_theme_registry_alter(&$theme_registry) {
  // Push theme_page() through a context_preprocess to provide
  // context-sensitive menus and variables. Ensure that
  // context_preprocess_page() comes immediately after
  // template_preprocess_page().
  $position = array_search('context_preprocess_page', $theme_registry['page']['preprocess functions']);
  if ($position !== FALSE) {
    unset($theme_registry['page']['preprocess functions'][$position]);
  }
  $position = array_search('template_preprocess_page', $theme_registry['page']['preprocess functions']);
  $position = $position ? $position + 1 : 2;
  array_splice($theme_registry['page']['preprocess functions'], $position, 0, 'context_preprocess_page');
  // New stuf ++++++++++++++++++++++++++++++++++++++++++
  if (module_exists('i18n_menu')) {
      $index_context = array_search('context_preprocess_page', $theme_registry['page']['preprocess functions'], TRUE);
      $index_i18n_menu = array_search('i18n_menu_preprocess_page', $theme_registry['page']['preprocess functions'], TRUE);
      if ($index_context !== FALSE && $index_i18n_menu !== FALSE && $index_context < $index_i18n_menu) {
        unset($theme_registry['page']['preprocess functions'][$index_i18n_menu]);
        array_splice($theme_registry['page']['preprocess functions'], $index_context, 1, array('i18n_menu_preprocess_page', 'context_preprocess_page'));
      }
    }
}

Cheers

hctom

#12 Works perfectly. Apply it and clear your cache.

#12 works on my side, too.

Neither #10 nor #12 work for me (i18n-6.x-1.10, i18nmenu_node-6.x-1.2).
#4 works

Serg.remote, this post if for D7.

I have the same problem for D6...I have applied the solutions here [http://drupal.org/node/586396] with no luck, any ideas?

#12 works great for me :)

I took the liberty of creating a patch to hctom's solution in #12. I created it against the 7.x-3.x branch. I do hope this makes it to the 3.0 release!

actually the changes from #12 are working. that means, the context action now does what it is supposed to do.
But, the i18n_menu functionality is kind of broken, there are german menu items on english pages and english menu items on german pages.

I can confirm that the patch #12 causes all kind of weird shit to happen. So much so that I actually thought I'm losing my mind.

It appears that this is caused by the following part (between >>> and <<<) in plugins/context_reaction_menu.inc:

  /**
   * If primary + secondary links are pointed at the same menu, provide
   * contextual trailing by default.
   */
  function execute(&$vars = NULL) {
    // THIS >>>
    if (variable_get('menu_main_links_source', 'main-menu') == variable_get('menu_secondary_links_source', 'user-menu')) {
     $vars['main_menu'] = theme_get_setting('toggle_main_menu') ? $this->menu_navigation_links(variable_get('menu_main_links_source', 'main-menu')) : $vars['main_menu'];
     $vars['secondary_menu'] = theme_get_setting('toggle_secondary_menu') ? $this->menu_navigation_links(variable_get('menu_secondary_links_source', 'secondary-links'), 1) : $vars['secondary_menu'];
    }
    // <<<

    $vars['main_menu'] = $this->menu_set_active($vars['main_menu']);
    $vars['secondary_menu'] = $this->menu_set_active($vars['secondary_menu']);
  }

  function get_active_paths() {
    $active_paths = array();
    foreach ($this->get_contexts() as $context) {
      if (isset($context->reactions[$this->plugin])) {
        $active_paths[] = $context->reactions[$this->plugin];
      }
    }
    return $active_paths;
  }

So, removing those lines leaves the i18n_menu translations intact and the menu works just fine (atleast in our setup).

Maybe that part just needs to be patched so that it does not reset the menu?

Adding a patch for the above for quicker testing.

Attached patch AND the #12 patch seems to get this thing working.

@tcmug, thank you for your work but it just won't work with me.

I got the latest DEV branch, applied patches from #12 and #24 but it will only work for menu items in English, not in Portuguese.

if you need more details please let me know. thanks in advance.

cheers,
Luciano

Luciano: I had a look at what other patches we run to the module and found this Fix breadcrumb not working properly with i18n - I'm no expert on how the menus work but worth trying?

Also another difference is that we're using the beta3 version along with menu_block 2.2 to display the menus.

@tcmug thanks for the reply. I'll test these options as soon as possible, but right now I have to present a working, well - something - without so much as real content. go figure. :)

I used both #8 and #24 and it fixed my issue, however I think this issue should be split into two:

Issue 1
"Stop i18n_menu from overriding context menu reactions" for patch #8, This should be committed as it insures the context menu reaction isn't overridden by i18n_menu.

Issue 2
"Make context menu reaction use i18n_menu if it is enabled" for patch #24, this worked for me but as i18n_menu has a number of use cases this may need more testing and is a separate issue from #8

I would handle this by keeping this issue "i18n conflict - Menu reaction doesn't have any effect" for Issue 1 (patch #8) and creating an new one for Issue 2 (patch #24)

Committed 8 and 24 together. Thanks for the bug report and to the various work on the patch(es).

http://drupalcode.org/project/context.git/commit/baacf1593ab42fd63193afa...

I can confirm it works even without Menu Block. :) thank you guys!