Skip to content
Help Center
Submit a request Sign in

Liquid blank values: understand truthy, false, nil and empty

A bare if check does not tell you whether a label contains useful text. In Liquid, empty strings, zero and empty collections are truthy. Correct blank checks help you avoid empty company headings, broken avatar images and misleading customer states.

At a glance

For: portal administrators and designers, including people new to Liquid. Applies to: Supportbench Core.

Start here: Settings → Customer Portal → select the portal → Page templates

Start with the practical purpose  ·  Syntax and supported behavior  ·  Example: avoid a blank company label  ·  Use for/else for an honest list empty state  ·  Treat zero and missing values separately  ·  Apply the example in a working portal page  ·  Troubleshoot the common mistakes  ·  Keep the customization understandable

Start with the practical purpose

“Truthy” means a value passes a simple condition such as {% if value %}. Only boolean false and nil are falsey in the current DotLiquid behavior. This differs from languages where zero or an empty string is treated as false.

Use blank when asking whether a text value or list lacks meaningful content. Use an explicit numeric comparison when zero has business meaning. Do not use a display check as proof of customer authorization.

Syntax and supported behavior

Value or comparisonResult and consequence
false / nilFalsey in a bare if.
"" / 0 / empty collectionTruthy in a bare if. These can still produce empty headings or zero totals.
value == emptyMatches an empty string/list/map; does not treat whitespace-only text as empty.
value == blankHandles nil, false, empty values and whitespace-only text in this renderer.
list.size > 0Tests whether a supplied collection has rows. A for/else block is often clearer for rendering it.
number > 0Tests a positive numeric value. Use the appropriate rule rather than if number.

Example: avoid a blank company label

{% if sb.profile %}
 {% unless sb.profile.company == blank %}
 <p>Company: {{ sb.profile.company | escape }}</p>
 {% endunless %}
{% endif %}

This checks the profile context first and then the actual company text. A profile can be valid while company is blank, and neither outcome says whether the contact may see company-wide cases.

Use for/else for an honest list empty state

{% for request in sb.cases %}
 <p>{{ request.subject | escape_once }}</p>
{% else %}
 <p>No requests are available in the current list.</p>
{% endfor %}

Do not write “You have never contacted support” merely because this list is empty. Filters, paging, account context and visibility can affect which records are supplied. A narrowly accurate message is more useful than an unsupported conclusion.

Treat zero and missing values separately

A zero open-case count can be a legitimate value, while a missing customer context can also yield default zeros in a summary model. Check the relevant signed-in context before presenting the number as personal history. For numeric configuration flags, compare the documented value explicitly; a bare if on zero still passes.

Apply the example in a working portal page

  1. Open the intended portal’s Page templates with permission to administer communities or the applicable edit override. Choose the page that supplies the object used by your example.
  2. Preserve a copy of the existing template in your change record. Keep the working forms, routes, input names and script hooks; these examples change presentation.
  3. Make the smallest useful edit, then choose Save Changes → Design. Inspect populated, empty and signed-out preview states as relevant.
  4. Check punctuation, long text, optional values and narrow-screen layout. Confirm the result says what you intend, not merely that it renders.
  5. Use Review changes → Publish for the approved design. Then verify the actual portal as the intended customer and check the full task.

Designer preview data is synthetic. A successful preview confirms neither real customer access nor the effect of a server-side workflow. Liquid cannot grant permission, edit a case or fetch arbitrary database records.

Troubleshoot the common mistakes

ProblemCorrection
An empty heading appears despite if valueUse unless value == blank for text.
A numeric flag set to zero still enters the branchZero is truthy. Use the documented numeric comparison.
Whitespace produces a visible empty blockempty does not catch whitespace-only text; blank does.
An empty default object is treated as a real recordCheck meaningful members or the supplied collection, not object existence alone.

Keep the customization understandable

Write down the expected behavior for missing, empty, zero and false separately. Testing these four cases often catches defects that a single populated preview cannot reveal.

Use descriptive local variable names and keep conditions close to the content they control. Record the customer scenario tested when publishing a change. Recheck the template when its source fields, portal role rules or supported language behavior changes.

Was this article helpful?