Liquid string filters: clean, shorten and safely display portal text

String filters help turn a long subject, customer label or short explanation into readable portal text. Use them to improve presentation while keeping the original meaning accessible. The supported Core filter names differ from examples written for Shopify, so copying a familiar name can produce missing or misleading output.

Start with the practical purpose  ·  Syntax and supported behavior  ·  Example: shorten a request subject without losing the full case  ·  Preserve line breaks in a plain-text message safely  ·  Replace unsupported names in older examples  ·  Apply the example in a working portal page  ·  Troubleshoot the common mistakes  ·  Keep the customization understandable

Start with the practical purpose

A string is text. Filters can trim whitespace, change case, replace a substring or shorten a preview. These transformations do not change the stored case, article or contact. Use them sparingly on identifiers or diagnostic text where exact punctuation matters.

Apply safe output at the HTML boundary. Plain customer names and search text need escaping. Already encoded subject/summary members may need escape_once. A renderer-supplied article body is a different content type and should follow its specific object guide.

Syntax and supported behavior

Example: shorten a request subject without losing the full case

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

Keep the link to the complete request. If two subjects become indistinguishable after truncation, show the case ID or use a larger preview. Readability should not make it harder to select the correct equipment incident.

Preserve line breaks in a plain-text message safely

{% capture message %}Include the equipment model.
Describe the symptom and when it began.{% endcapture %}
<p>{{ message | escape | newline_to_br }}</p>

Escaping occurs before the formatting filter adds its own line-break markup. Reversing the order can display the generated break tags literally. For article comments that already contain break markup, use the comment guide’s safe approach rather than assuming this plain-text recipe applies unchanged.

Replace unsupported names in older examples

The current supported guidance does not use camelcase, handleize, md5, pluralize, url_escape or url_param_escape. Use the catalog’s actual names and signatures. For localization/plural messages, use the Supportbench translation workflow and tp filter where appropriate, rather than a store-specific pluralize example.

The url_encode filter does not apply the custom url_encoded tag’s legacy dot/slash/backslash-to-plus transformation in the current installed renderer. Do not confuse these two names. Preserve supplied portal URLs whenever possible instead of constructing new encodings by guesswork.

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

Keep the customization understandable

Keep full diagnostic details available in the linked record. A preview should improve scanning without removing model numbers, error identifiers or other details customers need to distinguish similar issues.

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.

Continue learning

• Customize and publish portal pages with Liquid
• Understand filter order and safe output
• Use localized formatting
• Distinguish custom URL tags