Until now, Responsive Visibility did one job well: hide or show a Gutenberg block based on the screen size. You could toggle a block off on mobile, keep it on desktop, and add as many custom breakpoints as your layout needed.
Version 1.2.0 adds a second way to control a block. It is called Visibility Conditions, and it decides whether a block appears based on the visitor or the page, not the screen.
What Visibility Conditions do
A condition answers a simple question about the current request, like “is this person logged in?” or “are we on a product page?”. You add one or more conditions to a block, choose whether all of them or any of them need to match, and decide whether a match should show or hide the block.
It lives in a new “Visibility Conditions” panel in the block sidebar, next to the device controls you already use. No shortcodes, no extra page, no code.
The conditions in 1.2.0
- Login Status — show a block to logged-in users, or only to logged-out visitors.
- User Role — target administrators, editors, authors, subscribers, customers, or any role on your site.
- Specific User — show a block to one exact user by ID.
- Specific Post or Page — show a block only on a post or page you choose.
- Post Type — target posts, pages, WooCommerce products, or any custom post type.
- Page Type — front page, blog, single posts, archives, search results, or the 404 page.
- Shortcode — gate a block on your own PHP logic by pointing it at a shortcode.
A few things you can build
Say you run a membership site. Drop a “Join now” block on the page and give it one condition: Login Status is logged out. Members never see the pitch, and everyone else does. Add a second block with Login Status is logged in for the “Welcome back” message, and the two swap automatically.
Or you sell products. Put a shipping-policy block on the page and set Post Type to product. It shows on every product, and nowhere else, without touching a template.
Because you can combine conditions with the device rules on the same block, you can also do things like “show this banner to logged-in customers, but only on desktop.”
How the hiding actually works
This part matters, so it is worth being clear about.
Device rules use CSS. The block stays in the page and a media query hides it at the sizes you picked. That keeps every visitor on the same cached HTML, which is why it works with caching plugins and updates live when you resize the window.
Conditions are different. They run on the server, and a hidden block is left out of the page completely. That is deliberate: a member-only block should never sit in the page source where a logged-out visitor could read it. The trade-off is that login and role conditions depend on your cache treating logged-in visitors differently, which every major caching plugin already does by default.
Still fully backward compatible
Conditions are off by default. If you do not open the panel, nothing about your existing blocks changes. Everything from earlier versions, including the legacy device settings and your saved custom breakpoints, keeps working exactly as before. That has been the rule since day one and it has not changed.
Built to grow
Under the hood, each condition is a small, self-contained piece, and the editor builds its interface from what the server reports. That means new conditions can be added without rewriting the panel, and an add-on can register its own conditions through a filter without editing the plugin. Date and time conditions, URL targeting, and a few others are on the list for a future release.
Get it
Update to Responsive Visibility 1.2.0 from your Plugins screen, open any block, and look for the Visibility Conditions panel in the sidebar. If you have an idea for a condition you would like to see, leave it in the support forum.
