Liquid filters: format portal values safely and predictably

Updated Wednesday, October 28, 2026 · Marc Staine

Filters transform a value for presentation—for example, trimming a label, shortening a preview, formatting a date or escaping text for HTML. They help make a portal readable without changing the saved customer data. A well-chosen filter should preserve meaning and use the exact names supported by Core.

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: make a short, safe request preview · Choose safe output deliberately · Use the current filter catalog · Apply the example in a working portal page · Troubleshoot the common mistakes · Keep the customization understandable

Start with the practical purpose

An output expression begins and ends with double braces. The vertical bar, called a pipe, passes a value to a filter: {{ value | filter }}. A colon introduces an argument, and commas separate additional arguments. Multiple filters run from left to right.

Filters work on the supplied value. They do not fetch an additional case, change an article’s visibility or perform an API update. Choose a filter that matches the member’s type and the intended output context.

Syntax and supported behavior

Pattern	Meaning
{{ label \| strip }}	Remove surrounding whitespace from text.
{{ label \| truncate: 80 }}	Shorten a display string according to the filter’s character limit. Keep the full value accessible where needed.
{{ label \| replace: "Old", "New" }}	Replace matching text for this rendering; the saved record is unchanged.
{{ value \| strip \| escape }}	Trim first, then safely encode text for HTML.
{{ date_value \| ldate \| escape }}	Format a date using the portal locale, then escape the text. This does not convert timezones.

Example: make a short, safe request preview

{% for request in sb.cases %}
 <p><a href="/case/{{ request.id | escape }}">
 {{ request.subject | strip | truncate: 100 | escape_once }}
 </a></p>
{% endfor %}

This limits the preview label, not the saved subject. Keep the link to the full request so a customer can distinguish similar incidents. For an already encoded subject, escape_once avoids unnecessary double-encoding.

Choose safe output deliberately

Use escape for plain dynamic text and HTML attributes. Use escape_once when a documented member can already contain encoded text. A full article or activity body supplied for its intended renderer is different: escaping the entire body displays HTML code instead of formatted content.

Do not treat strip_html as a general-purpose security system for every context. For a simple plain-text display, strip markup and then escape the result. Do not insert text into executable JavaScript just because it was HTML-escaped. The old json filter examples are not supported Core guidance.

Use the current filter catalog

Core uses DotLiquid standard filters plus Supportbench’s format_bytes, format_empty, t, tf, tp, lnumber and ldate. Use the current designer catalog for exact signatures. The array, string and formatting guides below group the supported filters by task.

Names copied from another Liquid platform—such as handleize, md5, pluralize, default_pagination, highlight or weight_with_unit—are not automatically supported here. Replacing an unknown name with a similar-looking one without checking the result can change meaning.

Apply the example in a working portal page

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.
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.
Make the smallest useful edit, then choose Save Changes → Design. Inspect populated, empty and signed-out preview states as relevant.
Check punctuation, long text, optional values and narrow-screen layout. Confirm the result says what you intend, not merely that it renders.
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

Problem	Correction
An unknown filter appears in an old example	Check the installed Core catalog and replace the example with a supported operation.
Changing filter order changes the result	Filters run left to right. Decide which transformation must happen first and test the final text.
HTML appears literally	Check whether you escaped a supplied rendered body rather than a plain-text value.
The output looks correct but the saved value is unchanged	Expected. Filters affect rendering only.

Keep the customization understandable

Keep formatting close to the output boundary. Avoid long filter chains that obscure whether you are handling plain text, encoded text, a number or rendered HTML.

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?