Widget Logic and KC Widget Enhancements conflict

Yes, this is a known issue and I’ve mentioned it in the release announcement on my blog (I will add this to the plugin description on the next update).

I’m working on my own ‘widget logic’ implementation and hopefully I can include it in the next plugin update.

I, like many of us, have been scratching my now bald head trying to find a solution that will allow Widget Logic to play nicely with ANY plug in that adds Custom Class/ID to Widgets. I tried asking Andy (ZigWidgetClass) and got impatient waiting for a response (yes, he answered within a decent amount of time <12 hours, being a coder and impatient anyway, I dove in looking to find the problem). He and I both discovered that the issue is caused by the fact that WL needs to rewrite the ['callback'] array in order to function in the way that it does and in doing so keeps any other custom widget class plugin from visibly working.
No biggie, just need to test to see if Widget Logic is active then if it is use the ['callback_wl_redirect'] instead of ['callback'].
Since Andy’s fix was shorter and cleaner than mine I will show you his solution and all thanks should go to him:
This is from his plugin; ZigWidgetClass
This:
$option_name = get_option($widget['callback'][0]->option_name);
Gets replaced with this:
if (!($widget-logic-status = $widget['callback'][0]->option_name)) $widget-logic-status = $widget['callback_wl_redirect'][0]->option_name; # because the Widget Logic plugin changes this array $option_name = get_option($widget-logic-status);
Notice that depending on which plugin you have chosen to ad custom class/id’s to your widgets the $widget variable could be $widget_obj or something along those lines. You might find it easier to Search the plugin code for ['callback'][0]->option_name) as this should be standard.
ZigWidgetClass has already update the plugin to work with Widget Logic.
KC Widget Enhancements –

Yes, this is a known issue and I’ve mentioned it in the release announcement on my blog (I will add this to the plugin description on the next update).

I’m working on my own ‘widget logic’ implementation and hopefully I can include it in the next plugin update.

If you are using a different plugin than the two mentioned then you should alert them to this.
As an aside, @kucrut I am interested in seeing a version of Widget Logic that doesn’t break other plugins.

@hallmarc

Thanks for the info. I actually have a working version my plugin with ‘widget logic’ builtin. However, I don’t feel comfortable releasing it to the public because it’s using eval() (just like the original Widget Logic plugin). A commenter on my blog said that I shouldn’t worry about that because the widget settings can only be modified by admins and they should know what they’re doing, but alas…

Anyways,
My implementation of the logic will be a little more complicated to code but should be easier and safer for the site admins since they won’t need to enter WordPress’ conditional tags. I’m still working on my KC Setting plugin improvement (making it easy to create settings without editing any file) and should start the work on KC Widgets Enhancements when it’s done.

Oh, I forgot to mention…
I will add the check for Widget Logic in the next update. Thanks for the code ??