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.

geomagas

This plugin provides an [if] shortcode to conditionally render content. The syntax is the following:
<pre><code>[if condition1 condition2=false condition3]{content}[/if]
</code></pre>
Conditions are passed as attribute names. Multiple conditions evaluate to the result of ORing all of them. In other words, if at least one condition evaluates to the desired boolean result, {content} is rendered, otherwise it is discarded. 
Attribute values determine if we want the condition to be true or false. A value of <code>'0'</code>, <code>'false'</code>, <code>''</code> (the empty string), <code>'null'</code> or <code>'no'</code> means we expect the condition to be false. Anything else, including the absense of a value, is interpreted as true.
For example, suppose that we want to include a sentence in a post, but only for anonymous visitors:
<pre><code>[if is_user_logged_in=no]The Sentence.[/if]
</code></pre>
It also provides an [else] shortcode and an [eitherway] one for use inside [if] blocks. [else] will render its content if the condition evaluates to false, and [eitherway] will render its content regardless of the evaluation result. 
When used outside an [if] block, these shortcodes behave as if the whole content is surrounded by an [if] shortcode whose condition evaluates to true. In other words, an [else] shortcode would not render any content, while a [eitherway] one would. You can use as many of these shortcodes as you like in a single [if] block, which gives you the ability to do things like:
<pre><code> - Am I logged in?
 [if is_user_logged_in]- Yes you are.
 [else]- No you are not.
 [/else][eitherway]- I'm sorry, what?
 [/eitherway]- I said YOU A-R-E LOGGED IN!!!
 [else]- YOU ARE NOT LOGGED IN!!! What's the matter with you?[/else][/if]
</code></pre>
A multitude of conditions are supported out-of-the-box. The following evaluate to the result of the corresponding <a href="https://developer.wordpress.org/themes/basics/conditional-tags/" rel="nofollow ugc">WordPress Conditional Tag</a>, using the no-parameter syntax:
<pre><code> is_single
 is_singular
 is_page
 is_home
 is_front_page
 is_privacy_policy
 is_attachment
 is_category
 is_tag
 is_tax
 is_author
 is_archive
 is_year
 is_month
 is_date
 is_day
 is_time
 is_feed
 is_search
 is_sticky
 is_preview
 has_term
 has_excerpt
 comments_open
 pings_open
 is_404
 is_user_logged_in
 is_super_admin
 is_multi_author
 is_multisite
 is_main_site
 is_child_theme
</code></pre>
For example, the evaluation of the <code>is_page</code> condition is equivalent to calling <code>is_page()</code> with no parameter.
<h3>Extending</h3>
The functionality of the plugin can be extended by other plugins, by means of adding custom conditions through filters. To add a custom condition, a filter hook must be defined in the following manner:
<pre><code>add_filter($if_shortcode_filter_prefix.'my_condition','my_condition_evaluator');

function my_condition_evaluator($value) {
 $evaluate=.... /* add your evaluation code here */
 return $evaluate;
}
</code></pre>
Then, you can use your custom condition like so:
<pre><code>[if my_condition]{content}[/if]
</code></pre>
A big thanks to M Miller for the <a href="http://wordpress.stackexchange.com/a/123073/39275" rel="nofollow ugc"><code>normalize_empty_atts()</code></a> function.

If Shortcode

This plugin provides an [if] shortcode to conditionally render content.

RenderWhen for Blocks vs If Shortcode