Widget Logic lets you control on which pages widgets appear using WP's conditional tags. It also adds a 'widget_content' filter.
...
...
@@ -18,11 +18,7 @@ There is also an option to add a wordpress 'widget_content' filter -- this lets
= Donations =
If you like and use Widget Logic you could consider a small donation to Cancer Research UK. I have a [JustGiving.com donation link](http://www.justgiving.com/widgetlogic_cancerresearchuk). As of December 2011 we have raised 440 UKP. I'm going to aim to have upped that to 750 UKP by the end of 2012.
= Translate =
Social Translation: [https://translate.foe-services.de](https://translate.foe-services.de)
If you like and use Widget Logic you could consider a small donation to Cancer Research UK. I have a [JustGiving.com donation link](http://www.justgiving.com/widgetlogic_cancerresearchuk). As of February 2017 we have raised 1,048.50 UKP.
== Installation ==
...
...
@@ -38,27 +34,39 @@ Aside from logic against your widgets, there are three options added to the foot
* Use 'wp_reset_query' fix -- Many features of WP, as well as the many themes and plugins out there, can mess with the conditional tags, such that is_home is NOT true on the home page. This can often be fixed with a quick wp_reset_query() statement just before the widgets are called, and this option puts that in for you rather than having to resort to code editing
* Load logic -- This option allows you to set the point in the page load at which your widget logic starts to be checked. Pre v.50 it was when the 'wp_head' trigger happened, ie during the creation of the HTML's HEAD block. Many themes didn't call wp_head, which was a problem. From v.50 it happens, by default, as early as possible, which is as soon as the plugin loads. You can now specify these 'late load' points (in chronological order):
* Load logic -- This option allows you to set the point in the page load at which your widget logic if first checked. Pre v.50 it was when the 'wp_head' trigger happened, ie during the creation of the HTML's HEAD block. Many themes didn't call wp_head, which was a problem. From v.50 it happens, by default, as early as possible, which is as soon as the plugin loads. You can now specify these 'late load' points (in chronological order):
* after the theme loads (after_setup_theme trigger)
* when all PHP loaded (wp_loaded trigger)
* after query variables set (parse_query) – this is the default
* during page header (wp_head trigger)
You may need to delay the load if your logic depends on functions defined, eg in the theme functions.php file. Conversely you may want the load early so that the widget count is calculated correctly, eg to show an alternative layour or content when a sidebar has no widgets.
* Don't cache widget logic results -- From v .58 the widget logic code should only execute once, but that might cause unexpected results with some themes, so this option is here to turn that behaviour off. (The truth/false of the code will be evaluated every time the sidebars_widgets filter is called.
== Frequently Asked Questions ==
= Why isn't it working? =
= I upgraded to Version 5.7.0 and my site's widgets now behave differently =
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'.
= What can I try if it's not working? =
Try switching to the WP default theme - if the problem goes away, there is something specific to your theme that may be interfering with the WP conditional tags.
* Switch to the default theme. If the problem goes away, your theme may be interfering with the WP conditional tags or how widgets work
* Try the `wp_reset_query` option. If your theme performs custom queries before calling the dynamic sidebar this might help.
* Try a different 'Load logic' point. Most wordpress conditional tags only work 'after query variables set', but some plugins may require evaluation earlier or later.
* The 'Evaluate widget logic more than once' option may be needed if you have to use an early 'Load logic' point.
The most common sources of problems are:
* The logic text on one of your widgets is invalid PHP
* Your theme performs custom queries before calling the dynamic sidebar -- if so, try ticking the `wp_reset_query` option.
= I'm getting errors that read like "PHP Parse error… … eval()'d code on line 1" =
= Use 'wp_reset_query' fix option isn't working properly any more =
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.)
In version 0.50 I made some fundamental changes to how Widget Logic works. The result was that the wp_reset_query was less targeted in the code. If lots of people find this problematic I will look at a general solution, but the main workround is to put wp_reset_query() into your code just before calling a dynamic sidebar.
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'.
= It's causing problems with Woo Commerce / other popular plugin =
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.
= What's this stuff in my sidebar when there are no widgets? =
...
...
@@ -72,6 +80,8 @@ There is some confusion between the [Main Page and the front page](http://codex.
= Logic using is_page() doesn't work =
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](http://codex.wordpress.org/Function_Reference/is_page#Cannot_Be_Used_Inside_The_Loop).
= How do I get a widget to appear both on a category page and on single posts within that category? =
...
...
@@ -105,82 +115,28 @@ Tighten up your definitions with PHPs 'logical AND' &&, for example:
== Screenshots ==
1. The 'Widget logic' field at work in standard widgets.
2. The `widget_content` filter, `wp_reset_query` option and 'load logic point' options are at the foot of the widget admin page. You can also export and import your site's WL options for safe-keeping.
== Writing Logic Code ==
The text in the 'Widget logic' field can be full PHP code and should return 'true' when you need the widget to appear. If there is no 'return' in the text, an implicit 'return' is added to the start and a ';' is added on the end. (This is just to make single statements like is_home() more convenient.)
= The Basics =
Make good use of [WP's own conditional tags](http://codex.wordpress.org/Conditional_Tags). You can vary and combine code using:
* `!` (NOT) to **reverse** the logic, eg `!is_home()` is TRUE when this is NOT the home page.
* `||` (OR) to **combine** conditions. `X OR Y` is TRUE when either X is true or Y is true.
* `&&` (AND) to make conditions **more specific**. `X AND Y` is TRUE when both X is true and Y is true.
2. The plugin options are at the foot of the usual widget admin page… `widget_content` filter, `wp_reset_query` option, 'load logic point' and 'evaluate more than once'. You can also export and import your site's WL options as a plain text file for a quick backup/restore and to help troubleshoot issues.
There are lots of great code examples on the WP forums, and on WP sites across the net. But the WP Codex is also full of good examples to adapt, such as [Test if post is in a descendent category](http://codex.wordpress.org/Template_Tags/in_category#Testing_if_a_post_is_in_a_descendant_category).
= Examples =
* `is_home()` -- just the main blog page
* `!is_page('about')` -- everywhere EXCEPT this specific WP 'page'
* `!is_user_logged_in()` -- shown when a user is not logged in
* `is_category(array(5,9,10,11))` -- category page of one of the given category IDs
* `is_single() && in_category('baked-goods')` -- single post that's in the category with this slug
* `current_user_can('level_10')` -- admin only widget
* `strpos($_SERVER['HTTP_REFERER'], "google.com")!=false` -- widget to show when clicked through from a google search
* `is_category() && in_array($cat, get_term_children( 5, 'category'))` -- category page that's a descendent of category 5
* `global $post; return (in_array(77,get_post_ancestors($post)));` -- WP page that is a child of page 77
* `global $post; return (is_page('home') || ($post->post_parent=="13"));` -- home page OR the page that's a child of page 13
Note the extra ';' on the end where there is an explicit 'return'.
== The 'widget_logic_eval_override' filter ==
Before the Widget Logic code is evaluated for each widget, the text of the Widget Logic code is passed through this filter. If the filter returns a BOOLEAN result, this is used instead to determine if the widget is visible. Return TRUE for visible.
== Changelog ==
== The 'widget_content' filter ==
= 5.7.2 =
Removed conflicts with outdated WP versions.
When this option is active (tick the option tickbox at the foot of the widget admin page) you can modify the text displayed by ANY widget from your own theme's functions.php file. Hook into the filter with:
Fixed the settings form not being saved settings under some circumstances.
where `[priority]` is the optional priority parameter for the [add_filter](http://codex.wordpress.org/Function_Reference/add_filter) function. The filter function can take a second parameter (if you provde that last parameter '2') like this:
Added a setting to show logic code errors for admins (turned off by default).
Fixed the issue with quotes in error messages on some WP installations.
The second parameter ($widget_id) can be used to target specific widgets if needed.
= 5.7.0 =
Fixed PHP 7 compatibility issue.
A [Wordpress filter function](http://codex.wordpress.org/Plugin_API#Filters) 'takes as input the unmodified data, and returns modified data' which means that widget_content filters are provided with the raw HTML output by the widget, and you are then free to return something else entirely:
Fixed a conflict with the latest WPML plugin.
= Example filters =
A new default load logic point attached to the action 'parse_query'. By default the widget logic is only evaluated once.
{ return $content."<PRE>THIS APPEARS AFTER EVERY WIDGET</PRE>";
}`
I was motivated to make this filter in order to render all widget titles with the excellent [ttftitles plugin](http://templature.com/2007/10/18/ttftitles-wordpress-plugin/) like this:
People often ask for a way to give widgets alternating styles. This filter inserts widget_style_a/widget_style_b into the class="widget ..." text usually found in a widget's main definition:
Small fixes to satisfy some define('WP_DEBUG', true) errors
...
...
@@ -198,7 +154,7 @@ Removed a WP 3.1+ function call, hopefully making it 2.8 compatible again.
A little 'trim' of WL code to stop "syntax error, unexpected ')'" errors, which could occur if your WL was just a single space. Thanks to https://twitter.com/chrisjean for pointing this out.
Translation support! Thanks to Foe Services Labs http://wordpress.org/support/profile/cfoellmann for the work on this and the German translation files.
Translation support! Thanks to Foe Services Labs http://wordpress.org/support/profile/cfoellmann for the work on this and the German Social Translation
Added a 'widget_logic_eval_override' filter. This allows advanced users to bypass EVAL with a function of their own.
...
...
@@ -217,7 +173,7 @@ For the first time since this started on WP 2.3, I've rewritten how the core wid
It now uses the 'sidebars_widgets' filter (as it should have done when that was
introduced in WP2.8 by the look of it). The upshot is that is_active_sidebar should behave properly.
Widget callbacks only get intercepted if the 'widget_content' filter is activated, and much more briefly. (A widget's 'callback' is rewired within the 'dynamic_sidebar' function just before the widget is called, by the 'dynamic_sidebar_param' filter, and is restored when the callback function is invoked.)
Widget callbacks only get intercepted if the 'widget_content' filter is activated, and much more briefly. (A widget's 'callback' is rewired within the 'dynamic_sidebar' function just before the widget is called, by the 'dynamic_sidebar_param' filter, and is restored when the callback function is invoked.)
= 0.48 =
Kill some poor coding practices that throws debug notices - thanks to John James Jacoby.
...
...
@@ -244,8 +200,85 @@ Brings WP 2.5 compatibility. I am trying to make it back compatible. If you have
Last WP 2.3 only version
== Upgrade Notice ==
= 0.58 =
Important change to the default of when your Widget Logic is evaluated. It is now on the "parse_query" action, and just once. Those defaults can be overridden.
= 0.46 =
Required with WP2.8 cos of changes in Widget admin AJAX
