Widget Visibility Control

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): Always uses the classic "Visibility" button interface.

Yes. On activation, the plugin automatically imports all your existing Jetpack Widget Visibility rules. No reconfiguration needed.

Yes, but to avoid conflicts, our visibility interface is automatically disabled while Jetpack Widget Visibility module is active. 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.

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.

Yes. You can add multiple conditions and choose whether ALL conditions must match (AND logic) or just ONE condition needs to match (OR logic).

No. The plugin is optimized for performance with intelligent caching. Assets only load on admin widget screens, and frontend checks are minimal and cached.

No. This plugin works completely standalone without any external connections or dependencies.

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.

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

• 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

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.

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.

Phase 1 supports the most common conditional tags: is_home, is_front_page, is_single (for posts), is_singular (with a post type), is_page (with ID or slug), 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_tax, is_post_type_archive, in_category, and has_tag. Combinations using only AND or only OR (not mixed) are supported. Mixed AND/OR trees, current_user_can, is_active_sidebar, code that uses variables or superglobals, and custom functions are not translated automatically — the importer asks you what to do per widget.

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".

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.