Widget Logic lets you control on which pages widgets appear using WP's conditional tags. It also adds a 'widget_content' filter.
There was an important change to how your Widget Logic code is evaluated. There is a new default 'Load logic' point of 'after query variables set'. For most people this should be better, but you could try reverting to the old default 'when plugin starts'.
wp_reset_queryoption. If your theme performs custom queries before calling the dynamic sidebar this might help.
You have a PHP syntax error in one of your widget's Widget Logic fields. Review them for errors. You might find it easiest to check by using 'Export options' and reading the code there (Though be aware that single and double quotes are escaped with multiple backslash characters.)
If you are having trouble finding the syntax error, a simple troubleshooting method is to use 'Export options' to keep a copy and then blank each Widget Logic field in turn until the problem goes. Once you've identified the problematic code, you can restore the rest with 'Import options'.
This is often, not always, fixed by trying the different 'Load Logic' options. The 'after query variables set' option looks like it might be a better default, try it.
Since v .50 the widget logic code runs such that when dynamic_sidebar is called in a theme's code it will 'return false' if no widgets are present. In such cases many themes are coded to put in some default sidebar text in place of widgets, which is what you are seeing.
Your options, if you want this default sidebar content gone, are to either edit the theme, or as a work around, add an empty text widget (no title, no content) to the end of the sidebar's widget list.
There is some confusion between the Main Page and the front page. If you want a widget on your 'front page' whether that is a static page or a set of posts, use is_front_page(). If it is a page using is_page(x) does not work. If your 'front page' is a page and not a series of posts, you can still use is_home() to get widgets on that main posts page (as defined in Admin > Settings > Reading).
I believe this is fixed in 5.7.0. Let me know if that is not the case.
If your theme calls the sidebar after the loop you should find that the wp_reset_query option fixes things. This problem is explained on the is_page codex page.
Take care with your conditional tags. There is both an
is_category tag. One is used to tell if the 'current' post is IN a category, and the other is used to tell if the page showing IS for that category (same goes for tags etc). What you want is the case when:
(this page IS category X) OR (this is a single post AND this post is IN category X)
which in proper PHP is:
is_category(X) || (is_single() && in_category(X))
Have a go at it yourself first. Check out the 'Writing Logic Code' section under Other Notes.
This is sort of deliberate. I originally wrote it to be as flexible as possible with the thought of writing a drag'n'drop UI at some point. I never got round to it, because (I'm lazy and) I couldn't make it both look nice and let you fall back to 'pure code' (for the possibilities harder to cater for in a UI).
The plugin Widget Context presents a nice UI and has a neat 'URL matching' function too.
It might be that your theme performs custom queries before calling the sidebar. Try the
Alternatively you may have not defined your logic tightly enough. For example when the sidebar is being processed, in_category('cheese') will be true if the last post on an archive page is in the 'cheese' category.
Tighten up your definitions with PHPs 'logical AND' &&, for example:
is_single() && in_category('cheese')
Requires: 3.0 or higher
Compatible up to: 4.7.2
Last Updated: 2 weeks ago
Active Installs: 300,000+
8 of 16 support threads in the last two months have been marked resolved.
Got something to say? Need help?