Publishing with Pages CMS
How a post goes from a browser editor to a live page, and what each step in the pipeline is responsible for.
Writers on this site use Pages CMS. It is a browser editor that reads and writes the Markdown files in the site repository. This post explains what happens between the moment a writer saves and the moment a reader sees the page.
Step 1: the editor
Pages CMS reads the .pages.yml file in the repository root. That file lists
the collections, the fields of each collection, and the rules for file names
and uploads. The editor shows only the fields that the file declares, so a
writer cannot invent a field by accident.
Step 2: the commit
When the writer saves, Pages CMS commits the Markdown file to the repository through the GitHub API. The commit carries the identity of the writer, so the history shows who changed what. No content is stored inside the CMS.
Step 3: the checks
Every commit starts a continuous integration run. The run does two things:
- It checks the content against the schema. A missing summary, a bad date, or an unknown author stops the run.
- It builds the production site.
A failed run means the content or the code needs a fix. The live site keeps serving the last good build until the problem is solved.
Step 4: the deployment
The host builds the same commit and publishes the output. A deployment takes about one minute for a site of this size. Each deployment gets its own preview URL, so you can compare a change against the live site before it goes public.
Why this shape
The pipeline has no moving parts that we must operate. The repository holds the content, the checks protect the schema, and the host serves static files. If any provider becomes a problem, the content is still plain Markdown in Git, and it can move somewhere else without a rewrite.