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