RenderWhen for Blocks

RenderWhen for Blocks adds conditional visibility to every block in the WordPress block editor. Decide who sees what, and when, with a panel that reads exactly how you’d say it out loud:

>

Show this block when the user is logged in.

Show this block when the date is between March 1 and March 31.

Show this block when the device is mobile.

RenderWhen is built around two ideas that set it apart from other visibility plugins:

• Server-side rendering only. When a block is hidden by a condition, it is not rendered into the page output at all. No CSS display: none, no DOM bloat, no leaked content in view-source. Search engines, screen readers, and your page weight all benefit.

• Public Conditions API. The three built-in conditions are registered through the same public API your plugin or theme can use to add your own. No hacks, no internal-only code paths.

In the editor, a subtle dashed border marks every block that carries a visibility rule, so a rule-bearing block never disappears from the published page as a surprise. A “Preview as audience” sidebar lets you simulate a logged-out visitor, a specific role, or a different device class right in the editor — blocks whose rule would hide them fade out with a clear badge, no save-and-reload cycle required.

Built-in conditions (v1.0)

• User state — show to logged-in users, logged-out users, or specific roles

• Date range — show between two datetimes, timezone-aware

• Device type — show on desktop, tablet, or mobile

Designed for

• Agencies and freelancers building client sites who want a clean, predictable visibility tool

• Developers who need an extension point, not another walled garden

• Anyone who cares about page weight and SEO hygiene

What this plugin deliberately does NOT do

It does one thing well rather than ten things adequately. 0:

• Multi-condition AND/OR groups (planned for v1.1)

• URL / cookie / referrer / geolocation conditions

• WooCommerce, ACF, or membership integrations

• A settings dashboard

If you need those today, Conditional Blocks and Block Visibility are excellent and well-established choices.

For developers

Register a custom condition in three steps. Implement the interface, add it to the registry, ship.

add_action( 'renderwhen_register_conditions', function ( $registry ) { $registry->register( new My_Plugin\\Conditions\\Country_Condition() ); } );

Your condition class implements RenderWhen\Conditions\Interface_Condition:

namespace My_Plugin\Conditions;

use RenderWhen\Conditions\Interface_Condition;

class Country_Condition implements Interface_Condition { public function get_id(): string { return 'country'; }

public function get_label(): string { return __( 'Visitor country', 'my-plugin' ); }

public function get_schema(): array { return array( 'type' => 'object', 'properties' => array( 'countries' => array( 'type' => 'array', 'items' => array( 'type' => 'string' ), ), ), ); }

public function evaluate( array $settings, array $context ): bool { $current = my_plugin_detect_country(); return in_array( $current, $settings['countries']?? array(), true ); } }

The full set of public filters:

• renderwhen_register_conditions — register your conditions here

• renderwhen_evaluate_{condition_id} — last-mile override of any condition’s result

• renderwhen_render_block_hidden — fires when a block is hidden, useful for cache busters and SEO tools

• renderwhen_device_type — swap in your own device detection

The plugin is developed openly on GitHub. com/abhishekfdd/renderwhen