Abhishek Kumar

<p>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:</p>
<blockquote>
<p><em>Show this block when the user is logged in.</em><br />
  <em>Show this block when the date is between March 1 and March 31.</em><br />
  <em>Show this block when the device is mobile.</em></p>
</blockquote>
<p>RenderWhen is built around two ideas that set it apart from other visibility plugins:</p>
<ul>
<li><strong>Server-side rendering only.</strong> 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><strong>Public Conditions API.</strong> 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>
<p>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.</p>
<h4>Built-in conditions (v1.0)</h4>
<ul>
<li><strong>User state</strong> — show to logged-in users, logged-out users, or specific roles</li>
<li><strong>Date range</strong> — show between two datetimes, timezone-aware</li>
<li><strong>Device type</strong> — 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>
<p>It does one thing well rather than ten things adequately. Out of scope in v1.0:</p>
<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>
<p>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.</p>
<h4>For developers</h4>
<p>Register a custom condition in three steps. Implement the interface, add it to the registry, ship.</p>
<pre><code>add_action( 'renderwhen_register_conditions', function ( $registry ) {
    $registry->register( new My_Plugin\\Conditions\\Country_Condition() );
} );
</code></pre>
<p>Your condition class implements <code>RenderWhen\Conditions\Interface_Condition</code>:</p>
<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>
<p>The full set of public filters:</p>
<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>
<p>The plugin is developed openly on GitHub. Issues, PRs, and architecture discussions welcome: https://github.com/abhishekfdd/renderwhen</p>


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.

Davis Simiyu Wanyonyi

<p><strong>Menu Visibility Control</strong> is a lightweight, privacy-friendly WordPress plugin that lets you decide exactly <strong>who sees each menu item</strong>, directly inside the WordPress menu editor.</p>
<p>No settings pages.<br />
No lock-in.<br />
No performance overhead.</p>
<p>Everything is managed where it belongs: <strong>Appearance <span aria-hidden="true" class="wp-exclude-emoji">→</span> Menus</strong>.</p>
<h3>👁️ Visibility Options Per Menu Item</h3>
<p>You can control visibility based on:</p>
<ul>
<li>👥 Everyone</li>
<li>🔒 Logged-in users</li>
<li>🚪 Logged-out users</li>
<li>🧩 Specific user roles (Administrator, Editor, Subscriber, etc.)</li>
<li>📱 Device type (Desktop / Tablet / Mobile)</li>
<li>📄 Specific pages (auto-detected list)</li>
</ul>
<p>All conditions are optional and safely combined.</p>
<h3>💡 Perfect For</h3>
<ul>
<li>Membership and community websites</li>
<li>Client dashboards and intranets</li>
<li>Multi-role WordPress sites</li>
<li>Sites with mobile-specific navigation</li>
<li>Blogs that need different menus for visitors vs members</li>
</ul>
<h3>🔧 Key Features</h3>
<ul>
<li>Native integration with <strong>Appearance <span aria-hidden="true" class="wp-exclude-emoji">→</span> Menus</strong></li>
<li>Works with <strong>any theme or page builder</strong></li>
<li>Role-based menu visibility</li>
<li>Device-based menu visibility</li>
<li>Page-specific menu visibility</li>
<li>Auto-hidden UI (only shows options when enabled)</li>
<li>Secure (nonces, sanitization, strict validation)</li>
<li>Performance-optimized (runs only during menu rendering)</li>
<li>100% free, open-source, and donation-supported</li>
</ul>
<h3>🧠 Why Use Menu Visibility Control?</h3>
<p>Unlike large menu or membership plugins, this plugin:</p>
<ul>
<li>Uses <strong>only WordPress core hooks</strong></li>
<li>Stores <strong>minimal metadata</strong></li>
<li>Is compatible with caching, multilingual sites, and block themes</li>
<li>Does not track users or collect data</li>
</ul>
<p>It does one thing — and does it well.</p>
<h3>Support</h3>
<p>Need help or want to share feedback?</p>
<ul>
<li>Visit the <a href="https://wordpress.org/support/plugin/menu-visibility-control/" rel="ugc">support forum</a></li>
<li>Leave a <a href="https://wordpress.org/support/plugin/menu-visibility-control/reviews/#new-post" rel="ugc">review</a></li>
<li>Support development via <a href="https://knowledge.buzz/donate" rel="nofollow ugc">donation</a></li>
</ul>
<h3>License</h3>
<p>This plugin is licensed under the <strong>GPL v2 or later</strong>.</p>
<p>You are free to use, modify, and redistribute it under the same license.</p>
<p>Code is Poetry. ❤️</p>


Menu Visibility Control

Control WordPress menu item visibility based on login status, user roles, device type, or specific pages — lightweight and theme-agnostic.

RenderWhen for Blocks vs Menu Visibility Control