Plugin Author
wizzud
(@wizzud)
Can you show me the shortcode equivalent of the settings you are using, please?
[ If you’re using CMW as a widget, open its Assist, click in the shortcode box at the bottom, and copy-paste its content here (this assumes that the shortcode represents the Saved widget settings!) ]
Here is an example with exactly the settings i need. But also every other settings bring the same result:
[custom_menu_wizard menu=107 children_of="current" fallback_current=1 depth=1 depth_rel_current=1 flat_output=1]
I see every menu item in all depths without any filter or something.
But in the “emulator” everything is fine …
Plugin Author
wizzud
(@wizzud)
Do you have a web-accessible site that I can look at to see this in action?
Nope, it’s on my testserver 🙁
I use this theme in the payed version: http://wordpress.org/themes/mh-magazine-lite and no other related plugin, that has something to do with menu’s
Ok, found it 🙂
There is an issue with the “WordPress Access Control”, that causes it.
http://wordpress.org/plugins/wordpress-access-control/
Damn, it’s n cool plugin i would realy miss to secure some sites … 🙁
Plugin Author
wizzud
(@wizzud)
hmm …
Well I’m glad you’ve located the problem area. Looks like I’m going to have to take a peek into the WordPress Access Control plugin and see if I can determine which of us isn’t playing nice…
Plugin Author
wizzud
(@wizzud)
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
Thank you that you’ve analyzed the problem. So best way would be, to contact the WAC Team and hope that they can do something about it. I will point them to this thread, lets see what happens 🙂
Btw: Really add an paypal donate button somewhere, i bet some would donate you some money for this great plugin …