Content & media

Content types & entries

Collections, schemas, git or database storage, and the Content Hub.

A content type is a shape you describe once — the fields, what they hold, and what should be generated for it. Entries are edited in forms built from that shape, and everything ships as real files.

Content types

Under Content, a type has a name, a slug, and a list of fields. Two are built in: Title and Slug.

Field type	Holds
Text	a short line
Long text	a paragraph
Number	a figure
Toggle	on or off
Image	an asset from the media library
Date	a calendar date
Link	a web address
Email / Phone	an address, a number to call
Color	a hex value
List of text	tags, bullets
Group	fields kept together
Repeating items	a list of entries, each with its own fields

A group holds one record and a repeater holds a list of them. Both are keyed by field name in the emitted file, so a binding reads the same at any depth: {item.address.city}.

What a type generates

Three switches decide what a type is worth on disk:

Setting	Writes
Queryable	`src/data/<slug>.json` — the rows, which is what a Loop reads
Archive	`src/pages/<slug>.astro` — a page listing the live entries
Public	each entry gets its own page, linked from the archive

Switch one off and the file it wrote is removed. Deleting a type takes its generated files with it — nothing is left behind pointing at data that no longer exists.

Taxonomies

A taxonomy is a named list of terms — categories, tags, statuses — attached to one or more types. A queryable taxonomy emits its terms as src/data/<slug>.json too, so a filter list is a Loop like any other.

On an entry, a taxonomy is a picker. In the emitted row it is an array of term slugs:

src/data/projects.json

[
  {
    "title": "Harbour House",
    "slug": "harbour-house",
    "year": 2024,
    "category": ["architecture", "residential"]
  }
]

Pages are a collection too

The same fields and taxonomies, attached to routes instead of entries — which is how a page gets a "featured image" or a "category" without inventing a parallel system. Nothing is written for pages until you ask for it.

Markdown entries

Alongside the builder's own types, a project can hold ordinary Astro content collections under src/content/ — MD or MDX files with frontmatter. They are read and written as files, and an agent can edit one directly:

src/content/posts/hello.md

---
title: Hello
date: 2026-05-01
tags: [notes]
---

The body is markdown, and it stays markdown.

This is the direction the content side is heading: git-backed files as the default for small and medium sites, with a database adapter for the cases that genuinely need one — editing without a deploy, large or relational data, user-generated content.

Using entries on a page

A Loop over a content type binds {item.field_name} into the children you build. The canvas fills it with the real rows, so you are laying out actual content rather than an empty shell.