Privacy choices
This site may send the owner a minimal page-visit notice with page, browser, device type, and resolution. If you accept analytics, it can also remember an anonymous visit/session ID and collect richer engagement signals.
Read the privacy noticeContent types are rows, not code — creating one is a data operation, done through the admin or a seed script.
Because content_types/content_type_fields/content_items are the whole model, adding a new kind of content doesn't require touching the Next.js app's TypeScript at all, unless you want a brand-new detail-page layout.
Adding a content type is a database operation, not a code change — the schema handles the rest.
What this covers
The CMS stores all content as rows across three tables: `content_types`, `content_type_fields`, and `content_items`. Because the entire content model lives in data, introducing a new content type means inserting rows — via the admin interface or a seed script — not writing TypeScript. The Next.js app stays untouched unless you need a custom detail-page layout for the new type.
Key takeaways
1. New content types are created through the admin UI or a seed script — no app code required. 2. The three-table model (`content_types` / `content_type_fields` / `content_items`) is the full schema; extensibility is built into the data structure itself. 3. The only reason to touch the Next.js codebase is if the new type needs a distinct detail-page layout. 4. This is an intermediate task — you need to understand the table relationships, but no TypeScript changes are necessary for the common case. 5. For a broader look at how this architecture holds together, see the Dynamic CMS Architecture write-up; for hands-on extension patterns, the Alex CMS project shows how the content model is put to work.