Widget Logic / Widget Context replacing callback

Would you mind giving a slightly longer explanation of the issue. cheers.

@digitalnature:

Thank you so much for your post! I had issues with widget logic and a Yootheme theme where some widgets looked strange because after I installed Widget Logic.

You are right. The replacement of the whole callback array was the cause. So i fixed this by replacing the callback property again after Widget Logic does it evals…

like this:

$wp_registered_widgets[$id]['callback'] = $callback;
call_user_func_array($callback,params); // if so callback with original params!

This solved my theme issues!

I think i understand nk111’s point, but I’m still not at all clear on the original post here (‘many properties missing’?), and would love to know what I’m missing.

re nk111, what cause is there for restoring the callback property – and where are you doing it – in widget logic at the end of the widget_logic_redirected_callback function?

NB, i’ve just been looking at the (wp-includes/widgets.php) current dynamic_sidebar function and I think I see a new cleaner way to do widget logic using the dynamic_sidebar_params filter – which I’m SURE didn’t exist when I first started out!

The original poster meant that the callback property of the widgets gets replaced. Therefore other plugins which want to access that property (which is an array which doesn’t only store the callback function!) might fail afterwards.

Exactly that happend to me. My themes widgets did not work properly with widget logic activated.

So thats why i restore the callback property after widgets logics condition check and everything works!

And yes… this should be done in widget-logic-redirected-callback.

Well I ran into this issue when developing the same type of functionality that these plugins do.

And I didn’t need to override any callbacks. Just hook your widget visibility checking function to the widget_display_callback filter, and return false if the widget should not be visible on the current page, the $instance array otherwise.

Your forms go inside in_widget_form (and widget_update_callback for updating your options).

I don’t see why do you have to interfere with the widget properties, like the callback.

wow. widget_display_callback ! when did that turn up?!

holy, I am learning a lot here thanks – i’ve certainly been letting the grass grow under my feet on this.

“which is an array which doesn’t only store the callback function!”

really, i thought it could only be a function or an array of (object, method name).

anyway, actual work is all but over, and a new simpler widget logic using the widget_display_callback filter is in the offing!

hmm, maybe I’m getting ahead of myself. It looks like there are old and new style coded widgets, and that the old-style that don’t use the WP_Widget class won’t touch that filter.

however I think I can switch to using dynamic_sidebar_params instead of wp_head to sub in the intercepted callback, and then replace it shortly after, which should minimise WL’s interference.

looking good. got rid of the reliance on wp_head, and the code only changes the callback property for the duration of the dynamic_sidebar call. when i’ve done a bit more testing, updated the docs and remembered the SVN stuff I’ll try an update of the repository.

thanks all

i’ve actually overhauled the code a fair bit now so the callback data is changed only very quickly and also things like is_active_sidebar should work properly to show empty sidebars as i’ve moved to using the ‘sidebars_widgets’ filter instead. which i should have moved to doing years ago.

need to test it on 3.3 now really though. so give me some time…

FWIW if anyone is still looking at this, i’ve updated the development version to 0.50 if anyone wants to check it out

I’ll try to test it a bit more myself before commiting it as the stable current version

I think I’d be interested if it’s still in the pipes…

i already committed this, and the latest stable version is v.51 out now. is_active_sidebar works properly and it has a much reduced callback interception that is only active when the content filter is used too.

alanft, is your v.51 working with wp 3.3.1/3.3.2? I would be interested in trying this out and see if I can get it to work on some sites I am work on that use widget context, but these sites need to get up dated and I cannot cause of the widget context plugin.

Any help on fixing this would be much appreciated.

3.3.1 i’m happy with (and the user compatibility widget says 50 v 2), and I’ve just updated the home site i test with on 3.3.2 and it’s working fine.

It’s worth mentioning there’s a dev version to test too with a couple of important additions in it. I’ve got no way to ask people to beta test that for me. So i’ll probably just commit that soon, as it works fine for me.

i just seen you are the widget logic developer lol, I am a dope. Your name looked familiar too lol.