BriterWrite. Publish. Own it.

Documentation

Sections

JSON-defined highlight and list sections that bind posts to site routes — the generic replacement for hardcoded homepage/featured logic.

Sections

A section declares which posts appear and in what order on a route the site already renders — for example, the newest-first list on /notes or the single highlighted note on the homepage. Sections are content configuration, not pages: Briter never builds or styles a page. That stays true to the Constitution ("Not a page builder").

Sections replace the older site-specific hardcoded homepage/featured logic with a generic, portable mechanism. Manage them in the admin UI at /sections.

How sections are stored

Each section is one JSON file under content/sections/ (BRITER_SECTIONS_ROOT), named <id>.json. These files ride the existing git-sync — content/ is already on every adapter's allowed-path list (see Adapters) — so publishing a section change needs no adapter change. The shape is the locked contract shared byte-for-byte between Briter (which authors sections) and the external site (which reads and renders them); it is defined in lib/sections/types.ts.

Section shape

Field Type Notes
id string Unique identifier; also the filename.
type highlight | list highlight features a small number (usually one); list renders many.
enabled boolean Whether the site renders the section.
page string Required for list — the route the list renders on (e.g. /notes). A highlight is placed by the site (e.g. the homepage) and may omit it.
source all | tag | manual Where members come from.
tag string Used when source: tag.
slugs string[] Used when source: manual — explicit membership and order.
order published-desc | published-asc | manual Sort order; manual follows slugs.
count number Optional cap. Highlight: usually 1. List: omit for uncapped.

Built-in defaults

Two sections ship with both Briter and the site, so a fresh install renders correctly with zero configuration (BUILT_IN_SECTIONS in lib/sections/types.ts). They are surfaced even before any file exists on disk; editing one writes a real JSON file that then overrides the in-memory default.

notes-list — the default /notes list, newest-first:

{
  "id": "notes-list",
  "type": "list",
  "enabled": true,
  "page": "/notes",
  "source": "all",
  "order": "published-desc"
}

homepage-latest — the homepage highlight, auto-tracking the latest note:

{
  "id": "homepage-latest",
  "type": "highlight",
  "enabled": true,
  "source": "all",
  "order": "published-desc",
  "count": 1
}

By default the homepage highlight auto-tracks the newest note (count: 1, newest-first). Setting source: "manual" plus slugs pins a specific note; clearing the pin falls back to the auto-latest behaviour. This is the generic replacement for the legacy _featured.json, consistent with the project's decision log ("No _featured.json porting").

Editing sections

Use /sections in the admin. Saving a section writes its JSON file to content/sections/ and enqueues a git-sync job (publishing is the queue's job, not the store's), so the change reaches the site through the same pipeline as a post.