Liquid article pages: display content, translation notices and related knowledge

A useful article page lets a customer read the solution, check whether it applies, and find the next relevant step. sb.article contains the authorized knowledge article for the current page. It supplies the rendered body plus metadata and optional related lists, so a portal designer can improve presentation while preserving the publication and audience rules managed by the knowledge team.

What this object gives you  ·  Choose the correct page and customer context  ·  Supported values and how to use them  ·  Example: show the article and a useful translation alternative  ·  Design related knowledge around the customer’s next step  ·  Make and verify the change  ·  Common problems and recovery  ·  Keep the portal useful over time

What this object gives you

sb.article is a single article object, or null when no authorized article is available for the page. It is different from the compact rows in a topic’s article list. The full article’s content is the portal-rendered HTML; a list row is not a substitute for that body.

Language handling deserves an explicit design. If a requested translation is missing, translation_missing is true and the translated body is empty. A default-language link may be available. The template must not silently claim it is showing a complete translated article.

Choose the correct page and customer context

Use an article-page template with an actual article route and authorized article context. Related-in-container data also needs the selected container context. Public eligibility alone does not bypass topic, role or other portal audience rules.

Open the intended portal in Settings → Customer Portal, then choose Page templates. You need permission to administer communities or the applicable portal-edit override. Work on the existing page for this task; adding an object name to a different page does not make its records available. Keep existing forms, input names, navigation and scripts intact.

Liquid is a presentation language. Expressions inside {{ ... }} print values; statements inside {% ... %} control a loop or condition. A collection must be looped through before reading an individual row. These examples are display fragments to adapt within a working template, not replacement page templates.

Supported values and how to use them

Example: show the article and a useful translation alternative

{% if sb.article %}
 <h1>{{ sb.article.title | escape_once }}</h1>
 {% if sb.article.translation_missing %}
 <p>This article is not available in the selected language.</p>
 {% if sb.article.default_language_url != nil and sb.article.default_language_url != empty %}
 <a href="{{ sb.article.default_language_url | escape }}">
 Read in {{ sb.article.default_language_name | escape }}
 </a>
 {% endif %}
 {% else %}
 <div class="article-body">{{ sb.article.content }}</div>
 {% endif %}
{% else %}
 <p>This article is not available in this portal context.</p>
{% endif %}

This fragment preserves the distinction between a missing translation and an unavailable article. Keep the page’s existing feedback, navigation and article styling around it. Do not add a sign-in promise unless your portal configuration actually makes that article available after sign-in.

Design related knowledge around the customer’s next step

For an equipment fault article, a useful related link could explain how to collect diagnostic information or verify a repair. Show a short title and summary so readers can choose. Do not describe every automatically supplied suggestion as an approved troubleshooting sequence; the knowledge team should review the resulting recommendations.

{% for item in sb.article.related %}
 <p><a href="/article/{{ item.id | escape }}">{{ item.title | escape_once }}</a></p>
{% endfor %}

Make and verify the change

1. Write down the customer task this change should improve. For example, make the correct request or relevant knowledge easier to find. Decide what should appear when there is no data.
2. Copy the current template into your approved change record before editing. Add the fragment in the correct page context without removing functional controls.
3. Choose Save Changes to save the draft, then Design to preview it. Check a populated example and an empty or signed-out example as applicable.
4. Inspect desktop and narrow-screen layouts. Test long customer names, long titles, missing optional values, readable links and keyboard navigation.
5. Use Review changes → Publish when the draft is ready. A saved draft does not update the live visitor page.
6. Open the actual portal as an intended customer and follow the full task. Verify another relevant role or customer scope where visibility differs. Record the account, page, role and outcome with the change.

Common problems and recovery

Keep the portal useful over time

Keep the title, short summary and useful answer near the beginning of the page. Preserve meaningful article headings and descriptive related links. These practices help readers and answer retrieval understand the content; they do not guarantee search-engine placement.

Use clear labels and meaningful empty states. Do not display a raw ID when a customer needs a descriptive name, and do not describe an absent value as a service failure. After changes to portal roles, topic placement, custom fields or language coverage, revisit the relevant customer examples. A successful render alone does not establish that the instructions, links and customer visibility are still correct.

Continue learning

• Plan and publish a safe Liquid portal customization
• Display article comments safely
• Use compact article-list rows
• Configure the customer portal