Every field type supported by the Hiveku CMS — what each one stores, how it renders in the editor, and when to use it
The CMS form editor is built directly from the field definitions in your manifest. Each field’s type decides what the input control looks like, how data is validated, and how the value is stored on disk.This page is the full reference. Pick the type that matches the kind of data, and the editor takes care of the rest.
Long-form Markdown content.UI: A split-pane editor with live preview, syntax highlighting, image drop, and shortcuts. The same control is used for the body of MDX entries when isBody: true.Stores: Markdown source — either as a JSON string (for JSON collections) or as the body of the MDX file (when isBody: true).Properties:
Property
Description
isBody
When true on an MDX collection, this field becomes the body of the file. Exactly one body field per MDX collection.
An image asset.UI: An upload dropzone with drag-and-drop, paste support, and an “Choose existing” button that opens the project’s media library. Resizes and serves through Hiveku’s image CDN automatically.Stores: A JSON string with the path to the uploaded file (e.g. /uploads/hero.jpg), or an object with src, alt, width, height if metadata: true.Properties:
Property
Description
metadata
If true, store { src, alt, width, height } instead of just a path
accept
Comma-separated list of MIME types (default image/*)
A non-image file asset (PDF, video, audio, archives).UI: Same upload dropzone as image, with a generic file preview.Stores: A JSON string with the upload path.Properties:
Property
Description
accept
MIME types or extensions (e.g. "application/pdf,.zip")
One of a fixed set of values.UI: A dropdown (or a radio group for short option lists).Stores: A JSON string matching one of the option values.Properties:
Property
Description
options
Array of option strings, or [{ value, label }] objects for custom labels
multiple
If true, becomes a multi-select that stores an array
A list of values, all of the same shape.UI: A reorderable list with add/remove buttons. Each row renders the editor for the items type.Stores: A JSON array.Properties:
Property
Description
items
The type of each element. Can be a primitive ("string", "number", "image") or a full field definition ({ "type": "object", "fields": [...] })
A pointer to another collection’s entry.UI: A picker that opens a searchable list of entries from the target collection. The picker shows each entry’s title field for easy identification.Stores: A JSON string with the referenced entry’s slug, or an array of slugs if multiple: true.Properties:
Property
Description
collection
Required. The target collection’s id.
multiple
If true, stores an array of references
displayField
Field name to show in the picker (defaults to title or name)
Long-form prose with formatting?markdown (and isBody: true if it’s the main body of an MDX entry).
Short text?string. Add multiline: true for things like excerpts or short descriptions.
A fixed set of choices?select. Use multiple: true for multi-select.
A list of similar things?array. Set items to a primitive or to an object for richer rows.
A pointer to another piece of content?reference. Don’t duplicate fields across collections — link them.
Something that should just be one record? Use a singleton collection (manifest-level singleton: true) and put your fields directly on it.
Once an entry has data for a field, removing the field from the manifest hides it from the form but leaves the value in the file. Re-adding the field restores the editor. Renaming a field is more invasive — ask the AI to migrate the data.