SignalJuly 12, 2026

Content fields are data, not code

Because content_type_fields and content_items.fields_json are schemaless, adding a field to an existing type never touches existing records.

Content

Content types, their fields, and their items all live as rows in content_types, content_type_fields, and content_items — nothing is a hardcoded model in the app. fields_json on an item is just JSON; the field-definition rows are only used to render admin forms and validate input, not to constrain what's already stored.

The practical effect: adding a new field to a type that already has published items is a pure insert into content_type_fields. Existing items don't need a migration or a backfill — they just don't have a value for that key until someone fills it in, and the admin form treats it as empty.

cmsarchitectureschema

Internal Links

Keep exploring

ProjectProducedAlex CMSDiscovery made while reviving content types on the CMS.

Explore with Alex OS

Content fields are stored as data rows and JSON, so adding a field to a live content type is a single INSERT — no migration, no backfill.

What changed

Content types, their field definitions, and their items all live as database rows — nothing is a hardcoded model. Item data sits in `fields_json` (plain JSON); the `content_type_fields` rows exist only to drive admin forms and validate input, not to constrain stored records. Adding a field to an existing type is a pure insert into `content_type_fields`. Items already in the database are untouched — the admin form just treats the new key as empty until someone fills it in.

Why it matters now

This came into focus while reviving content types on the Alex CMS project. The schemaless design means a published content type can evolve without touching existing records — no ALTER TABLE, no backfill script, no coordinated deploy. That's a direct consequence of keeping field definitions as data rather than application code.