Discriminate by Content Type
Not every source should look the same. A product should render as a product card, a PDF as a document card, an FAQ as a quote. The content type on a reference — reference.type — is how you branch, and it's the same content type you set on a job's Contents settings.
The Pattern: A Template per Content Type
The default highlighted card handles the built-in types (FILE, PAGE, and untyped). For any other type, it looks for a template named exactly after the type and renders that:
{% assign referenceType = reference.type | default: "" | strip %}
{% if referenceType == "" or referenceType == "FILE" or referenceType == "PAGE" %}
{% include 'default-card' %}
{% elsif referenceType | hasTemplate %}
{% include referenceType %} {# e.g. content type "PRODUCT" → the PRODUCT template #}
{% else %}
{% include 'fallback-card' %}
{% endif %}
So to give a content type its own look, you:
- Set that content type on the data capture job (or content) — say
PRODUCT. - In the Advanced editor, add a template named
PRODUCTwith the Liquid for that card.
Inside your PRODUCT template, the current reference is still in scope:
<div class="product-card">
<h4>{{ reference.title }}</h4>
{% if reference.metaOgImageURL %}<img src="{{ reference.metaOgImageURL }}"/>{% endif %}
<a class="buy" href="{{ reference.url }}">View product</a>
</div>
Discriminating by Source (Dataset)
reference.dataset is also available, so you can render differently by where the content came from:
{% if reference.dataset == "Product catalog" %}
{% include 'PRODUCT' %}
{% else %}
{% include 'default-card' %}
{% endif %}
Tags vs. content type
Today, per-reference branching is driven by content type (reference.type) and dataset (reference.dataset) — the tags you attach to content in a dataset aren't surfaced on the reference object inside templates. Use the content type to drive a custom visualization; reach for the dataset to tell sources apart.