5. Creating Pages

The pages Tab 🟢

pages controls every standalone page on your site — your homepage, your About page, your Browse and Map views, and any custom pages you add (a "How to Cite" page, a methods essay, and so on). It's marked light green: safe and expected territory, one tier down from main-metadata and config but still meant to be edited freely.

Every row is one page. Unlike main-metadata, where every row is the same kind of thing (a collection item), pages mixes two different kinds of rows — it's worth telling them apart before you start editing.

Two kinds of rows

1. Built-in pages — rows whose filename matches a site feature CB-Remix already knows how to build: index, browse, map, data, locations, timeline, search, subjects, item. These power core parts of the site (the homepage, the map view, the search page, and so on), so their filename and layout are fixed — don't rename or delete these rows. Their permalink is usually left blank, since the site places them automatically. What you can edit is their title and content — for example, adding an introductory paragraph above the data table on the Data page.

2. Custom pages — rows you add yourself for free-form content: about, contribute, how-to-cite, method, and a custom visualization page (neomorphemes-over-time) in this example. These need an explicit permalink (the URL the page lives at) and a layout of page (plain text) or default (for embedding things like an iframe). Add as many of these as your project needs, following the same pattern.

Structure

Column	What it holds
filename	The page's internal ID/slug. For built-in pages, this must match the exact expected name (see list above). For custom pages, pick any short, lowercase, hyphenated slug.
title-in-<Lang1> / title-in-<Lang2>	The page's title, in each site language. Header text is auto-generated from config, same as on main-metadata.
content-in-<Lang1> / content-in-<Lang2>	The page's body text, written in Markdown. Headings (#, ##), links ([text](url)), and basic HTML are all supported — the template even embeds a raw <iframe> for the custom visualization page.
permalink	The URL path the page will be published at (e.g. /about.html). Required for custom pages; leave blank on built-in pages so the site can place them automatically.
layout	Which template renders the page. Built-in pages need their matching layout (home-infographic, browse, map, data, cloud, timeline, search, item); custom pages use page for plain text or default for something more custom, like an embed.
extra-metadata	Optional, layout-specific settings. See below.
comments	Left blank throughout this template — treat it as free notes for your own team rather than something the site reads, unless you've confirmed otherwise for your build.

About extra-metadata

A few layouts accept extra settings here, written as key: value:

• The About page in this template uses credits: true to turn on a credits section.
• The locations and subjects pages both use the cloud layout (a word-cloud style browse view), and each points to a different data source via cloud-fields: site.data.theme.locations-fields or cloud-fields: site.data.theme.subjects-fields — these field lists are themselves defined on config-theme, so the two need to stay in sync.

If you add a new cloud-layout page, use the same cloud-fields: site.data.theme.<something>-fields pattern, matching a field list you've defined on config-theme.

Common mistakes to avoid

• Renaming or deleting a built-in page's filename (e.g. changing browse to something else) — the site looks for these exact names to build core features.
• Adding a new custom page but leaving permalink blank — without it, the page has no URL and won't be reachable.
• Misspelling layout, or using a layout name that doesn't exist — double-check against the built-in list above for existing pages, and use page or default for new ones unless you know you need something else.
• Filling in content-in-<Lang1> but leaving content-in-<Lang2> empty on a custom page — for a bilingual site, both should generally be written out in full (this doesn't apply to built-in pages like map or search, where blank content on both sides is normal and expected).
• Setting cloud-fields to a field name that doesn't actually exist on config-theme — the page will render with an empty cloud instead of an error, which can be confusing to debug.

As with every tab, changes here don't reach your live site until you run Sync content from Spreadsheet in GitHub Actions.