Shortcodes

Shortcodes are the in-body links between content pieces. A page or post body can point at a block, a stack, a document, or a form, and the static builder resolves each reference at build time; inserting the real render, never a placeholder. Four shortcodes exist; everything else (page lists, related content, galleries, videos) is a block type used through the {{block:name​}} family rather than a different syntax.

The four families

• {{block:name​}}: one reusable block. Renders the named block’s template output exactly where it sits in the body. Block names are unique per language; a language’s content references its own language’s edition, falling back to a language-free copy when this language’s edition is missing.
• {{stack:name​}}: one reusable stack. Stacks resolve fully: nested stacks resolve recursively (with the cycle/depth safety cap), then the stack’s layout wrapper applies, so a placed stack reads like a whole section inside the body.
• {{document:slug​}}: a published document link: looked up from the build cache, rendered as the link to /documents/<slug> (the CMS-tracked download endpoint your host’s proxy routes to the CMS).
• [form:slug​]: an embedded form: rendered inline when the slug is active at build time; falls back to a CMS-hosted iframe when only cms_base_url is configured; otherwise a build error.

Where shortcodes run

• Only in body text: page and post bodies (and landing page bodies share the same families). Titles, slugs, menu labels, and URLs do not process shortcodes.
• No template-level logic inside shortcodes: no conditions or loops at this layer. Conditional rendering lives in blocks (each its own TT file), not in the shortcode syntax.
• All four families resolve in the same render pass in any theme template, including raw and landing page bodies, which can be assembled from the same building material.

Broken references are build errors

A shortcode pointing at something that doesn’t exist (a block/stack name with no matching edition, a missing or unpublished document slug, an inactive form) leaves an HTML marker comment in the built page (<!-- form:<slug> not found --> and friends) and is recorded as a build error naming the shortcode and the reason. The promotion guard sees those like any pre-promotion failure, so a broken reference cannot ship silently; fix the reference (or publish/restore the target) and rebuild.

Choosing between them

• Blocks: the atom for content composition (hero, CTA, quote, gallery…); reference one wherever its single instance belongs.
• Stacks: a complete ordered section in one reference (shared feature rows, standing CTA groups, campaign sections).
• Documents: the tracked-download path; because replacement keeps the slug, built references survive updates.
• Forms: the submission surface; with cms_base_url set, embedding works even when the page is hosted away from the CMS.

They nest freely: a block can live inside a stack inside a body, and a form can sit inside a block; the builder resolves everything that appears in active content.