DirectoryCustomize — Visibility Engine — Help

Gate logged-out visitors on member profiles with cutoff/fade, paywall, or button-only treatments — plus a rules engine for fine-grained per-viewer control.

What it does

Visibility Engine controls what logged-out (or otherwise gated) visitors can see on any widget across your directory site. It does not replace the widget — BD still renders the full natural content first, then the engine overlays the gating treatment on top. Three modes ship out of the box:

1. Buttons only — the widget stays fully visible; action buttons (Send Message / See Phone / Write Review on profiles, or equivalent actions on other widgets) get rewritten to drive sign-up
2. Cutoff & Fade — the widget renders up to a chosen point, the rest fades out, and a sign-up CTA card sits below the fade
3. Paywall — the full widget renders behind a blur, and a centered CTA card overlays it

On top of those modes, a Visibility Rules engine lets you return a different verdict (show / hide / blur / show_full) per viewer based on auth state, plan, page type, device, time of day, and more. Rules give you per-viewer control without having to ship code.

The most common use case is gating member profiles for logged-out visitors, but the engine works on any widget — sidebars, contact forms, search result cards, custom sections, and more. If it renders on the page, VE can gate it.

Mode picker

Configure via Plugins → DirectoryCustomize → My Widgets → Visibility Engine → Configure → Settings.

Cutoff mode options

When mode is Cutoff & Fade, two extra fields appear:

About the "After Tab Nav" option — this shows the tab BUTTONS but fades the tab CONTENT. It's the strongest teaser pattern: visitors see there are more tabs (Reviews, Photos, Specialties, etc.) without seeing what's in them, which drives sign-up curiosity.

Header buttons treatment

The Send Message / See Phone / Write Review buttons at the top of the profile have their own behavior settings, independent of the mode. Pick how each behaves for logged-out viewers:

When you pick Rename + redirect, three text/URL pairs appear so you can customize each button independently — useful for tracking which button drives the most sign-ups (set different UTM params per button).

Phone number in the profile body

Separate from the header See Phone button, the profile body has a .table-display-phone row showing the actual digits. The engine treats this independently:

Common pattern: keep the header "Sign Up to See Phone" button visible as a sign-up driver, but still Hide or Mask the digits row so logged-out viewers can't read the number elsewhere on the page.

CTA card

The CTA card is the only piece the engine actually renders itself — everything else is BD's native rendering with overlays. Six fields control its content:

Design tab

The Design tab gives you complete visual control over the CTA card, sign-up button, and overlay effects. Everything else on the page inherits your site's native styling so the gated treatment blends in.

Colors

CTA card — Background, border, corner radius (Square / Subtle / Rounded / Pill), shadow (None / Subtle / Medium / Strong).

Headline & body — Heading color, subtitle color, login link color.

Sign-up button — Background, text color, size (Small / Medium / Large / Extra Large), corner radius (Square / Subtle / Rounded / Pill).

Typography

Full font control for every text element on the CTA card — each section lets you pick a font family, size, and weight:

CTA heading — Font family (15 fonts, each previewed in its own typeface), font size, weight (Normal through Extrabold).

CTA subtitle — Font family, font size, weight (Light through Semibold).

Sign-up button — Font family, weight (Normal through Bold). Button size is set in the Colors section.

Overlay effects

Cutoff fade — Fade height (None / Subtle / Medium / Strong) — controls how tall the gradient is before the CTA card sits below.

Paywall blur — Blur intensity with a live preview (Hint / Subtle / Medium / Strong) — controls how much of the content is readable behind the overlay.

Visibility Rules

Rules let you override the default mode behavior per viewer. They evaluate top-to-bottom and the first matching group wins — the engine returns a verdict and the consuming widget interprets it.

How rules are organized

Rules live in rule cards — one card per widget that reads the engine. Each widget you gate gets its own card in the authoring UI, so you can set independent rules for profiles, sidebars, search results, or any other gated widget.

Inside a card:

• A default action dropdown sets the verdict when no rule group matches
• One or more rule groups each return a specific verdict when their conditions match
• Groups can be enabled/disabled independently and reordered

The four verdicts

Different widgets interpret the verdicts in their own way. For example, a member profile maps hide to the cutoff fade, while a search-result card might map blur to a grayscale overlay.

Context keys — what you can match on

Operators

The operator dropdown filters automatically to only show operators valid for the chosen key's value type — so you won't see "auth > something" or "viewer_plan contains foo".

AND / OR — the alternating depth pattern

Rule groups use Simplero's alternating-by-depth pattern:

• The root of each group picks AND or OR — you choose at the top of the tree
• Nested groups alternate automatically — if root is AND, nested groups are OR, and groups nested inside those are AND again
• Each level shows a pill button labeled with its current operator — click it to flip the root, or to add a sibling/child condition

This keeps complex rules readable at a glance: you always know that a child level is the opposite of its parent.

Example rule patterns

Block paid-tier directories from logged-out viewers, free-tier from anyone

Default: show
Group 1: When (Viewed plan ID is one of: 5,7,12) → blur

Visitors hit the paywall on premium plans; everyone else sees full profiles.

Show full profile on mobile after hours, gate during business hours

Default: hide
Group 1: When (Device = Mobile) AND (Time of day >= 18 OR Time of day < 8) → show

Off-hours mobile visitors get full access; daytime visitors get the cutoff fade.

Always show admins the full profile, never gate them

Default: hide
Group 1: When (Viewer role = Admin) → show

Admins bypass the engine entirely.

Stale listings get blurred to encourage refresh

Default: show
Group 1: When (Listing age >= 365) → blur

Profiles over a year old get the paywall treatment so the member feels the pressure to update.

Integrations

The Visibility Engine talks to a couple of other DirectoryCustomize widgets when both are installed. Each integration appears as its own card on the Settings tab.

Highlighter integration

The Highlighter widget styles individual tabs (Reviews, Premium, etc.) with ribbons, glows, and animations. VE talks to it in two ways:

Both toggles are mirrored on Highlighter's own Configure panel — saving in either place updates the other. The CTA glow color also follows whatever Highlighter is configured for site-wide, so the brand color stays consistent.

DirectoryAds integration

When DirectoryAds is installed and Show ad slots behind paywall blur is on, ad slots render behind the blurred profile content in paywall mode. You monetize the impression even when the viewer can't read the profile. (Only applies in paywall mode — other modes either don't blur or don't cover the page.)

Common questions

Where it lives

In your DirectoryCustomize plugin admin: Plugins → DirectoryCustomize → My Widgets → Visibility Engine.

Three configuration tabs:

1. Profile Settings — mode picker, cutoff options, header button treatment, phone display, CTA card content, integrations, per-plan customization
2. Visibility Rules — per-widget rule cards with condition builder
3. Design — CTA card colors, typography (fonts, sizes, weights), fade height, paywall blur intensity

Saves apply immediately on the profile page — no rebuild or republish needed.

Need more help?

If a rule isn't behaving the way you expect:

1. Open the Visibility Rules tab and review your rule groups top-to-bottom
2. Check which group would match the visitor's context and what verdict it returns
3. If a group fires that shouldn't — review its conditions (the operator filter prevents most nonsense matches, but typos in text values can slip through)
4. If no group fires when one should — check that the group is Enabled (the checkbox at the top of each group)

Still stuck? Contact support with:

• Your directory URL
• The visitor's context (auth state, plan ID, device, page they were viewing)
• A screenshot of your Rules tab showing the groups in question