Update for the problem if anyone can still help:
Ignore the above description of the problem, this is the situation below:
I have a very weird problem happening. I have a custom function called ‘is_my_ancestor_of (x)’, and it simply checks the current post categories ancestors to see if they are equal to x.
I then use the function in your widget logic box in 4 widgets in my sidebar, e.g. is_my_ancestor_of (15) etc. Inside my function i added an echo statement to say ‘i am testing for x’.
When my web page is called, the echo statement for all 4 widgets is called over and over throughout the page, in the navigation menu, in the sidebar, and in the footer, basically wherever there are widgets and multiple times for those widgets.
Does anyone know why widget logic would be running so many times per page/widgets etc when it really should be seen to be called 4 times ??
thank you
The main hook is the filter ‘sidebars_widgets’ which is mainly called in the ‘wp_get_sidebars_widgets’ function, and that is called in a number of other functions, eg is_active_sidebar(), dynamic_sidebar() and so on.
Hi Alan, thanks for the explanation, much appreciated.
So if i have 15 widgets on a page, and only one of them needs to run a piece of widget logic, isn’t calling widget logic unnecessarily 14 times a massive bug ? … There must be a different and more specific hook to use, or at the very least, not run Widget Logic if the widget logic field is blank?
A bug this big is detrimental to website performance, and is something that needs a solution based on the huge number of people who use your plugin?
I’m open to suggestions to improve things! I try to keep WL to a minimal “profile” in code of course.
But eg if you have 15 widgets on a page, it’s not all of widget logic’s plugin code runs 15 times, and if you only have code in one widget, then that code will run once if your site just calls dynamic_sidebar() once.
Some sites do more, having multiple sidebars or calling is_active_sidebar() which needs to enumerate the widgets (which in turn needs to filter out inactive widgets).
In the case of multiple sidebars it’s not immediately obvious how to minimise the repeat calls – the dynamic_sidebar routine calls wp_get_sidebars_widgets() with no parameters and that just calls the filter to act on all widgets on all sidebars.
In the worst case where WL plugin is active and all widgets have no actual WL code in them, the actual executing code in the plugin is very minimal
(In case you look back in)
BTW, I have been looking into this! You’ve set me wondering if executing just once might fix a lot of the quirks people see in widget logic. And it occurred to me that of course though I can’t stop the filter being called multiple times that it could cache the results the first time.
Might toy with a ‘Don’t cache the logic’ option in case that breaks some people’s sites
So, thanks for making me think!
actually tried updating the code to accommodate this change in the ‘development’ version here
http://wordpress.org/plugins/widget-logic/developers/
if anyone is interested in trying that out
Hi Alan
Glad to have been of help! … Isn’t it possible to just call this when a widget is being displayed ? … i.e. I don’t understand why is there an issue at all with it being called multiple times, isn’t there a more appropriate hook that just gets called once if a sidebar is actually being displayed AND it has a widget logic statement attached to it ??
The new dev version doesn’t call your code repeatedly. If you give it a try I’d love to know how you find it.
I’ve just arranged that when the filter is called it only does the calculation the first time, and then on subsequent calls it goes “I already worked this out, here’s what I said last time”
I don’t think there is a better hook, for good or bad. Like I said above, it’s hard to avoid the filter being called multiple times. “dynamic_sidebar” calls the filter regardless of which sidebar is called (and without passing that information on), so I just have to make the filter a little cleverer. And I have you to thank for the nudge to do that. And at the same time it made me realise that the FIRST time that’s called should default to a different point in the WP process, and I’m hoping that clears up a number of related problems I’ve seen people trying to deal with.
