Liquid topic article lists: ordered, latest and popular knowledge

A topic page should help customers choose an article without opening every result. Supportbench provides compact article lists for a selected knowledge container, including its normal order, latest content and popular content. Use each list for a clear purpose, and tell readers what the ordering means.

What this object gives you  ·  Choose the correct page and customer context  ·  Supported values and how to use them  ·  Example: display a topic’s article choices  ·  Choose a list for the operational purpose  ·  Make and verify the change  ·  Common problems and recovery  ·  Keep the portal useful over time

What this object gives you

sb.container_articles is the selected container’s article list. The related roots sb.container_articles_latest and sb.container_articles_most_popular provide alternate selections. Each is a collection; access title and other members inside a loop.

These are summary rows. The declared content member is blank in this list context; use the article page for the full solution. Popularity and recency are discovery signals, not proof that an article is applicable to the customer’s product or current configuration.

Choose the correct page and customer context

Use a knowledge-container page with a valid selected container. Root topic cards and article detail pages have different data contracts. Only records admitted by the portal’s article and audience rules should be expected.

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: display a topic’s article choices

<ul class="article-list">
{% for item in sb.container_articles %}
 <li>
 <a href="/article/{{ item.id | escape }}">{{ item.title | escape_once }}</a>
 {% if item.summary != nil and item.summary != empty %}
 <p>{{ item.summary | escape_once }}</p>
 {% endif %}
 </li>
{% else %}
 <li>No articles are available in this topic for the current portal context.</li>
{% endfor %}
</ul>

A useful summary for a recurring equipment problem states the symptoms, relevant model or configuration, and what the procedure helps the reader do. “Click here for more information” does not help a customer choose between similar results.

Choose a list for the operational purpose

Avoid placing three near-identical long lists on the same page. Start with the customer’s decision, then use the smallest set of sections that makes that decision easier.

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

Review titles and summaries when agents repeatedly send customers the wrong article. The list is an operational decision aid: the customer should recognize the product, symptom or task before opening the page.

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
• Navigate knowledge topics
• Render a complete article page
• Configure the customer portal