Why a collection, not a “global settings” doc?

Birkly uses collections + entries only. Shared layout content is still entries — usually one entry per region (header, footer). That keeps versioning, drafts, multilanguage, and the Public API consistent with the rest of your content.

Setup steps

1. Create collection — Name: “Site elements”, handle: site-elements.
2. Fields (example):

- Title (text) — admin label, e.g. “Header”. - Blocks (Dynamic items) — logo, nav links, CTA buttons, legal links.

1. Create entries — one per region:

- Entry slug header — main site header blocks. - Entry slug footer — footer columns and copyright.

1. Publish entries when ready (status Published).
2. On your site, bind regions:

<birkly-region collection="site-elements" entry="header" field="blocks"></birkly-region>

<main><!-- page-specific content --></main>

<birkly-region collection="site-elements" entry="footer" field="blocks"></birkly-region>

The Birkly client fetches live content and hydrates the region. See Web components and Choose your stack.

Multilingual sites

Enable multilanguage on the site-elements collection. Edit Blocks per language tab so header/footer copy matches each locale. Regions respect the active site language when configured.

When not to use site elements

| Scenario | Better pattern | |----------|----------------| | Many similar items (blog posts, products) | Regular collection + list/detail templates | | Child rows on one page (comments) | Sub-collections | | One long article | Single entry with Content editor field | | Visitor-submitted data | Public API collection — Public forms |