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.

dudaster

Ele Conditions for Elementor turns static Elementor elements into interactive, context-aware components — without writing a single line of code.
There are two independent systems, both accessible from the Advanced tab of any widget, section, or container:
<h4>⚡ Triggers & Actions (client-side, no page reload)</h4>
Attach one or more trigger → action pairs to any element.
10 trigger types:
<ul>
<li>Click — user clicks the element</li>
<li>Hover — user hovers over the element</li>
<li>Delay on load — fires after X milliseconds from page load</li>
<li>Scroll into view — fires once when the element enters the viewport</li>
<li>Time on page — fires after X seconds the visitor has been on the page</li>
<li>Exit intent — fires when the cursor moves toward closing the tab</li>
<li>First visit — fires only on the visitor’s very first page load (localStorage)</li>
<li>Nth visit — fires on the Nth page load (visit counter in localStorage)</li>
<li>A/B Group A / B — fires for visitors randomly assigned to group A or B (persists via localStorage)</li>
</ul>
9 action types:
<ul>
<li>Show — make the target element visible</li>
<li>Hide — hide the target element</li>
<li>Toggle — toggle visibility on each trigger</li>
<li>Add / Remove / Toggle Class — apply a CSS class (great for CSS animations)</li>
<li>Scroll To — smooth-scroll the page to the target element</li>
<li>Focus — set browser focus on the target (input fields, etc.)</li>
<li>Close Others in Group — hide all siblings sharing a CSS class (accordion pattern)</li>
</ul>
Target selector: leave empty to act on the element itself, or enter any CSS selector to act on another element anywhere on the page.
Hide Initially: a dedicated switcher that hides the element on load independently of triggers — useful for elements revealed by a trigger.
<h4>🎛 Display Conditions (server-side, evaluated at render time)</h4>
Show or hide elements based on variables, rules, and time windows. Multiple conditions per element with AND / OR logic.
Built-in variables include: <code>user_role</code>, <code>is_logged_in</code>, <code>user_id</code>, <code>post_type</code>, <code>post_status</code>, <code>post_age_days</code>, <code>post_word_count</code>, <code>post_has_thumbnail</code>, <code>cart_count</code>, <code>cart_total</code>, <code>current_hour</code>, <code>current_day</code>, <code>current_month</code>, <code>current_year</code>, <code>utm_source</code>, <code>utm_medium</code>, <code>utm_campaign</code>, <code>utm_content</code>, <code>utm_term</code>, and more.
Condition types:
<ul>
<li>Simple — compare a variable to a value using ==, !=, >, <, >=, <=, contains, starts_with, ends_with, empty, not_empty</li>
<li>Time interval — show element only between two times of day (supports cross-midnight ranges)</li>
<li>Date/datetime interval — show element only within a date or datetime window</li>
</ul>
Custom variables — register your own variables via the <code>eleconditions_vars</code> filter in your theme’s <code>functions.php</code>.
ACF support — pick any ACF field from a searchable dropdown; the value is fetched at render time.
User meta — condition on any WordPress user meta key for the current visitor.
Debug mode — shows a red-bordered overlay with the evaluated variable values, visible only to editors and administrators.
<h4>Developer-friendly</h4>
<ul>
<li>Zero dependencies beyond Elementor</li>
<li>Fully filterable variable system</li>
<li>No inline styles injected into saved content — everything is evaluated at render</li>
</ul>
Note: Requires the free <a href="https://wordpress.org/plugins/elementor/" rel="ugc">Elementor</a> plugin.

Ele Conditions for Elementor

Add interactive triggers and conditional display logic to any Elementor element — show, hide, toggle on click, scroll, exit intent, and more.

RenderWhen for Blocks vs Ele Conditions for Elementor