wizzud

If you inspect the widget’s output with your browser’s development tools you should see an encasing DIV that has a class of widget_custom_menu_wizard. It’s quite likely that the DIV will have one, or more, other class(es) as well, such as widget_wrapper. It’s also quite likely that your theme will already have applied some styling to the DIV.

You can add your own css rules, or change what’s already there, to create the amount of space that you need, using either padding or margin.

An example might be something along the lines of…

.widget_custom_menu_wizard {margin-top:2em; margin-bottom:2em;}

If you are using a child theme, you should be able to add your css rules to that child theme’s style.css file. If you are not, and you do not wish to consider doing so, then you will need to modify your theme’s style.css … but be aware that any changes you make will be lost when/if you update the theme!

Unfortunately the widget can only use custom menus, because they are not theme-dependent. A theme can call wp_nav_menu() with a fallback option, and the callback it provides can build a menu in any fashion and with any content that it cares to. But that callback handles the entire HTML output, and the code that the CMW widget hooks into for its filtering never gets reached, so it’s not even possible to tweak CMW to handle it. Sorry!

Having more than one item in the menu marked as “current” is actually easily achievable – merely by adding the same page to the menu twice – so it’s by no means a PolyLang-specific situation. I have changed CMW (v2.0.2) to only take the first one encountered (it used to allow subsequent “current” items to override any previous, and so ended up with the last one found). This should resolve the CMW visibility problem … at least for those people that have the language-switcher at the end of their menu (which I’m hoping might be the most likely scenario).

Sure, just add some css rules. For example…

#id-of-top-ul li {display:inline-block; vertical-align:top;}
#id-of-top-ul li li {display:list-item;}

or

#id-of-top-ul li {float:left;}
#id-of-top-ul li li {float:none;}

These are just a couple of possibilities, and there are undoubtedly other (and possibly better) alternatives. They are also merely starting points : you will probably want to tweak some other settings as well (to give some horizontal separation, for example), and the relative success of any particular method may depend on your specific menu structure (particularly the number of sub-items if you use float).

Hi Ludwig.
I’m afraid this is a consequence of the update at v2.0.0 – the 2nd of the !Possible Breaker! changes noted in the Changelog. If you set the Switch to Current Item Fallback option then I think you should get the behaviour you are expecting.

What options have you set? Children of Current Item? Children of Current Root Item? Children of Current Parent Item?

I don’t understand the significance of

The menu item ‘1’ … children are being populated via the plugin on the sidebar

Does that mean that this isn’t a WordPress menu structure (maintained from Appearance/Menus in admin)? Do all these menu items show up in CMW’s “assist”?

Add these to your child theme’s stylesheet:

.widget_custom_menu_wizard li,
.widget_custom_menu_wizard li:after {
    border-bottom: 0 none !important;
}
.widget_custom_menu_wizard li a {
    text-shadow: 0 0 0 transparent !important;
}

I can’t say that its normal, however it is what your theme has set for widget lists, list items and anchors.

And yes, you can change it.

Exactly how you would go about changing it depends on your knowledge of CSS, the facilities possibly offered by your theme, and/or your understanding of WordPress. I’m guessing that you’re probably not running a child theme – which might make things a bit trickier, because if you changed the theme’s stylesheet you’d risk losing the changes if/when the theme was updated. You could investigate creating a child theme? Or you might consider a plugin that would allow you to put CSS directly into WordPress: CSS & Javascript Toolbox might be one such (there are undoubtedly others, and they may even be better suited, but that one sprang to mind)? If you need to add classes or an id to CMW, to assist with the styling, you can easily do so.

You can paste it into the content area of any post/page – place it on a line on its own.
You should also be able to paste it into something like WordPress’s Text widget.
(Themes and other plugins may well supply other content areas where shortcodes are also accepted.)

Although CMW is primarily intended as a widget, the shortcode extension can be used in exactly the same fashion and places as any other WordPress (or plugin) shortcode.

wp_nav_menu() (in includes/nav-menu-template.php) applies these filters after a menu has been ‘walked’ (ie. filtered by CMW and built as HTML list items)…

// Allow plugins to hook into the menu to add their own <li>'s
$items = apply_filters( 'wp_nav_menu_items', $items, $args );
$items = apply_filters( "wp_nav_menu_{$menu->slug}_items", $items, $args );

and after wrapping in a container (if applicable)…

$nav_menu = apply_filters( 'wp_nav_menu', $nav_menu, $args );

You can test for the CMW widget (specifically) having processed the menu by checking…

if( !empty( $args->_custom_menu_wizard ) ){ .... }

Is that the sort of information you need?

Findings so far (note that this is not a solution, more of an aide memoire for me)…

Yep, CMW can not cope with the PolyLang switcher in the menu (especially when configured for Children Of anything involving current item).

Why? …
If a page in the menu has a second language alternative then when that page is the current menu item the language-switcher entry for the page’s language also gets “current” status. This means that there are 2 items in the menu with “current” status : the page item (correctly), and the language-switcher item for the language of the current page (incorrectly – my opinion, so probably debatable).
CMW doesn’t expect more than one item to have a “current” status, so if the language-switcher item comes after the page item (in the menu order), then the language-switcher is determined as being the “current” item as far as CMW is concerned. If the page item happens to come after the language-switcher item, then the page item would be the “current” item (as far as CMW is concerned) and CMW would correctly show it as such.
Basically, when determining the “current” item, CMW takes the last item marked as “current” from the elements passed to it by WordPress. So if the language-switcher is at the bottom of the menu then it will override the page’s “current” item status. If language-switcher were at the top of the menu, then the page’s “current” item status would be recognised by CMW.

There’s a second problem with the language-switcher item in the menu, and that is that it does not consist of a single item! When the list of menu item elements reaches the widget the language-switcher menu item has become one item per language, and each of those items has the same ID!
Now this is also something that CMW does not expect, and as a consequence CMW will only show the last of the languages put out by the switcher (if you set CMW to Show All, for example, instead of Children of Current Item).
WordPress’s own Custom Menu widget copes with this non-unique ID situation slightly better than CMW, in that it does output all the language items … but it still doesn’t expect IDs to be duplicated as one can tell by adding, say, a page item as the child of the language-switcher item in the menu structure – the child page gets assigned to the first language (only) whereas one would ideally prefer it to be assigned as a child of the last language (to keep the languages together in a block).

Where does this get me? Or you?
Nowhere at the moment because, as noted at the top, this is not a solution … and I’m afraid I don’t currently have a solution, so I can only apologise for CMW’s inadequacy in this respect. I will keep looking at it, but please don’t hold your breath in expectation, because I’m not sure it’s feasibly solvable!

Thanks, I’ll investigate…

I’m sorry, but at present, No it can not.

Good, I’m glad you’re sorted. Thanks for letting me know.

Hmm … well I sincerely hope it’s not a bug, because at the moment I can’t replicate it. And I agree that changing the target of the item links is definitely not correct behaviour!

May I ask you to perform a couple of small experiments for me?

1. Could you create an instance of WordPress’s own Custom Menu widget, and give it the same menu that you have configured for CMW, please? The Custom Menu widget should reproduce the entire menu, versus CMW’s subset, and if you could just compare the navigation of the “faulty” item on CMW with the same item on the Custom Menu widget’s output I would be grateful?

2. If the navigation of the equivalent items (CMW vs. Custom Menu widget) doesn’t match, could you create a brand new instance of CMW and simply save it “as is”, ie. set to Show All, from level 1 for unlimited depth. As with the Custom Menu widget, you should get the entire menu from this new CMW instance, so could you just check the navigation of the equivalent problem item again for me please?

Many thanks for the assistance, I really appreciate it (and I apologise for needing to ask for it).