Element Conditions, introduced in Bricks 1.5.4, let you skip rendering an element on the front end if its conditions aren’t fulfilled.
Conditions are validated server-side and are meant to be used to filter out/not load an element based on data (post, user, dynamic data, date & time, etc.).
Not rendering an element means the element HTML doesn’t exist in the source code.
This is perfect to restrict content to logged-in users, or users with a certain role (e.g. membership sites), to hide time-sensitive information according to a certain weekday/date/time, in relation to dynamic data, etc.
If you need full programmatic power to define your own element conditions you can use the bricks/element/render Bricks filter.
Accessing conditions
When editing an element, click the “Conditions” (toggle) icon in the panel header to open/close the element conditions interface. If an element has conditions, you’ll also see the “Conditions” toggle icon in the structure panel. Click it, to jump right into the conditions interface of this element.
How element conditions work
At least one set of conditions must be fulfilled for the element to be rendered. Meaning all conditions inside a condition “set” must evaluate to be true.
So there is an OR relationship between condition sets and an AND relationship between conditions inside a set.
To add your first set of conditions click the “+” icon next to the “Conditions” title:
We now have one set with one condition. Every condition consists of the following three properties:
- Key (post ID, user role, date, dynamic data, etc.)
- Comparison operand (==, !=, >, <, contains, before, after, etc.)
- Value (numeric, text, checkbox, select option(s), etc.)
Let’s say we want to show an element only to logged-in users. We’d create the following condition:
This element is now only rendered when the person viewing this page is logged in.
Non-logged-in guests, bots, crawlers, etc. will not be able to see this element (as it’s not in the source code).
Conditions indicator
Notice the highlighted “Conditions” icon in the screenshot above. It’s a great indicator to see at a glance if the element you are editing has any conditions (without having to open the conditions interface).
To quickly scan for element conditions on your page, the “Conditions” (toggle) icon is also visible next to an element in the structure panel. A click on it brings you right into the conditions interface.
Checking multiple conditions
Between a set of conditions exists an OR relation. And conditions within a set have an AND relation.
Let’s create a second set of conditions (by clicking the “+” icon at the top-right again) to illustrate this.
The condition in this new set is fulfilled (true) if the post title is “Account”.
As there is an OR relation between condition sets, the element is rendered if (1) the user is logged in OR (2) the title of the post/page being viewed is “Account”.
Combining AND & OR conditions
Let’s further extend the conditions for this element by also checking if the logged-in user has been registered before the 1st of Jan, 2022.
As there is an AND relation between conditions inside a set, we’ll click the “+” bottom on the bottom-right of our first condition to add another condition to this first set like this:
You’ll also notice the vertical “AND” label between conditions inside a set.
And the horizontal “OR” label between condition sets.
We hope this helps to visualize the element conditions logic even better.
How to compare dynamic data against the value
The element conditions, by default, compare against the label.
Certain dynamic data provider fields allow you to specify the value & label (e.g. Metabox checkbox list, radio, select, etc.). To compare against the value instead, you can use the :value filter, which we introduced in 1.5.7 like this:
The condition above is fulfilled when the Metabox checkbox list has the blue value selected. Without the :value filter the condition would compare against the checkbox option label.
PLANNED: Element Conditions API
We’ll first collect some more user feedback about this first implementation of the element conditions. Once we are confident about the syntax we will provide appropriate filters so you can extend the conditions interface yourself (with your own keys, comparison operands, and values).