Adding visibility rules

Build a rule set

Select a block and click Visibility in its toolbar. In the Visibility rules window:

• Choose Show if or Hide if: what happens when the rules match.
• Add conditions to a group. Within a group, choose Match all in group or Match any in group. With several groups, choose Match all groups or Match any group.
• Switch the whole set Active or Inactive to turn it off without deleting it.

The window may suggest a rule based on the block's own bindings, such as Show if tagline is not empty. That's the most common rule: hide a heading and its label when the field is empty.

A condition you haven't finished filling in is ignored. A condition of a type that no longer exists (for example, one added by a plugin you've removed) counts as not matching, so the block is treated as if its rules failed.

Field-based conditions

The first condition type, Dynamic tag, tests any value or expression: pick a field with the tag picker (or type @), then a comparison such as is not empty, is equal to or is greater than. The comparison value can be another tag, so you can compare two fields.

It uses the same comparisons as the condition modifiers, including Is first loop item and Is last loop item.

Built-in conditions

Group	Conditions
Post	Post status
User	User is logged in, User is logged out, User role is, User capability, User is author of current post, User can edit current post
Author	Author role is
Templates	Is front page, Is single post, Is page, Is home, Is archive, Is post type archive, Is taxonomy archive, Is search results, Is 404
Request	Current URL, Referrer, Query parameter
Time	Weekday is, Time is between, Date is between
Client	Browser, Operating system

Rules in loops

A data loop repeats its block first, then checks rules on each copy. Put a rule on a block inside the loop to hide individual items ("hide a member card when there's no photo"). A rule on the looped block itself hides the whole loop.

Caching

Rules are checked when WordPress builds the page. If your site uses full-page caching, a page built for one visitor may be served to the next, so rules about the visitor (logged in, role, browser), the request (URL, referrer, query parameter) or the time can show stale results. Exclude those pages from the cache, or vary it by visitor.

Visibility isn't security

A hidden block isn't sent to the browser, but the data it would show may still be available elsewhere, for example in another template. Don't rely on visibility rules to protect private information.

Technical details for LLMs

• Stored: the block's vxframeworkVisibility attribute: { enabled: bool, action: "show"|"hide", group_match: "any"|"all" (default any), groups: [ { match: "all"|"any" (default all), rules: [ … ] } ] }. Evaluated in render_block on the front end only.
• Dynamic rule: { "type": "dynamic", "expression": "@post(rating)", "comparator": "is_greater_than", "args": ["4"] }; comparators are the conditional modifier keys; args may be expressions.
• Named rule type ids: user:logged_in, user:logged_out, user:role, user:capability, user:can_edit_current_post, user:is_author_of_current_post, author:role, content:post_status, content:is_front_page, content:is_single, content:is_page, content:is_home, content:is_archive, content:is_post_type_archive, content:is_tax, content:is_search, content:is_404, request:current_url, request:referrer, request:query_parameter, time:weekday, time:time_between, time:date_between, client:browser, client:operating_system; plus dynamic.
• Exact type keys, operators and value pools: vx-framework/list-visibility-rules. Read it before writing a vxframeworkVisibility config: an unknown rule type fails closed and hides the block.
• Incomplete rules are skipped. Extension: vxframework/visibility/rules (add Base_Rule classes), vxframework/visibility/rule_match (override a result).