Display Conditions extends the Divi 5 builder’s own Conditions panel with conditions about the visitor rather than the page. They appear in the condition picker under a Squad Conditions heading, alongside Divi’s own, and they can be set on any module, Squad’s or Divi’s.
Target a module
- Switch on Display Conditions from Divi Squad → Extensions and save. On Divi 4 it will not load, and it says so in an admin notice rather than failing quietly.
- Open a page in the Divi 5 Visual Builder, open the module’s settings, and go to its Conditions panel.
- Add a condition and pick one from the Squad Conditions group in the picker.
- Fill in the condition and choose whether the module is shown or hidden when it matches. Add more conditions to the group and set the group to match all of them or any of them.
- Save the page and check it as a visitor who does not qualify. The module should be absent from the page source, not merely invisible.
What you can test in the builder
Eight conditions appear directly in the Divi 5 picker, plus a ninth that references a saved set:
- Country and Continent: where the visitor is.
- Referrer Host, UTM Parameter and URL Parameter: where they came from.
- Visitor Type, Visit Count and Visit Recency: first time or returning, how many visits, and how recently the last one was. These three are counted in a cookie the extension sets on the front end.
- Saved Rule Set: match against one of your own reusable rule sets.
The seven that live in a rule set
The engine resolves seven more conditions that are not in the builder picker, because Divi ships its own equivalents there: logged in state, user role, a fixed date window, a recurring schedule, device, operating system, and the current post’s context. They are reachable by building a rule set that uses them and referencing that set from the module. That is the reason to learn rule sets even for a single module.
Reusable rule sets
A rule tree you will use more than once is saved as a rule set and referenced by name, so twenty modules aimed at the same audience are one definition rather than twenty. A set is groups of conditions, two levels and no deeper, and a set cannot reference another set from inside itself. Both limits are enforced when the set is saved, with an error naming the group and the condition rather than a silent truncation.
A reference to a set that is missing or switched off shows the module rather than hiding it. Failing open is deliberate: a deleted rule set should not silently empty your pages.
Evaluated on the server
Every condition is resolved before the page is sent, so a module a visitor does not qualify for is never written into their page. Nothing is hidden with CSS, and nothing about your targeting is readable in the page source. The same engine answers Popup Maker’s Who sees it field, which is why a popup nobody qualifies for is never printed either.
The caching rule
Every one of these conditions is per visitor, and a full page cache serves one visitor’s page to the next. The first time the extension resolves one of its own conditions on a real front end request, it defines the standard do not cache constant and sends no cache headers. It deliberately does not do this in the admin, in a REST request, or inside the builder, because none of those is the page a cache would store.
If your caching layer does not read that signal, exclude those pages yourself. A page whose content depends on the visitor must not be served from a shared cache.