wizzud

Here’s a slight modification to the above code…

jQuery(function($){
  $('.widget_custom_menu_wizard').each(function(){
    var currPath = $(this).find('li.current-menu-item');
    $(this).find('ul ul').each(function(){
      $('<a/>', {href:'#'})
        .addClass('cmw-expander')
        .html('<span>▲</span><span style="display:none;">▼</span>')
        .css({position:'absolute',right:'-1em',textDecoration:'none'})
        .on('click', function(ev, hide){
          var d = $(this).data(),
              isOpen = !d.closed,
              effect = hide?'hide':(isOpen?'slideUp':'slideDown');
          $(this).siblings('ul')[effect]();
          $(this).find('span').each(function(i){
            $(this)[!i === isOpen ? 'hide' : 'show']();
          });
          d.closed = isOpen;
          this.blur();
          return false;
        })
        .prependTo($(this).parent().css('position','relative'));
    });
    if(currPath.length){
      currPath = currPath.parentsUntil(this, 'li')
        .add(currPath).children('.cmw-expander');
    }
    $(this).find('.cmw-expander').not(currPath)
      .trigger('click', [true]);
  });
});

The differences are that it initially keeps the current menu item (assuming there is one!) expanded (ancestors and immediate children), and the trigger is absolutely positioned to the right.

Once again, this is only meant to be an example of what can be done. It is not intended for a production site!

I’m afraid it’s down to the WordPress Access Control plugin.

I’ll see if I can explain (sorry, but it does get a bit technical!)…

Both CMW and WAC have their own nav menu Walkers, and both are extensions of WP’s own Walker. (And note that entry point into any Walker is its walk)( method).

Now, CMW gives its Walker to wp_nav_menu(), whereupon WAC then replaces the CMW Walker with its own Walker, but keeps the CMW Walker “alive” within the WAC Walker.
At some point in the wp_nav_menu() processing, Walker->walk() is called.
The WAC Walker does not have its own walk() method, but it has inherited one from the WP Walker, and it’s the WP Walker->walk() that actually gets run. Which is where your problem lies!

Now, the WAC Walker has code within it – “magic” methods, such as __call and __get – which are (presumably) intended to call CMW Walker methods (like walk()) if the WAC Walker doesn’t have its own version. However, they are effectively useless because the WAC Walker has inherited a walk() from the WP Walker! So the “magic” methods are only of any use for CMW’s custom methods/properties, which are of no relevance when then walk() entry point can’t be reached.

<?php
class WPN {
	function walk(){
		echo __METHOD__ . '<br>';
	}
}
class CMW extends WPN {
	function walk(){
		echo __METHOD__ . '<br>';
	}
	function beta(){
		echo __METHOD__ . '<br>';
	}
}
class WAC extends WPN {
	function __construct( $repl = null ){
		$this->repl = empty( $repl ) ? new AA() : $repl;
	}
	function __call( $name, $args ){
		call_user_func( array( $this->repl, $name ), $args );
	}
}

$b = new CMW();
$c = new WAC( $b );

$b->walk(); // CMW::walk ... this would be CMW without WAC, but...
$c->walk(); // WPN::walk ... WAC gets in the way & runs WP's walk
$c->beta(); // CMW::beta ... WAC runs CMW's custom beta()!
?>

So, basically CMW and the WordPress Access Control plugin in incompatible. Sorry! But it should point out that it was always likely to cause problems where 2 plugins are tryin

hmm …
Well I’m glad you’ve located the problem area. Looks like I’m going to have to take a peek into the WordPress Access Control plugin and see if I can determine which of us isn’t playing nice…

Do you have a web-accessible site that I can look at to see this in action?

Can you show me the shortcode equivalent of the settings you are using, please?

[ If you’re using CMW as a widget, open its Assist, click in the shortcode box at the bottom, and copy-paste its content here (this assumes that the shortcode represents the Saved widget settings!) ]

The settings you have applied – according to the shortcode given – will only list the root page (“About Us”) if that root page is the current page.

I hesitate to suggest this, but …
You have set the text “About Us” as the title of the widget : Are you sure that you’re not getting confused about what is the title of the widget and what is the content of the widget?
For example, if you were to (temporarily!) change the title of the widget to, say, “Something Else”, and then to navigate to one of the sub-pages, do you then see any mention of “About Us”?

Your Memoir theme has a rule that sets .menu-item to float left (style.css, line 52)…

.menu-item {
    float: left;
    padding-right: 20px;
}

The padding-right is irrelevant (it’s overridden to zero by another rule), but your problem is the float:left;.

You need another rule that clears the float for the content of a CMW widget, for example…

.widget_custom_menu_wizard .menu-item {
    float: none;
}

This is specific to CMW widgets, but you could make it specific to any widget, or to just sidebar widgets, by changing the lead class.

There is (currently) no shortcode option available for changing the HTML element that wraps the title of a widget produced via a shortcode. The default is an H2, with a class of “widgettitle”, and that default is the WordPress default (see before_title & after_title args in documentation for the_widget()).

There is, however, a filter available if you can add something along these lines into your theme’s functions.php :

function my_cmw_shortcode_filter( $sidebar_args ){
    // before_title default is '<h2 class="widgettitle">' : change to ...
    $sidebar_args[ 'before_title' ] is '<h4 class="widgettitle">';
    // corresponding after_title default = '</h2>' : change to ...
    $sidebar_args[ 'after_title' ] = '</h4>';
    // NB : other sidebar_args are before_widget and after_widget
    return $sidebar_args;
}
add_filter( 'custom_menu_wizard_shortcode_widget_args', 'my_cmw_shortcode_filter', 10, 1 );

If your H4 doesn’t need a class then remove it, or modify it to whatever you want it to be.

[ If you don’t already use a child theme then I would suggest that you consider doing so, otherwise any upgrade to your theme will lose any modifications you make to its functions.php! ]

Hmmm … that is curious, because CMW doesn’t really care about urls and it doesn’t do any filtering by menu item titles. At the front end, the only time it looks at a title is if you set a Title From option, and even then it simply takes it and outputs it (suitably filtered, as all titles are).
In admin it displays menu item titles in the “assist” and the children-of SELECT, but it only uses/stores ids.

Could you expand a bit on “it doesn’t work”, please?
Like … Is the problem with admin, or at the front end? Is something being displayed, or nothing? Is there a partial or scrambled display? What settings are you using? (maybe you could show me the shortcode equivalent?) Are you using it as a shortcode, as as a widget? If you have options set, have you tried simply leaving it at Show All (with no other options modified)?

Try adding a CSS rule for .current-menu-item > a, eg.

.current-menu-item > a {border: 1px solid #ffff00;}

If you need to restrict it to just the CMW plugin then…

.widget_custom_menu_wizard .current-menu-item > a {
    border: 1px solid #ffff00;
}

Have you tried something like Children of Current Root Item, maybe with Include Parent?

Can you give me the shortcode equivalent of your widget settings, please?
And are you using the latest versions of woocommerce (not sure it matters, but it might help me when testing), CMW, and WordPress?

Thanks Spanka. I’ll give your suggestions some serious consideration (without making any promises!)…

Sorry for the delayed response, but for some reason I didn’t get notified of this question.

As always, FireFox’s Firebug is very definitely your best friend in this sort of situation. But most modern browsers have perfectly adequate developer tools built-in nowadays, and any of them should be able to provide enough information for you to be able to tell which particular styles are being applied to any element. That should be enough for you to be able to dynamically add your own style in order to override colour (for example). Just adding !important is not always enough, because you also have to consider the specificity of the rule you’re applying, versus the specificity and importance of the rule(s) already being applied.

If you have a live site I could look at – with guidance as to exactly what should be changed to what – then I could take a look?

Without going through every page of your site, I can’t see the CMW plugin being used, so I assume you’ve removed it.

The simplest way to test the code above is in Firefox, using the Firebug extension : create a widget that will output multiple levels of menu items, and go to the page at the frontend; make sure Firebug is running, and in its Console tab’s code box, paste the above code and Run it. (it works – on a 2 level menu – because I’ve just re-tested it). You could also run the debugger (the Script tab) on the included (into your theme) javascript, and put breakpoints at certain points in the code snippet to make sure you’re hitting them?

Wrt the CSS & Javascript Toolbox, I don’t know what the error could be that it produces, and I have to admit that I haven’t tried the Toolbox recently, or even specifically with this code … I mentioned it because its a plugin that I have used successfully in the past, and it is intended to handle precisely this sort of scenario. Also note that I only gave it as an example – doubtless there are others that will do a similar job, and a lot of themes also provide customisation of this sort as part of their options.

For “popup” submenus you’re going to need a whole lot more script and/or styling, and a clear idea of what a “popup” means to you. I would suggest that you look around for a specific script plugin to handle them (probably a jQuery one?), and then set it up to handle your particular requirements. Remember that you can always set CMW up with a unique id on the container, so that jQuery javascript can target very specific instances of the widget, and if you use, for example, body classes in the selector as well, you can even target the same widget instance but on different pages. All sorts of possibilities are available … and Firebug is definitely the developer’s best friend (my opinion!).