Content Studio
Open /admin/cms for the full Studio, or choose Studio from the inline
editor. Use on-page editing for visible content and Studio for structured data,
repeatable records, and fields that do not appear on a page.
The home view
Section titled “The home view”The dashboard lists configured, dynamically defined, and discovered collections. Choose a card to open its entries; a collection configured as a singleton (one fixed entry, such as site settings) opens that entry directly. Use the compact collection switcher to move between collections.
Entry lists support search and pagination. Titles, thumbnails and supporting
text can be configured with titleField, thumbnailField and subtitleField.
Raw IDs remain available as internal addresses. Single-page lists omit pagination.
Creating a new collection is currently an API operation. Studio can create entries inside an existing collection when allowed.
Create an entry
Section titled “Create an entry”- Open a collection with creation enabled and choose its New action.
- Enter a title. Studio suggests an internal ID where a title field is available.
- Adjust the ID before creating if needed. IDs are permanent internal addresses.
- Create the entry, complete its fields, and save. Defaults come from the schema.
A duplicate ID keeps the dialog open so you can correct it. Creating an entry does not generate a page template: your Astro routes determine how entries render.
Editing an entry
Section titled “Editing an entry”| Control | How to use it |
|---|---|
| Text / multiline text | Edit short values or paragraphs; schema descriptions explain the field |
| Formatted HTML | Use Bold, Italic and Link; Edit HTML is secondary source access with sanitization |
| Image | Replace by upload or use the image-URL option; review alternative text separately |
| Number, on/off switch, choice list | Enter constrained values, switch a boolean, or select one of the allowed options |
| Repeatable record | Expand its summary, edit fields, add/remove records, and move by drag or keyboard |
| Field groups | Work through related sections; technical IDs/dimensions can be secondary details |
The action area prioritizes title, save status and the primary save action. Occasional actions such as History and Delete live in More. Required fields are marked; descriptions and Help supply context without a permanent help banner.
Validation opens collapsed controls and focuses the first invalid field. The server repeats validation. Keep the form open if a save fails; a failure does not mean your browser edits were stored.
Studio and page synchronization
Section titled “Studio and page synchronization”In the drawer, selecting content on the page opens the matching entry and field. Selecting a field in Studio locates its page match. Text and images preview while you type; structural saves refresh the page preview.
The drawer moves opposite selected content without reflowing the host page. Use its controls to move sides, expand to full Studio, or close. Closing preserves unfinished form state; navigation to another surface may ask you to resolve it. On small screens the drawer uses the full width.
Edit / Preview controls whether page interaction edits content or follows normal navigation. Preview does not publish your changes.
Draft, preview, and publish
Section titled “Draft, preview, and publish”Ordinary saves go live in server delivery without a write policy. Static delivery and policy-controlled editing save private drafts. Markdown body changes always draft until Publish. Read Saving and publishing for the full behavior table, visibility, sign-out, and git workflow.
Studio keeps Public/Hidden entry visibility separate from whether the latest change is unsaved, a saved draft, or live. A private change to the visibility field is not public until published.
Revision history
Section titled “Revision history”Open More > History to review action summaries, changed fields, and available value previews before choosing Restore. Restoration is a write, not merely a preview loaded into the form; read the confirmation before accepting it. With a write policy, restoring requires both edit and publish permission and writes shared content. Static visitors still need a rebuild and deployment.
Built-in history keeps up to 50 snapshots per entry. Named identities are attached to new snapshots. Markdown publish snapshots can preserve the earlier full source for restoring prose and frontmatter together. This is not a backup system or a promise of a Studio undelete screen; back up content independently.
Conflicts and recovery
Section titled “Conflicts and recovery”If another save changed an entry while you were editing, Studio identifies changed fields and offers Keep my edits or Load latest. Review the differences; keeping local work is not an automatic merge. Copy important unsaved text before reloading or discarding. Publication has additional draft conflict and recovery rules.
Collection capabilities
Section titled “Collection capabilities”This configuration is for the developer setting up Studio. Add it to the
existing caret() call; editors do not need to change code to use the form.
caret({ collections: { posts: { label: 'Articles', entryLabel: 'article', titleField: 'title', thumbnailField: 'cover', subtitleField: 'summary', previewPath: '/articles/{id}', creatable: true, orderable: true, deletable: true, }, site: { singletonId: 'global', creatable: false, deletable: false }, },});Creation, ordering and deletion capabilities are enforced by the server. A per-identity write policy can further restrict them. Arrange content only when the complete collection is loaded, without a search filter or partial page. Pointer and keyboard movement remain available.
See Configuration for settings and Schemas for groups, descriptions and field formats.
Accessibility and language
Section titled “Accessibility and language”Studio includes labelled controls, save/error announcements, keyboard movement,
focus management in dialogs, and English/Spanish messages. Configure locale
and dictionary for built-in copy; schema labels and collection names are yours.
API calls behind the UI
Section titled “API calls behind the UI”Custom integrations can use the API reference
for entry lists, schemas, mutations, uploads, drafts, publication and history.
These requests require authentication; writes also need x-caret-request: 1.