wizzud

Right …
Apologies for the delay, it’s taken me a while to track down what’s happening.
Unfortunately, the culprit is your theme, Gridiculous.
It hooks into the wp_nav_menu_args filter – which is applied by wp_nav_menu(), the function used to create any menu – and if a menu has been allocated to the theme’s “primary” location (which is a perfectly reasonable thing to do), and the required depth of the menu is not set to 1, then the theme substitutes its own Walker (code that determines what it displayed and how).
The apparent intention is to provide items that have sub-items with some sort of indicator (I haven’t investigated far enough to determine exactly what it does), but the problem is that it wipes out CMW’s own custom Walker, so you never reach any of CMW’s filter processing.

The code in question (in the Gridiculous theme’s functions.php) is:

add_filter( 'wp_nav_menu_args', 'bavotasan_nav_menu_args' );
/**
 * Set our new walker only if a menu is assigned and a child theme hasn't modified it to one level deep
 *
 * This function is attached to the 'wp_nav_menu_args' filter hook.
 *
 * @author Kirk Wight <http://kwight.ca/adding-a-sub-menu-indicator-to-parent-menu-items/>
 * @since 1.0.8
 */
function bavotasan_nav_menu_args( $args ) {
    if ( 1 !== $args[ 'depth' ] && has_nav_menu( 'primary' ) )
        $args[ 'walker' ] = new Bavotasan_Page_Navigation_Walker;

    return $args;
}

I don’t think there’s anything I can do (with CMW) because in the general hierarchy of things, a theme outranks a plugin. While it is possible to circumvent Gridiculous’ filter, it would require configuring the CMW instance for a Depth of 1, then coding another filter (one of CMW’s own) to set the Depth back to what you really wanted it to be. That’s just not practical. the other possibility is to run a child theme that removes that filter, but that depends on whether or not a have a child theme, and whether or not you really want to completely remove the effect that filter provides.

My suggestion would be that you contact the Gridiculous authors and give them the problem? Basically, it doesn’t only affect CMW, but any other plugin that provides similar manipulation of custom menus (using wp_nav_menu()).
I’m sorry I can’t be of more help.

May I ask…
What version of WordPress are you running?
What other plugins do you have installed/activated?

v3.1.0 has just been released, which might resolve (some of?) your problems…

• Fixes the problem of paginated Home Page.
• Adds a “last resort” determination of current menu item : it’s in the Fallbacks section and has to be specifically enabled, but bear in mind the limitations discussed above, whereby there still has to be something in the menu that WordPress can designate as a parent.
• Now provides a (limited) dual-scenario capability, for occasions where one set of options is not quite sufficient.

I’m sorry but unless I’m looking at the wrong page – http://keflico.com/ekstranet/ , yes? – then I can’t see the problem.

Your widget and shortcode have essentially the same settings : children of current branch. The fallback is slightly different, but since there are children (only 1, but that’s enough!), the fallback doesn’t come into play. Start mode “level” makes no difference, and they both have it anyway.

So, I assume that Ekstranet (the current page) has a single child, Gruppe1: I can see that child (and only that child) in both the content’s shortcode output and the sidebar’s widget output. If I navigate to Gruppe1, the sidebar widget shows me Gruppe1 (it has fallen back to Current, ie. Gruppe1, because Gruppe1 has no kids), and there’s no shortcode output (presumably because it’s not on the page).

Obviously I am missing something, because this seems to be exactly what I would expect to see. What do you think should be showing, and where?

Sorry, I misunderstood (again).

CMW only looks for menu items marked, by WordPress, as being the current menu item. When you go into a post – for which there is no specific related entry in your custom menu – then there is no menu item available to be marked as the current item. With no apparent current item, a CMW widget configured to depend on the presence of a current item will produce no output.

What WordPress does do is mark a Category menu item is being current_item_parent if a post is being displayed that belongs to that category. This effectively means that the menu has an item that is marked as the parent of the current item … without actually having a current item to be parent of (if you see what I mean).
I suppose it might be possible to cope with that scenario as well, maybe using it as a last resort if CMW can’t determine a “current item” by any other means. But I still have the restriction that CMW can only ever have one “current item”, yet a post can belong to more than one category, each of which could have a related item in the custom menu : CMW would only be able to use the first one encountered (as it currently does with all the other -prioritised – possibilities for “current item”).
However, even that solution (if it were available) may not suit you, because it would still require that a Category menu item exists for any category to which a post belongs, and I’m not sure that’s case with your current menu.

Anyway, I will ponder upon it for the next release. But meantime, once again, CMW seems to fall short of your requirements, and I don’t have a quick fix. Sorry.

Afterthought : Actually there is one possibility, and that’s to hook into WordPress’s wp_nav_menu_objects filter and set whatever item you like as being “current”. [Filter is run immediately before calling walk_nav_menu_tree(), from within wp_nav_menu(); code in wp-includes/nav-menu-template.php]
You’d probably want to check for it being a CMW widget instance (the presence of $args->_custom_menu_wizard), and possibly even for specific configurations of the widget (assign a unique class). You could zip through the items array searching for an item marked as “current”, falling back on setting the Home Page link as being current if you can’t find anything else? Of course this requires a bit of coding know-how, and preferably a child theme to place the code in …

Done a bit of checking…

Scenario :
Front Page is set to display Your latest posts (in Settings, Reading) and the number of posts triggers pagination. Also, the custom menu has a Link menu item that points to the Home Page (let’s call it the Home-Page-Link).

Now, when you land on the Home Page, WordPress sets a current property on the Home-Page-Link and gives it a class of “current-menu-item” (among other things).
However, when you then navigate to a paginated page – such as home/page/2/, home/page/3/, etc – WordPress still applies the “current-menu-item” class to Home-Page-Link, but does not set its current property!
Since CMW currently only uses the menu item’s current property to determine the “current item”, the paginated page gets missed as actually still being part of the “Home Page”!

Technically, I not sure whether this is a bug in WordPress or in CMW, however I will put a work-around into CMW for the next release (specifically for this scenario). Meantime, I’m sorry that it doesn’t currently do what you need it to, but I’m afraid I don’t have a quick fix either.

Thank you!