Labels and Series

A label is one tag that can do three unrelated jobs at once. It can be a reader-facing topic index, so everything about pricing turns up on one page. It can be a series, so five posts read in a deliberate order with navigation between them. And it can be an access scope, so one teammate publishes everything carrying Product and stays read-only everywhere else. You switch each job on independently, and a label that does none of them is still useful as a private organizational tag.

Labels are created and configured in Settings → Labels. You attach them to a page from the Labels field in the editor’s Page settings tab — see Page Settings.

Creating and configuring a label

Type a name into the Label Name input at the top of the screen to create one. Expand any label in the list to configure it. Every field autosaves as you type — there is no Save button.

The Slug field slugifies what you type as you type it, and finishes the job when you leave the field, so Product Updates becomes product-updates. If a label’s slug has been locked, the field is read-only and the panel explains why: “Slug is locked due to published pages.” A label can also be locked outright, in which case every field on it is disabled.

Job one: a reader-facing topic index

Check Use as Index — described on the screen as “For labels that you want to show to readers as clickable links to an index.” — and the label becomes visible to your site with a slug of its own. It then appears in your site’s labelList.json and in the per-page-type label collections your templates iterate, which is what a topic page is built from.

Be clear about the division of labor here, because it is the thing people expect Leed to do and it does not: the URL and the appearance of a topic page come entirely from your templates. The label supplies a name, a description and a slug. Whether that becomes /blog/topic/design/ or /tags/design/, and what the page looks like, is a template you write. The collections a label produces are enumerated in Collections and Pagination Data, and the rendering pipeline they plug into is How Templates Work.

The sitemap side of the same thing is Label Sitemap Priority, which is a page-type override rather than a label field — see Configuring a Page Type.

Leave Use as Index unchecked for internal tags. An invisible label still groups pages in the CMS, still drives series ordering, and still works as an access scope — it just never reaches a reader.

Job two: a series

Check Use as Series — “For grouping pages into a linked series.” — and pick a flavor. The two behave differently enough that the choice matters.

Multi-Part is for content that reads in sequence — a five-part guide, a course. Announcement is for a running stream where only the newest matters — release notes, status updates, a changelog.

How the starter blog layout renders each flavor

The blog.hbs layout that ships in your site repository renders both flavors out of the box, above the page body.

A multi-part page gets a <section class="multipart-series"> holding the series name, the series description, and an ordered list of every part oldest-first. The part you are reading is rendered as plain text; the others are links.

An announcement page gets a <section class="announcement-series"> reading “Find this page useful? This page is part of the series: [series name]. The latest page in the series is [link to the newest part].” — shown on every page in the series except the newest one, which would otherwise link to itself.

State this to yourself plainly before you promise it to anyone: that is the shipped starter layout, not a platform behavior. If your developer has rewritten blog.hbs, or your page type uses a different layout, your site renders whatever that layout renders. Leed publishes the series data; the template decides what a reader sees.

A multipart page instead gets a <section class="multipart-series"> above the article body, holding the series name, its description, and the ordered list of parts — with the part you are currently reading rendered as plain text rather than a link, so the box doubles as a position indicator.

Rendering a series in your own templates

Five helpers cover series in templates. Three iterate:

• Series — every page of the label’s series, whichever flavor it is
• MultipartSeries — only when the label is a multi-part series
• AnnouncementSeries — only when the label is an announcement series

And two gate a block on the flavor, setting the label object as the block’s context:

• IfMultipartSeries
• IfAnnouncementSeries

Inside an iterating block, each item carries index (1-based), total, isFirst and isLast, with @index (0-based) on the data frame — which is enough to build a “part N of M” caption or a next-installment callout. This is the multi-part block from the shipped blog.hbs, and it is the pattern to copy:

{{#each this.labels}} 
  {{#IfMultipartSeries this}} 
    <section class="multipart-series">
      <p class="series-name">{{ this.name }}</p>
      <p class="series-description">{{ this.description }}</p>
      <ol>
        {{#MultipartSeries ../this }} 
          {{#eq this.data.page.url ../../../page.url }}
          <li class="current-series-page">{{ this.data.title }}</li>
          {{else}}
          <li class="series-page"><a href="{{ this.data.page.url }}">{{ this.data.title }}</a></li>
          {{/eq}}
        {{/MultipartSeries}}
      </ol>
    </section>
    <hr>
  {{/IfMultipartSeries}}
{{/each}}

Note the two different arguments. IfMultipartSeries this takes the label id from the {{#each}} and switches the context to the label object, so {{ this.name }} inside is the label’s name. MultipartSeries ../this has to reach back up one frame for that same id, because this now means the label. And ../../../page.url climbs back out to the page being rendered so the current part can be left unlinked.

Two constraints the helpers do not announce:

Full parameter tables for all five helpers are in Collection, Lookup and Series Helpers.

Job three: an access scope

Each label’s panel carries a row of role-override pickers — Content Manager, Approver and Contributor — that elevate a chosen teammate on every page carrying that label. A Content Writer can be made a Content Publisher for everything tagged Product, and stay a writer everywhere else. It is the tool for letting a team own a slice of the site without giving them the site.

The one thing that makes this different from every other label setting: a label-scoped grant takes effect in the CMS immediately and never needs a publish. It is CMS access control, not site data, so there is nothing to deploy. The person can act on it the moment you save.

Granting a role on a label is one of several override kinds, and how an override combines with a person’s base role — the stronger of the two wins — is on Resource-Level Access Overrides.

Labels on a page type

A page type can carry labels of its own, set on its panel in Settings → Page Types. Those labels describe the whole section rather than a single page, and they reach your templates and feeds alongside the section’s other data — useful for a section-level topic or a routing tag your templates key off. They are covered with the rest of the page-type fields in Configuring a Page Type.

When label changes reach your site

Name, slug, description, series settings and visibility are site-facing data. Changing any of them marks the label with the amber unpublished indicator and queues a single Labels entry in the pending list on the Deploy screen — one entry for all your labels, not one per label. Publishing it rewrites _data/labelList.json in your site repository and rebuilds. See Publishing Changes.

Role overrides are the exception and do not queue anything, as above.