I cannot find the Visibility controls on a widget. Where are they?
In two different places, depending on the widget:
- A block (Paragraph, Categories, Image…): in the Visibility panel of the right sidebar.
- A classic widget shown as a legacy widget: in a Visibility button at the bottom of the widget itself , under its own fields. Not in the right sidebar.
If the right sidebar of a classic widget says so and you still see no button, check whether Jetpack Widget Visibility is active, because then Jetpack provides the controls and this plugin stands aside.
Does this work with the block-based widget editor?
Yes! Widget Visibility Control works with all widget editing interfaces:
- Block-based widgets (Appearance > Widgets): Visibility settings appear in the Visibility panel in the right sidebar.
- Legacy Widgets in the block editor: The classic “Visibility” button appears within the legacy widget interface.
- Classic Widgets plugin : If you prefer the traditional widget interface, the “Visibility” button appears below each widget.
- Customizer (Appearance > Customize > Widgets): Follows your Widgets screen, so you get the Visibility panel with block-based widgets and the “Visibility” button with classic widgets.
I’m using Jetpack. Will my visibility rules be preserved?
Yes. On activation, the plugin automatically imports all your existing Jetpack Widget Visibility rules. No reconfiguration needed.
Can I use this alongside Jetpack?
Yes, but to avoid conflicts, our visibility interface is automatically disabled while Jetpack Widget Visibility module is active, for blocks and for classic widgets alike, and a notice on the Widgets screen tells you so. You can continue using Jetpack’s interface, and when you disable the Jetpack module, our interface will take over automatically. Your visibility rules are stored in both formats, so the transition is seamless. Rules already saved keep being applied either way.
What happens if I deactivate or uninstall this plugin?
On deactivation, your rules are preserved for when you reactivate. On uninstall, only this plugin’s data is removed. If you haven’t cleaned the legacy data, Jetpack can still read your original rules.
Can I use multiple conditions on a single widget?
Yes. You can add multiple conditions and choose whether ALL conditions must match (AND logic) or just ONE condition needs to match (OR logic).
Does this plugin slow down my site?
No. The plugin is optimized for performance with intelligent caching. Assets only load on admin widget screens, and frontend checks are minimal and cached.
Does this require a WordPress.com connection?
No. This plugin works completely standalone without any external connections or dependencies.
Does this work with full site editing (FSE) themes?
This plugin is designed for widget areas (sidebars, footers, etc.). Full Site Editing themes typically don’t use traditional widget areas – instead, they manage all content through the Site Editor using template parts and blocks.
If your FSE theme includes widget areas, the plugin will work in those areas. If you need conditional visibility for blocks in FSE templates, you would need a different solution designed for the Site Editor.
How does time scheduling work?
Time scheduling allows you to show or hide widgets during specific date and time ranges. This is ideal for:
- Promotional banners – Display ads only during sale periods
- Seasonal content – Show holiday greetings or seasonal offers automatically
- Flash sales – Schedule countdown widgets for limited-time deals
- Event announcements – Display event info until the event date passes
- Time-sensitive notices – Show maintenance warnings or temporary announcements
You can configure:
- Show only during period – Widget appears only between the start and end dates
- Hide during period – Widget is hidden between the start and end dates
- No end date – Widget starts showing from a specific date and continues indefinitely
The schedule uses your WordPress timezone setting (Settings > General). If you also have visibility rules configured (like “show only on homepage”), both conditions must be met – the widget will only appear on the homepage AND within the scheduled time range.
How does the taxonomy selector work on sites with many taxonomies?
When you select “Taxonomy” as a condition, a second dropdown appears where you pick the specific taxonomy (e.g., Product Category, Color, Size). Only then does the third dropdown show the terms for that taxonomy. This cascading approach makes it much faster to find the right term on WooCommerce sites or any site with many custom taxonomies.
For hierarchical taxonomies, you can also check “Include children” to automatically match all child terms of the selected term.
Can I import my rules from Widget Logic?
Yes, both from Widget Logic 5.x and 6.x — they use the same storage format in the database. When the plugin detects Widget Logic data, you’ll see a notice and a section in Appearance > Widget Visibility > Import / Export. The importer shows each widget that had Widget Logic code, the original PHP, and the rule we extracted. For widgets whose code we can’t translate automatically, you decide per widget: import as always visible, import as always hidden, or skip.
What Widget Logic functions are supported on import?
Most of the common conditional tags: is_home, is_front_page, is_single, is_singular (with or without a post type), is_page (with an ID, a slug, or no arguments at all), is_category, is_tag, is_author, is_archive, is_search, is_404, is_date / is_day / is_month / is_year, is_user_logged_in, is_sticky, is_paged, is_attachment, is_privacy_policy, is_tree, current_user_can, is_tax, has_term, has_category, is_post_type_archive, in_category, and has_tag.
WooCommerce shops are covered too: is_product, is_shop, is_cart, is_checkout, is_account_page, is_product_category, is_product_tag and is_woocommerce.
Rules that are just a constant (true, false, or combinations like !(true || false)) import as always visible or always hidden.
Lists of values are supported too, in both notations: is_page( array( 1, 2, 3 ) ) and is_page( [ 1, 2, 3 ] ). So are negated rules like !is_home(), !is_page(2) && !is_page(3), or !( is_home() || is_category(5) ), which are imported as “hide” rules.
Checks on the current address are translated into URL rules: strpos() , stripos() or str_contains() on $_SERVER['REQUEST_URI'] for “the address contains”, strpos( ... ) === 0 or str_starts_with() for “the address starts with”, and $_SERVER['REQUEST_URI'] == '/some/path/' for an exact address. Their negated forms are imported as “hide” rules.
Combinations using only AND or only OR are supported. What still cannot be translated automatically: mixed AND/OR expressions, a negated condition combined with a positive one, wp_is_mobile, regular expressions, code reading post meta or any variable other than $_SERVER['REQUEST_URI'] , and custom functions. For those the importer tells you why and asks what to do with that widget.
How does the URL rule work?
Choose “URL” as the rule type and type the address you want to match. A path is enough ( shop , /shop/ and shop/ all mean the same page), and you can also paste the full URL from the browser.
Use * as a wildcard for any run of characters:
- shop/* matches /shop/ and everything below it
- shop* matches /shop/, /shop/shoes/ and also /shopping/
- */reviews matches any address whose last part is “reviews”
- *sale* matches any address with “sale” in it
Upper and lower case make no difference, and neither does the final slash. Each rule holds one pattern: to cover several addresses, add one rule for each and leave them joined with OR.
To look at the query string, write it after a ? : shop?orderby=price matches /shop/ with exactly that query, ?*promo=* matches any page that carries a “promo” parameter, and *promo=summer* finds that text anywhere in the address. A ? with nothing after it asks for no query string at all, so /? is the home page only when nothing follows it.
Two things worth knowing. If your site uses a page cache, rules that depend on tracking parameters may not vary, because many caches serve the same stored page whatever the utm_ values are. And a URL rule only looks at the address: to show a widget to certain people, use the User, Role or Capability rules instead.
Will my Widget Logic data be deleted after import?
No. The original Widget Logic data stays in the database so you can roll back if needed. From Appearance > Widget Visibility > Import / Export you can delete it later with “Remove Widget Logic data”.
Can I export and restore my visibility rules?
Yes, both. In Appearance > Widget Visibility > Import / Export, the Export section downloads a JSON file with every rule, which widget each one belongs to, the plugin version and the site it came from. The same section restores a file back, so it works as a real backup and as a way to carry a setup from a staging site to production.
When restoring you choose what happens to what is already there: Merge only touches the widgets present in the file and leaves the rest alone, while Replace clears every current rule first so the site ends up exactly as the file describes.
Rules are matched to widgets by their identifier ( text-3 , categories-2 …), so a restore lands correctly on the same site or on a copy of it. On a different site the identifiers may belong to other widgets, so check the result. Anything the file contains that this version does not understand is skipped and reported, never imported half-way.
Can I import my rules from Widget Options?
Not yet. Widget Options stores its visibility data in a format that’s very different from Widget Logic and Jetpack, and an importer is a separate effort. If you only used Widget Options for visibility, you can configure the equivalent rules in our plugin manually — the most common scenarios (pages, post types, taxonomies, user roles, login state) are all supported.
