Liquid discussion pages: display sb.topic, posts and attachments

A discussion page should help a customer follow the problem, read the responses and recognize the relevant outcome. sb.topic supplies a selected community discussion and its posts. Use it to improve that reading experience while keeping the portal’s existing reply, attachment and access behavior intact.

What this object gives you  ·  Choose the correct page and customer context  ·  Supported values and how to use them  ·  Example: display discussion posts with attachment links  ·  Present an outcome without hiding the reasoning  ·  Make and verify the change  ·  Common problems and recovery  ·  Keep the portal useful over time

What this object gives you

sb.topic is the discussion object; sb.topic.posts is its collection of posts. An admitted topic context is required. When no usable discussion is available, the runtime can provide an empty object rather than a useful populated record, so check meaningful members or the post list instead of relying only on object truthiness.

Answer metadata describes the discussion’s recorded state. It does not independently certify that a response is safe or suitable for every customer’s equipment, configuration or contractual scope.

Choose the correct page and customer context

Use the selected discussion page, normally reached through /topic/ and the discussion identifier. A forum directory and a forum’s topic list do not supply the same full post object. Preserve the existing form and permission branches for posting or selecting an answer.

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 discussion posts with attachment links

{% for post in sb.topic.posts %}
 <section class="discussion-post">
 <h2>{{ post.title | escape_once }}</h2>
 <p>{{ post.posted_by | escape }} · {{ post.posted_on | ldate | escape }}</p>
 <div class="post-body">{{ post.content }}</div>
 {% for attachment in post.attachments %}
 <p><a href="{{ attachment.path | escape }}">{{ attachment.name | escape }}</a>
 ({{ attachment.size | format_bytes | escape }})</p>
 {% endfor %}
 </section>
{% else %}
 <p>No discussion posts are available in this context.</p>
{% endfor %}

The supplied post content is prepared for the discussion renderer: agent content may retain HTML, while customer content is encoded with line-break handling. Do not substitute an unrelated raw input field for post.content or remove the surrounding page’s security behavior. Attachment names and paths still need safe attribute/text output.

Present an outcome without hiding the reasoning

For a complex equipment issue, the final fix may only make sense after earlier diagnostic steps. If your existing page highlights the selected solution, retain access to the other posts so the customer can understand the conditions and failed approaches.

When the answer should become reusable guidance, have the support team create or improve an appropriately scoped knowledge article through KCS. A discussion can contain account-specific assumptions that need review before becoming general instructions.

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 author, date and outcome presentation understandable. Community answers may be useful evidence, but account-specific diagnoses and customer commitments should stay connected to the authorized case process.

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 the discussion list
• Turn reusable answers into reviewed knowledge
• Configure the customer portal