wizzud

Okay, from my point of view the answer is straightforward : CMW doesn’t assign the item IDs, WordPress does. However, that probably doesn’t help you very much …

I think you will find that WordPress will only assign an ID if the ID that it intends assigning – in the format menu-item-[ID of the menu item] – has not already been used elsewhere on the page. So, for example, if you were to do jQuery(‘#menu-item-419’) on the page that produced the code pasted above, then you would get a result … but the element located would be somewhere else on the page. This is how WordPress avoids creating invalid duplicate IDs.

PS : If you are after the “menu-item-####” from the class, have you considered using a regex? …

x = (el.className.match(/(^|\s)(menu-item-\d+)(\s|$)/) || [0,0,''])[2];

CMW only provides the means to filter the menu items, not to edit them.
Assuming that you can’t modify the menu itself (because “Fruits” is probably only a small part of it), the code below will replace every occurrence of the string “Fruits” with “All”. But be warned : it’s an all-encompassing solution for any CMW-produced menu … and that may not be what you want!

add_filter( 'wp_nav_menu', 'my_cmw_nav_menu_as_dropdown', 10, 2 );
function my_cmw_nav_menu_as_dropdown( $nav_menu, $args ){
  if( !empty( $args->_custom_menu_wizard ){
    $nav_menu = str_replace( 'Fruits, 'All', $nav_menu );
  }
  return $nav_menu;
}

From within the widget itself, No.

You could code an additional filter into your theme’s functions.php to do it, if you wished? As an example…

add_filter( 'wp_nav_menu', 'my_cmw_nav_menu_as_dropdown', 10, 2 );
function my_cmw_nav_menu_as_dropdown( $nav_menu, $args ){
  if( !empty( $args->_custom_menu_wizard )
      && $args->_custom_menu_wizard['flat_output'] ){
    $nav_menu = preg_replace_callback(
      array( '/<li[^>]*>(.*?)<\/li>/', '/<ul([^>]*)>/', '/<\/ul>/' ),
      'my_cmw_nav_menu_as_dropdown_callback',
      str_replace( '</ul>', '</select>', $nav_menu )
      );
  }
  return $nav_menu;
}
function my_cmw_nav_menu_as_dropdown_callback( $matches ){
  $firstChars = substr( $matches[0], 0, 2 );
  $rtn = $matches[0];
  if( $firstChars == '<l' ){
    if( preg_match( '/href="([^"]+)"[^>]*>([^<]+)</', $matches[1], $m ) > 0 ){
      $rtn = '<option data-href="' . $m[1] . '">' . $m[2] . '</option>';
    }else{
      $rtn = '<option>' . $matches[1] . '</option>';
    }
  }elseif( $firstChars == '<u' ){
    if( preg_match( '/id="(.*?)"/', $matches[1], $m ) > 0 ){
      $rtn = '<select name="' . $m[1] . '"' . $matches[1] . '>';
    }else{
      $rtn = '<select' . $matches[1] . '>';
    }
  }
  return $rtn;
}

CMW’s container option is intended to take a tag, because that’s what wp_nav_menu() handles.

The tags that wp_nav_menu() accepts can be modified from the defaults (“div” or “nav”) by using a filter – “wp_nav_menu_container_allowedtags” (ref: wp_nav_menu() in wp-includes/nav-menu-template.php) – but that filter receives nothing that lets you know whether wp_nav_menu() is processing a CMW menu or some other menu (should you need to be able distinguish).

An alternative might be to hook into wp_nav_menu()‘s “wp_nav_menu” filter. For example…

add_filter( 'wp_nav_menu', 'my_cmw_nav_menu_filter', 10, 2 );
function my_cmw_nav_menu_filter( $nav_menu, $args ){
    if( !empty( $args->_custom_menu_wizard )
            && !empty( $args->_custom_menu_wizard['container'] ) ){
        $nav_menu = preg_replace(
            '/^<(' . $args->_custom_menu_wizard['container'] . ')/',
            '<$1 itemscope="itemscope"',
            $nav_menu
            );
    }
    return $nav_menu;
}

I have released CMW v2.0.6 which – with any luck – might hopefully solve your problem. I can’t be absolutely certain because it is still dependent on the flags (not classes!) set by WordPress or other plugins that modify menus. Give it a try and let me know?

PS : If your custom product posts are provided by a plugin, it might be worth letting the plugin author know about this problem, because the validity of having a parent and child item both marked as “current” (when the items are distinct) might be considered … umm … debatable?

That is … disturbing.

I can see that the page being displayed is “NC-100 Family” : may I ask, of the classes assigned (in the CMW sidebar widget) to the “Products” item and the “NC-100 Family” item, which item has a class of “current-menu-item” and/or “current_page_item” (or any other class that indicates “current”)?

I appreciate that CMW isn’t currently doing what you need it to, but by any chance do you have a web-accessible page that shows this problem, so that I can take a look?

As some background : the “assist” is an emulator, ie. it does not know or care what the actual menu items represent within WordPress, they are merely “items”. Setting a “current menu item” in the assist makes it act as CMW would (should!) *if* CMW determined that that same item was the first-found item marked by WordPress as “current”. In your case, what I suspect might be happening is that “Products” has been marked – by WordPress – as “current”, so CMW is treating it as such even though the page on display is “NC-100 Family”. (It’s only a suspicion because I can’t see the widget’s shortcode equivalent in your image, so I’m guessing a little bit).

Ideally, I would like to see a CMW instance showing the entire menu (ie. set to Show All) so that I can see what each item’s classes are depending on the current page being shown (if it is possible, and not too much trouble … maybe by giving the widget a class that sets the entire widget to display:none;?).

I’m sorry this is giving you problems, and I appreciate any assistance you can give me in determining the cause.

With all due deference, I suspect it’s not. If CMW works with a theme, but not with a child of that theme, then surely the implication is that the problem lies with whatever has changed between the 2 scenarios, ie. the child theme?
If you have “inactive sidebars” – as opposed to a non-functioning widget within a sidebar – maybe your child theme is somehow preventing the parent theme registering its sidebars?

Yes, but you have to provide it yourself.

CMW does not provide any front end styling : themes handle styling, and if I tried to provide additional styling it would be “wrong”, in some way or another, and to greater or lesser degrees, for almost every single user!

You have the ability to add class(es) and/or a unique id to any instance of the widget. You can then add CSS rules to your (child?) theme’s stylesheet to override your theme’s default styling. I would suggest giving the widget container a unique id or class, and then using Firebug (or similar) to dynamically override the current rules (with new rules using your added id/class) to suit what you want. Then copy your updates into your stylesheet.