Conditional Content

The Conditional Content block allows you to display content only when specific conditions are met. It’s a wrapper block that renders its child blocks only if the defined logic evaluates as true. If the condition is not fulfilled, no output is generated — meaning no markup is rendered at all, not even hidden via CSS. This block supports a wide range of condition types, including checks against URL parameters, cookies, dates and times, and even custom logic via a filter.

In the editor, the Conditional Content block appears as a simple wrapper box. You can insert any other blocks inside it, similar to how a Group block works. At the top of the box, there’s a label showing a short summary of the conditions set, helping you quickly identify when the content will be shown, if these have been configured already. For detailed setup and configuration, use the block sidebar.

Settings

In the sidebar, the Conditional Content block is divided into two panels: Conditions and Behaviour.

Conditions

In the Conditions panel, if no conditions are currently defined, you’ll only see a single “Add condition” button. Clicking this button adds a new, empty condition row. You can then define the condition by selecting its type, available options, a condition rule (like “Is”, “Is not”, etc.), and the desired comparison value. To add additional conditions, click the + button. Any condition can be removed using the X icon next to it.

You define the rules that must be true for the block’s content to be displayed. There are 14 different types of conditions available. Each condition type comes with its own context-aware settings, including value inputs, logic options, and comparison types. You can combine multiple conditions for advanced display logic. The available condition types are:

• URL parameter conditions check whether a specific query parameter exists in the page URL and what value it holds. You can choose a predefined (e. g. Google Campaign or Forms parameters) or custom parameter name and define rules like “Has the value”, “Contains the value”, “Is set” or the opposite rules. If using “Is set” or “Is not set”, no value input is required.
• Cookie conditions work the same way as URL parameters but evaluate the value of a cookie set by the site. You can choose from predefined cookies or define your own. All standard comparison operators are available, including “Is set” and “Contains the value”.
• Local Storage conditions let you check the value of items stored in the browser’s local storage. Only individual keys are supported. You can define whether the key is set, has a specific value, or contains a string.
• Time conditions allow you to show content depending on the time of the visit. You can select from predefined times of day (like “morning” or “night”) or enter a specific hour or timeframe manually, instructions are given in the description text if selected.
• User role conditions check the role of the current user. You can use this to target logged-in users with specific roles or show content to non-logged-in users. Options include “is” or “is not” with a dropdown for selecting roles.
• Post conditions are based on the current post context. You can choose a post type and then define whether the post being displayed matches one or more specific post IDs. This works well for targeting single pages or posts.
• Post taxonomy conditions evaluate the taxonomy terms of a post. This only works in archive templates. You can select a taxonomy and compare whether it includes or excludes specific terms. Terms can be selected from a list or entered manually.
• Post meta conditions use meta field values of the current post to determine visibility. This feature only works with custom post types created via the Post Types feature. You can choose from various numeric and textual comparisons — like “Smaller than”, “In the future (date)”, or “Contains the value”.
• Post type conditions display content depending on the post type being rendered. There’s no need for additional configuration aside from selecting which post type should match or not match.
• Post index conditions check the index of the current post in a Query Loop. This only works inside a Query Loop block. The first item has index 1, second is 2, and so on. You can check for exact matches, ranges, or even/odd positions.
• Number of posts found lets you render content depending on how many posts are returned by a query — specifically for search or archive templates. You can check for no results, a single result, or multiple ones. No input values are needed.
• Archive taxonomy conditions let you display content based on the archive’s taxonomy term. These only work in archive templates. You can check if the current archive is for specific terms or exclude certain terms.
• Location (Template Type) conditions are based on the WordPress template being rendered. You can select from standard locations like the front page, blog page, or 404 page. Multiple values can be selected and checked using “is” or “is not”.
• Custom Filter conditions offer the most flexibility. These are defined by developers using the greyd.conditional-content.conditions filter. You can choose a registered custom condition and configure it similarly to cookie or parameter conditions. Refer to the developer documentation for implementation details.

Behaviour

The Behaviour panel lets you control how the block evaluates multiple conditions and how it behaves in the frontend.

When multiple conditions are defined, the Operator setting (AND / OR) determines how the block evaluates them. With AND, all conditions must be true. With OR, just one matching condition is enough. If only one condition exists, the operator has no effect.

The Update live toggle enables real-time updates in the frontend without reloading the page. This currently works only for time-based conditions. Note that while the content is already rendered in the DOM, it remains hidden via display: none until the condition becomes true.

With Avoid caching enabled, the block re-evaluates its condition(s) on the client side after the initial page load. This ensures accurate behavior even with cached HTML. Currently, this feature supports only URL and cookie conditions and works best when the block contains a single condition. Keep in mind: the block’s content is rendered initially but removed from the page if the condition is false.

Finally, Enable debug mode shows a debug message in the frontend. This message helps identify configuration issues during development. Important: this option should never be enabled on production websites.

Video