wizzud

Maybe, under Inclusions, set Branch Ancestors : to level 1 (root) ?

Yes, there’s an entry in the FAQs that might help.

Just a suggestion…

.h-right .menu-widget > li {
    margin-left: 0;
}

If that’s not enough – and I suspect it won’t be – then you might need to add an override that halves (or more) the 20px left margins for those top widgets?…

.h-right > div {
    margin-left: 10px;
}

Unfortunately I think that’s down to WordPress. CMW doesn’t change that sort of item detail (and definitely not underlying post details – it doesn’t care!), it merely filters the items and then passes the filtered set through to WordPress’s nav walker class for output.

There are several places where WordPress uses that format if it can’t find a post title, one of which is the wp_setup_nav_menu_item() function (in wp-includes/nav-menu.php).
A quick check would be to (temporarily) add WordPress’s own Custom Menu widget into the sidebar and see what that displays (for the same menu as CMW is configured for). If that also displays “#nn (no title)” titles then you need to check your menu and posts, and possibly any language plugins?

Sorry I can’t be of more help.

Do you have a web-accessible page I can go to to see this problem? (eg. the “Category XA” page?)

What is the shortcode equivalent of your current configuration, please?

Does the “assist” correctly simulate the effect you’re after, or does it exhibit the same incorrect results as stated above (ie. when Category XA is the current item, does the “assist” show Category XA’s children as output or not)?

Are all my assumptions (in the previous response) correct?

When Category XA is the current page – and Category XA is shown in the CMW menu – does the Category XA item (the LI element) in the menu have any of the following classes?
– current-menu-item
– cmw-current-item
– cmw-has-submenu
– cmw-menu-item-had-children

Are you up-to-date with both WordPress and CMW (versions 4.5 & 3.3.0 respectively)?

Start with…

Primary Filter
– Branch: Current Item
Secondary Filter
– Starting at: 2 (assuming Category X is at root level)
Qualifier
– Current Item is in: Secondary Filter

(= “for any non-root current item, show the full current item branch from level 2 downwards”)

This makes an assumption that whatever you want to show for when children for Category X are the current item, you also want similar for children of Category Y (and any other root item on the menu). It also assumes that when a root level item (such as Category X appears to be) is the current item then nothing gets shown.

It’s quite likely that these assumptions are inaccurate, in which case you will have to adjust something (depending on which assumption is incorrect, what else you want to show and when, and what your menu really looks like).

Hmm…
Is there anything in your site’s error_log that might give any indication as to a possible problem?
If you (temporarily) enable WP_DEBUG and try accessing the widgets page, do you get any errors then?
If you (temporarily) switch to a WordPress theme – such as TwentySixteen or TwentyFifteen – do you still have the problem?

Newspaper is a commercial theme, so I can’t just install it and test CMW against things like their Smart Sidebar functionality (which I assume was involved in creating your “new sidebar”).

I’ve updated CMW (v3.2.6) with a small change that adds a cmw-current-item class to the menu item that CMW is using as its “current menu item”.

Note that this does not affect any class that WordPress assigns – which should include the current-menu-item class – and it merely indicates which of the output items (if any) CMW decided to use (internally) as its current item.

Ah!
Right, I owe you a couple of apologies:

Firstly, for the typo – which you figured out anyway : cmw-has-submneu should have been cmw-has-submenu!

Secondly, having looked back at the CMW code, I misspoke when I said that CMW doesn’t do anything with the menu-item-has-children class : it does! It removes that class if the item in question no longer has children in the filtered output.

Lastly, I misunderstood exactly what it was that you were trying to do : you want the top level root items (of the displayed menu) to indicate that they used to have child items, regardless of whether or not they still have child items in the currently displayed menu.

With regard to the second point : the menu-item-has-children class is relevant to the output, not the source of data from which the output was constructed. As such, if the output menu item is childless then it should not have that class. That won’t change.

However, I have just submitted an update – version 3.2.5 – that puts a cmw-menu-item-had-submenu class on any item that originally had children, regardless of whether or not it still has children in the currently displayed menu.
If you update CMW to 3.2.5 and try using li.cmw-menu-item-had-submenu instead … ?

Your Mantra theme is supplying the CSS (approx. line 319 of style.css)…

.entry-content ul > li {
    background: rgba(0, 0, 0, 0) url("images/bullet.png") no-repeat scroll left 10px;
    padding-left: 20px;
}

The reason that the bullet is only showing on the 1st LI is because you have unbalanced I (italic) tags in your H4, which is causing double I tags to be placed around the 2nd & 3rd LI’s such that they’re no longer direct descendants of the parent UL.

To remove it, change/override your CSS. I would suggest you also validate & correct your page’s HTML.

The menu-item-has-children class is set by WordPress, and CMW doesn’t do anything with it. CMW applies its own class to items it believes (according to its configured filters) are parents – cmw-has-submneu – so maybe you could try targeting li.cmw-has-submneu instead?
(If you use your browser’s Developer tools to Inspect the items of the output menu, you should be able to see the classes that each element has been given; any that begin with cmw- have been added by CMW; any others are outside of CMW’s scope.)

Yes, if you create a menu with an appropriate page structure, for use with CMW’s Branch=Current Item setting.

My apologies if any part of the description or documentation lead you to believe that this plugin provides control over a menu’s appearance : it doesn’t. I obviously need a blunt, up-front statement to that effect, and I will sort that out.

CMW allows you to filter menu content, not change what it looks like.

…ridiculous and complicated…

Yes, it’s quite complex. I’ve tried (possibly not very successfully) to make it as friendly as possible, but a lot of people want to be able to do a lot of different things with it, and that leads to a large number of options. And Yes, to one specific user who only needs to set 1 option, then all the other options might be considered “ridiculous” However, if there are 20,000 users, each setting one option – but not necessarily the same one! – then perhaps it’s only the option(s) that nobody ever sets that could be referred to as “ridiculous”?

…came out just like the … custom menu that WordPress provides.

Yes, I’m afraid it would, especially if the only option that was set was which menu to use.

…complete waste of time.

Sorry about that. I can’t give you your time back, but for future users I’ll try to be clearer about what the plugin won’t do.

What does this do that is not already done?

Hmmm… Given that we agree that its quite complicated, I would have hoped for an answer of “quite a lot”. However, I can see that it depends on your point of view : if you need it produce the same output as another plugin but with different styling, then Yes, this plugin will do Nothing for you!

Thank you for the review. It’s been informative, and I will tweak the plugin’s description as a result. Sorry it didn’t fit your needs.

Sure. FILTERS settings (default unless specified)…

Primary Filter
– Branch : Current Item
Secondary Filter
– For Depth : 2 levels
Inclusions
– Branch Ancestors : to level 1 (root)
– Branch Siblings : checked

eg.

[cmwizard menu=179 branch=current depth=2 ancestors=1 siblings=1 flat_output=1/]

Umm … I suspect not.

CMW doesn’t know about pages or post, just menu items. That’s all it works with. As such, there is no condition for being on a certain page; the condition it can work to is for a menu item being identified as the “current item”, which not the same thing.

Also, although you don’t make it clear, I get the impression that you might be talking about the main navigation menu – which is usually produced by your theme. If that’s the case, then it is unlikely to be either a widget or a shortcode, so considering CMW as a replacement may not be practical? On the other hand, if you’re talking about a secondary menu – say, in a sidebar – then CMW could be used, but I still don’t think it would be able to do what you want.

If your menu doesn’t have visible indications of the existence of a sub-menu, then you might be able to achieve what you’re after with some CSS? On the home page, the BODY tag often has a class of ‘home’, so you could display:none on sub-menu ULs within body.home?