Guide

Reference

Platform

blog-template is a finished reference site. Clone it into a new app, then replace the copy, images, theme and config before launch.

Abstract illustration of a diagonal stack of blog entries

A finished reference site you clone, then make your own.

This site is a template. Every page you can see — the home page, the blog, the privacy, terms and cookies pages — exists so that a new site can start from something finished instead of something empty.

## How it is meant to be used

You do not edit this site. You **clone** it into a new app namespace, and then you change the copy, the images and the theme until nothing of the template is left. The clone is a straight copy of every content entry under this app, rewritten under the new app's name. Cross-references between entries are preserved, so the new site renders exactly like this one on the first build.

## What to change before you launch

- **Copy** — every page here is written to read as real content, not as filler. That is deliberate: it sets the quality bar. Replace it with your own.
- **Images** — the illustrations are a small, coherent SVG set. Swap them for your own artwork and update the alt text.
- **Theme** — colours, fonts and spacing come from a shared default. Your site overrides them in two small files. See *Theming a cloned site*.
- **Config** — the site name, domain and analytics id live in one settings entry. Point them at your site.

## Why a template at all

Standing up a site by hand means recreating the same page structure, the same navigation and the same policy pages every time, and getting some of it subtly wrong. Starting from a known-good copy means the structure is already correct and the only work left is the work that is actually yours: the content.

What this template is

Pages, standard-content blocks, renderers and slugs: the four entry types that do most of the work on every site built from this template.

Abstract illustration of angular panels stacking into a page

Pages, standard-content blocks, renderers, slugs — how they fit together.

Four kinds of entry do most of the work on every site built from this template. Once you can see how they fit together, the rest of the model follows.

## Pages

A **page** is a route. It has a slug (the bit in the URL), a template, and a list of content entries. A page holds almost no text itself — it is a container that says *what* appears and *in what order*.

## Standard-content blocks

A **standard-content** entry is a titled block of text and links — an intro paragraph, a section of body copy, the copyright line in the footer. Most of the words on this site are standard-content blocks. Each carries a class name that hooks it to a style rule.

## Renderers

A **renderer** decides how an entry is drawn. The same standard-content block rendered three different ways gives you a hero, a card or a plain paragraph. Renderers are content, not code — they point at a component by path and can be swapped without a deploy.

## Slugs

A **slug** entry maps a URL to a page. Keeping the URL separate from the page means you can change one without disturbing the other, and support more than one language.

## Putting it together

A request for `/privacy-policy` finds the slug, which points at a page, which names a template and a list of blocks, each of which names a renderer. The build walks that tree once and emits static HTML.

The content model in one page

A cloned site inherits a shared visual floor. Your own look is a small set of token and component overrides in two files.

The shared floor, and the two files where your site’s look actually lives.

A cloned site already looks finished because it inherits a shared visual floor. Your site's own look is a small set of deltas on top of that floor.

## The floor

The shared styles package defines the default tokens — colours, type scale, spacing — and the structural rules for the header, the main column and the footer. Every site gets this for free. On this template, the floor *is* the design: there are no overrides.

## Where your overrides go

Each app owns a `src/styles/` directory with two files that matter:

- **`custom-variables.css`** — override the design tokens. A new brand colour, a different heading font, a wider content column: these are one-line changes here.
- **`custom.css`** — component-level rules that only your site needs.

The import order is fixed: variables first, then the shared base, then your component overrides. Variables must be declared before the base consumes them.

## Fonts

Fonts are loaded in the app and referenced by token. Change the token in `custom-variables.css` and the whole site follows.

## A good rule

If you are fighting the floor with long, specific selectors, stop. Either the token you want already exists and you should set it, or the floor is missing something and that belongs in the shared package, not in your app.

Theming a cloned site

Content lives in a per-environment database. How publishing snapshots an entry, how promote moves it up, and what default_slug and the status key control.

dev, uat and prod — how content moves, and what points the front door where.

Content lives in a database, not in the code. There are three copies of that database — one per environment — and content moves between them deliberately.

## dev, uat, prod

- **dev** is where content is authored and where drafts are visible. Builds here show the working copy of every entry.
- **uat** is for review. It shows only published content.
- **prod** is the live site. Same rule: published content only.

## How content moves

Editing happens in dev. When an entry is ready it is **published**, which snapshots its current state. A promote step copies published entries from one environment up to the next. The copy is per-app, so promoting this site never touches another site sharing the same table.

## What points the front door

Two things decide what a visitor sees first:

- **`default_slug`** — the page that `/` redirects to. It is a config value, not a code change.
- **the status key** — a small per-environment switch that puts the site into coming-soon, maintenance or live mode at the edge, before the page is even served.

## The takeaway

A deploy ships code. Publishing and promoting ship content. They are separate on purpose: you can fix a typo without a release, and you can release without touching a word of copy.

Publishing and environments

The blog landing page. It lists every published post, newest first. The template ships with a few example posts - edit or delete them once you have your own.

blog-intro

Everything the site has published, newest first. When you clone this template it comes with a handful of example posts - keep them as a reference or replace them with your own.

Latest posts

scPostsListing

5180ad05-9ee6-4681-acf4-42ef7ff29f89 standard-content scPostsListing

Every published post for the site, newest first.

Blog

footer-nav-logo

Terms and conditions

footer-terms_conditions

Privacy policy

footer-privacy_policy

Cookies policy

footer-cookies_policy

Legal Pages

legal-collection-footer

ba43ef6c-9955-4a19-9e0c-150f9c0cb572 standard-content footer__column

footer-primary

e740ad03-461e-4626-b469-ebf6b326e5ed standard-content footer__columns

copyrightText

005ea48d-1d27-499e-86da-8526becde3f4 standard-content footer__copyright magazine

navLogo

Home

Home - Top Nav Link

Blog - Top Nav Link

Contact

Contact - Top Nav Link

FAQ - Top Nav Link

Colour mode

Colour mode - Top Nav Toggle

navlinksWrapper

dc061992-079f-476a-9fb5-4e4963a737fe standard-content

This website stores cookies on your computer. To find out more about the cookies we use, see our <a href="/cookies-policy">Cookies Policy</a>.

cookieConsent

fbb6ba7a-1526-45e1-85f0-08256bcc905f standard-content