wizzud

Ok.
1. What settings are you using? (The shortcode equivalent?)
2. Is there any page for which that CMW instance does display? And is it web-accessible, so I can take a look?
3. Is there more than one menu element in this custom menu that points to the Home Page?
4. If you set up a CMW widget with its default settings (for the custom menu in question) ie. Level 1 for unlimited Depth, does it display on the Home Page? And when you Inspect the menu element that points to the Home Page, does it show as being the current item (has a class of current-menu-item)?

Hi Shawn.
I think what you’re asking for is a sort of two-scenario case, as in : if current item is in the menu show this set of items; if it’s not, then show this other set of (possibly) completely different items.

Unfortunately, CWM does not currently provide that dual-scenario functionality … although I must admit that I have started looking into it. I have 2 possibilities :
a. create a new Standby section, which has limited filters and only comes into effect when the main Filters fail to return any items, or
b. create a specific Current Item sub-section within the main Filters section.
Both approaches add further complexity to the settings, which I’m not sure that CMW (or more specifically, it’s users) can take, and neither is currently particularly clear in terms of what it provides or when it provides it. If I can keep it logical and ergonomically sound then I’ll seriously consider adding it, but I haven’t made my mind up yet.
Sorry.

…where would I put this? Inside the short code?

No, CMW does not provide any facility for specifying additional CSS rules. As to where you should put it … well, there are a number of possibilities:

• your theme may provide the facility for you to enter your own CSS rules as part of its custom settings; some themes do, most don’t
• if you are running a child theme, then you could edit that child’s stylesheet and enter the rules there
• there are plugins such as the CSS & Javascript Toolbox (and undoubtedly others similar) that provide the ability to enter your own CSS rules, above and beyond those of your theme
• lastly, you could modify your theme’s stylesheet, but I do not recommend this because any update to the theme would wipe out your customisations!

I assume 24 is the <id-of-top> referred to…

No, it isn’t. The 24 is the internal-to-WordPress id of the custom menu that the widget is configured to filter; this is not the same as the id attribute that WordPress assigns to the UL (or OL in your case) HTML element that gets output to the page. WordPress assigns a unique id of menu-{menu slug}[-#], where {menu slug} is the “name” of the custom menu being used, and [-#] is an optional, incremental number that ensures uniqueness when there are multiple occurrences of similar items being output on the one page. So, if your custom menu is called, say, “my custom menu”, then the first occurrence might have an id of menu-my-custom-menu, the 2nd would be menu-my-custom-menu-1, and the 3rd would be menu-my-custom-menu-2, etc.
There is a potential problem with using the WordPress-generated id though : if you subsequently insert another instance in front your original instance – the one you provide all the custom styling for – then the original instance (now the 2nd instance) will change its id from menu-my-custom-menu to menu-my-custom-menu-1 … which will throw out your styling. You might be better off providing your own unique class for either the widget itself, the container, or the list element (UL or OL), via the CMW settings. (Using a class rather than an id makes your CSS styles re-usable for other instances).

All the main browsers nowadays provide Developer facilities which enable you to play around with a page’s HTML & styling (to some degree, and with varying ease), and I would suggest that that is the place to start (personally, I could not do without Firefox’s Firebug extension). You can try out different CSS rules without having to code anything into WordPress, and only when you are happy with the results do you then have to make a decision as to how to implement them.

No problem.
Seems like you’ve definitely got some rogue javascript floating round somewhere, and I hope you manage to track it down and fix it.
I know your problem isn’t quite fixed yet, but I’m going to mark this as resolved since it appears not be related to CMW.
Good luck…

Hi.
Unfortunately, I suspect that what you’re asking is not currently possible with CMW.

According to

…all parent pages display all the time…

I believe you would like the root(?) items to be permanently shown – regardless of the current page/item. This is certainly possible with CMW, using the Level option, with a For Depth.
However, you also want conditional display of further items depending on whether the current item then happens to fall within scope of the displayed root items, and this is not available with the Level option.

The only conditionality available with the Level and Items primary options is a boolean (on/off) check for the existence of current item within scope; conditional modification of the specified subset items is not an option. If this is what is required, the only way to achieve it with CMW is to set up the entire permanent subset of items, and then use CSS to conditionally hide any sub-items unless they fall on the current path or below the current item.

If I have made a wrong assumption about the meaning of “display all the time”, then I apologise. (For example, if the widget was required to only produce output when current item was within scope of the root items, then Yes, that is achievable with CMW; but your post doesn’t read like that.)

Thank you for letting me know, and Yes, from what I have been able to determine from their documentation I suspect that you are correct in guessing that it’s probably something to do with the way menus are handled by WPML.
I am trying to get in touch with the WPML team to determine whether there’s anything I can do about it …

Hi.
When you install CMW : instead of immediately activating it (from the update.php page), please return to the plugins page and activate from there.

The problem is known to me, and it’s to do with the difference between how update determines the main plugin file versus how plugins determines it. I have a fix for this which will be released very shortly, but meantime please be assured that the main CMW file headers are intact, complete, and accurate.

Apologies for the hassle.

Sorry, I was writing while you had solved …
Glad you’re sorted.