Abhishek Kumar

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:
<blockquote>
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.
</blockquote>
RenderWhen is built around two ideas that set it apart from other visibility plugins:
<ul>
<li>Server-side rendering only. When a block is hidden by a condition, it is not rendered into the page output at all. No CSS <code>display: none</code>, no DOM bloat, no leaked content in view-source. Search engines, screen readers, and your page weight all benefit.</li>
<li>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.</li>
</ul>
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.
<h4>Built-in conditions (v1.0)</h4>
<ul>
<li>User state — show to logged-in users, logged-out users, or specific roles</li>
<li>Date range — show between two datetimes, timezone-aware</li>
<li>Device type — show on desktop, tablet, or mobile</li>
</ul>
<h4>Designed for</h4>
<ul>
<li>Agencies and freelancers building client sites who want a clean, predictable visibility tool</li>
<li>Developers who need an extension point, not another walled garden</li>
<li>Anyone who cares about page weight and SEO hygiene</li>
</ul>
<h4>What this plugin deliberately does NOT do</h4>
It does one thing well rather than ten things adequately. Out of scope in v1.0:
<ul>
<li>Multi-condition AND/OR groups (planned for v1.1)</li>
<li>URL / cookie / referrer / geolocation conditions</li>
<li>WooCommerce, ACF, or membership integrations</li>
<li>A settings dashboard</li>
</ul>
If you need those today, <a href="https://wordpress.org/plugins/conditional-blocks/" rel="ugc">Conditional Blocks</a> and <a href="https://wordpress.org/plugins/block-visibility/" rel="ugc">Block Visibility</a> are excellent and well-established choices.
<h4>For developers</h4>
Register a custom condition in three steps. Implement the interface, add it to the registry, ship.
<pre><code>add_action( 'renderwhen_register_conditions', function ( $registry ) {
 $registry->register( new My_Plugin\\Conditions\\Country_Condition() );
} );
</code></pre>
Your condition class implements <code>RenderWhen\Conditions\Interface_Condition</code>:
<pre><code>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 );
 }
}
</code></pre>
The full set of public filters:
<ul>
<li><code>renderwhen_register_conditions</code> — register your conditions here</li>
<li><code>renderwhen_evaluate_{condition_id}</code> — last-mile override of any condition’s result</li>
<li><code>renderwhen_render_block_hidden</code> — fires when a block is hidden, useful for cache busters and SEO tools</li>
<li><code>renderwhen_device_type</code> — swap in your own device detection</li>
</ul>
The plugin is developed openly on GitHub. Issues, PRs, and architecture discussions welcome: https://github.com/abhishekfdd/renderwhen

RenderWhen for Blocks

Show or hide any block when conditions match. Developer-first API and true server-side rendering — hidden blocks never reach the browser.

Jonathan Horowitz

Content Visibility for Divi Builder allows Sections and Modules to be displayed/hidden based on the outcome of a PHP boolean expression.
This plugin is for both the standalone Divi theme (or child themes thereof) and the Divi Builder plugin, version 3 or higher!
<h3>Developer Filters</h3>
<h4>Expression Validation Filters</h4>
The following filters allow developers to customize expression validation behavior. Add these filters in your theme’s functions.php or in a custom plugin.
<code>content_visibility_for_divi_builder_blocked_functions</code>
Filter the array of blocked function names. Functions in this list will cause an expression to fail validation. All comparisons are case-insensitive.
Example – allow <code>file_get_contents</code> (blocked by default):
<pre><code>add_filter( 'content_visibility_for_divi_builder_blocked_functions', function( $functions ) {
 return array_diff( $functions, array( 'file_get_contents' ) );
} );
</code></pre>
Example – block an additional function:
<pre><code>add_filter( 'content_visibility_for_divi_builder_blocked_functions', function( $functions ) {
 $functions[] = 'my_dangerous_function';
 return $functions;
} );
</code></pre>
<code>content_visibility_for_divi_builder_allowed_tokens</code>
Filter the array of allowed PHP token types (T_* constants). Tokens not in this list will cause an expression to fail validation. This is an advanced filter – consult the PHP tokenizer documentation before modifying.
Example – allow the T_VARIABLE token type (blocked by default, use with caution):
<pre><code>add_filter( 'content_visibility_for_divi_builder_allowed_tokens', function( $tokens ) {
 $tokens[] = T_VARIABLE;
 return $tokens;
} );
</code></pre>
<code>content_visibility_for_divi_builder_allowed_chars</code>
Filter the array of allowed single-character tokens. Characters not in this list (such as <code>=</code>, <code>;</code>, <code>{</code>, <code>}</code>, <code>`</code>, <code>@</code>, <code>&</code>, <code>|</code>, <code>~</code>, <code>^</code>) will cause an expression to fail validation.
Example – allow the <code>&</code> character for bitwise operations:
<pre><code>add_filter( 'content_visibility_for_divi_builder_allowed_chars', function( $chars ) {
 $chars[] = '&';
 return $chars;
} );
</code></pre>
<code>content_visibility_for_divi_builder_allowed_callables</code>
Filter the array of callables (function names and <code>Class::method</code> static-method entries) the validator considers known-safe. Anything not on the allowlist (and not on the <code>blocked_functions</code> denylist) is treated as an “Unknown callable” error. Names are normalized (leading <code>\</code> stripped, <code>namespace\</code> keyword prefix stripped, lowercased) before comparison, so <code>\My\Namespace\Class::method</code>, <code>My\Namespace\Class::method</code>, and <code>namespace\My\Namespace\Class::method</code> all match the same allowlist entry. The default list ships with WordPress conditional tags (<code>is_user_logged_in</code>, <code>current_user_can</code>, <code>is_admin</code>, etc.). The Expression Validation tab’s content scanner generates a ready-to-paste snippet for this filter pre-populated with every custom callable currently in your content.
Example – allowlist a theme helper and a static service method:
<pre><code>add_filter( 'content_visibility_for_divi_builder_allowed_callables', function( $callables ) {
 $callables[] = 'mytheme_should_be_visible';
 $callables[] = 'MyTheme\Visibility\Service::checkUser';
 return $callables;
} );
</code></pre>

Content Visibility for Divi Builder

Thanks for maintaining this plugin. It works great. Some examples in the documentation would make the use at the beginning easier :)

Great PlugIn


I found this addon to be very useful in putting up content for a persons website. It allows you to create PHP functions or use inherent true/false functions that you can then control what content shows based on that. I find it useful in having one content being shown before a certain date and another block being set to show after a certain date. Allowing you to schedule content changes within the website.


RenderWhen for Blocks vs Content Visibility for Divi Builder