Configuration

Config flows one way: site.Params into _partials/init.html, which resolves defaults once, and out to the templates. Templates read resolved values and never re-derive a default inline, so every default below lives in exactly one place in the source.

Site parameters#

[params.author]#

Several authors#

[params.author] is the single, site-wide author, and a site that only ever has one needs nothing else. For more than one, put a file per person in data/authors/ and name the keys in a post’s front matter:

# data/authors/ada.toml
name = "Ada Example"
headline = "Invented the demo co-author"
image = "images/ada.png"
links = [{ link = "https://example.com" }]

# in the post
authors: ["morten", "ada"]

A post that says nothing about authors falls back to [params.author], which is what keeps this backward compatible: an existing site renders exactly what it rendered before.

A key with no matching file fails the build. A post crediting somebody who then does not appear is the kind of bug nobody notices until the person asks why their name is missing.

Registering author = "authors" under [taxonomies] gives each author a page listing what they wrote; showAuthorsBadges then links the byline names to them.

Writing a bio in TOML has one trap. A """ string keeps its indentation, and Markdown reads four leading spaces as a code block, so a bio indented to line up with the keys around it renders as a grey <pre> slab rather than as prose. Keep the continuation lines flush left — exampleSite/hugo.toml shows the shape, and the test suite asserts the bio never renders as a code block.

[params.home]#

[params.article]#

The edit link on the page you are reading is live. It points at this file in the theme’s own repository, built from editURL plus the content path.

Sharing links#

Eleven services are supported. Any post on this site shows the row live at the foot of the article.

Every one of these is a plain link. No script, no SDK and no widget is loaded, so nothing is requested from any of these services until a reader actually clicks. That is why the list is limited to services with a documented share URL — a provider needing a script would put a third-party request on every article page for a button most readers never press.

mastodon needs mastodonInstance. Mastodon is federated, so there is no central host to post to: the share URL belongs to an instance. A static site cannot know the reader’s own instance, and routing through a third-party instance picker would be a call to somebody else’s server on every click, so the site names the instance instead. Listing mastodon without setting mastodonInstance fails the build rather than quietly dropping the button.

email opens a mail client, not a website, so it is the one entry with no target="_blank" — opening a mailto: in a new tab leaves an empty tab behind in most browsers.

[params.list] and [params.footer]#

[params.verification]#

Public ownership tags. Each renders only when its key is set, so a site that verifies nothing emits nothing.

Menus#

A menu entry with children renders as a disclosure panel rather than a hover dropdown, because hover menus are unreachable by touch and awkward by keyboard. The Docs entry in the header above is one; open it and look at how it behaves with the keyboard alone.

[[menu.main]]
  identifier = "docs"
  name = "Docs"
  pageRef = "docs"
  weight = 20

[[menu.main]]
  parent = "docs"
  name = "Configuration"
  pageRef = "docs/configuration"
  weight = 2

One level only. A blog that needs three wants a landing page, not a bigger menu.