Sveltia CMS

Content Editor ​

Sveltia CMS provides a powerful Content Editor that allows users to create and modify content entries stored in their Git repository. This document outlines the key features and functionalities of the Content Editor.

Features ​

The Content Editor includes the following features to enhance the content creation and editing experience:

Two-Pane Interface ​

If the Preview Pane or i18n support is enabled, the Content Editor interface will split into two panes. By default, the Edit Pane is displayed on the left side, while the Preview Pane is on the right. This layout allows users to see a live preview of the content while editing. If the UI language is set to a right-to-left (RTL) language, the arrangement will be reversed. For that reason, the CMS UI calls them the first and second panes rather than the left and right panes.

The two-pane interface includes the following features:

  • Resizable Panes: Users can adjust the width of each pane by dragging the divider between them, allowing them to customize their workspace according to their preferences.
  • Swappable Panes: The small swap button in the middle of the divider switches the two panes around, so the Preview Pane can be on the left and the Edit Pane on the right. The arrangement is remembered per collection, along with the pane widths, and stays in effect until the panes are swapped back. If the panes appear on the “wrong” side, this is why — click the button again to restore the default order.
  • Scroll Synchronization: When editing long entries, Sveltia CMS synchronizes the scroll position between the Edit Pane and the Preview Pane. This helps users see how the content will look as they write, without having to manually scroll both sections.
  • Click-to-Highlight: Clicking on a field in the Preview Pane highlights the corresponding field in the Edit Pane. If the field is collapsed in the Edit Pane, it will automatically expand when clicked in the Preview Pane. This feature makes it easy to locate and edit specific fields based on their appearance in the preview.
  • Optional Second Pane: Users who prefer to edit at full width can hide the second pane with the Show Second Pane option in the editor menu. The pane layout is remembered and restored when the pane is shown again. See User Settings for details.

The Content Editor includes a sidebar that provides additional information and tools related to the content being edited. On a small screen, where the sidebar doesn’t fit, its panels are listed in the 3-dot menu and open in a sheet at the bottom of the screen. There are four panels:

  • Slug: Shows the entry’s slug and lets users edit it. See Slug Panel for details.
  • Validation: Shows any field validation errors in the content. When a user clicks on an error, the corresponding field in the editor will be highlighted. Results appear when an entry is saved, and the Validate button in the panel header checks it at any time — against every rule, including the required fields that an Editorial Workflow draft can be saved without, so users can see what’s still missing before the entry can be published.
  • History: Shows the commit history of the current content file. Clicking a commit shows a diff view of the changes made in that commit on the Git provider. This panel is not available while using the local development workflow.
  • Backlinks: Shows all the content files that reference the current content file via Relation fields. Clicking a backlink opens the referenced content file in the editor. For example, users can see all blog posts that reference a specific author or tag, which can be useful for quickly navigating between related content.

More panels will be added in the future.

Auto-Saving Drafts ​

When creating or editing content, Sveltia CMS automatically saves draft backups in the browser’s local storage. This ensures that work is not lost in case of accidental navigation away from the page or browser crashes. Drafts are saved periodically as changes are made and can be restored when the user returns to the editing interface.

Auto-saving draft can be disabled in User Preferences.

Revert, Restore and Clear ​

The Content Editor offers three ways to start over, side by side in the 3-dot menus:

  • Revert Changes discards the unsaved changes, bringing back the last saved values. This is useful for undoing changes made during the current editing session.
  • Restore Default puts back the values a new entry would have, taking each field’s default option into account.
  • Clear empties the values, ignoring the defaults, so that fields can be filled in from scratch. A List field is left without items and a KeyValue field without pairs. A required field then has to be filled in again before the entry can be saved.

They apply to different parts of the entry depending on the menu:

  • The menu of a field applies to that field alone, including the subfields of an Object or List field.
  • The content options menu in the header of an editor pane applies to every field in the locale shown in the pane, labeled Revert Changes, Restore Default and Clear All.
  • The editor options menu at the top-right corner applies to every field in every locale, labeled Revert All Changes, Restore Default and Clear All.

Because the pane and editor menus change many fields at once, they ask for confirmation first. A field can be reverted to undo a restore or clear, until the entry is saved.

Restoring and clearing leave alone the values a user doesn’t enter: Hidden, UUID and Compute fields, read-only fields, and the type of a variable type Object field. The items of a List field with the allow_remove: false option are kept as well, since clearing or restoring could remove them, and so are those of a List field with the allow_add: false option when restoring, which could add items. An optional Object field that is collapsed stays collapsed. With i18n enabled, restoring or clearing a field in the default locale does the same in the other locales where the field is duplicated, while in another locale only the fields that can be translated there are changed.

Slug Panel ​

An entry’s slug is the identifier that appears in its file name and, in most setups, in its URL on the live site. It’s usually generated from a template, such as the entry’s title, and is shown in the Slug panel of the sidebar, which can also be opened with the Edit Slug option in the 3-dot menu.

The slug is shown as read-only text, with a pencil button to edit it. While it’s being edited, it’s checked as the user types: a slug cannot contain slashes or whitespace, cannot already be in use by another entry in the same collection, including entries awaiting review under the Editorial Workflow, and must match the collection’s pattern slug option if any. Press Enter or click the check mark button to apply the slug, or press Escape to cancel. Whatever is typed is normalized with the site’s global slug options. If the collection has a hint slug option, it’s shown at the top of the panel.

If entry slugs are localized, the panel has a section for each locale, like the Validation panel. Otherwise, there’s a single slug shared by every locale.

New Entries ​

In a new entry, the panel shows the slug the entry will be saved with, which follows the entry’s content as it is edited. A slug containing a date and time, such as {{year}}-{{month}}-{{day}}-{{slug}}, is shown with the current date and time, and gets the date and time of the save. A random ID, such as {{uuid_short}}, is kept until the entry is saved, so the entry is saved with the slug shown.

Once a user gives a custom slug with the pencil button, it no longer follows the entry’s content. To go back to the generated slug, edit the slug and empty it.

If the collection is configured to have users type the slug, the panel shows a regular text field instead, opens by itself when a user creates an entry, and the entry can’t be saved until a slug has been entered.

Saved Entries ​

In a saved entry, the pencil button renames the entry. The new slug takes effect when the entry is saved, and saving does three things in a single commit:

  • Renames the file. The entry moves to the file path matching its new slug. Git records this as a rename, so the file’s history is preserved. In a nested collection the entry’s folder is renamed instead, and everything below it moves along: the entries stored there and, with entry-relative media, the files of each page bundle. The entry keeps its place in the tree — renaming never files it under a different parent, which is what the Parent Folder field is for.
  • Adds a redirect. If the collection has a preview_path option, the entry’s previous URL is recorded in its data so the framework can redirect visitors from the old URL to the new one. See Redirects.
  • Updates references. Every entry that points at this one through a Relation field is rewritten to reference the new slug, so no links between entries are left dangling. The Backlinks panel of the sidebar shows which entries will be updated before saving.

In a nested collection where every entry is stored as an index file, the folder holding an entry is what identifies it, so the panel shows that folder’s name rather than the path leading to it, with a Rename Folder button. The folder is shared by every locale unless the slugs are localized. A name is only in the way if another folder in the same parent already uses it, so the same name can appear elsewhere in the tree. The rules differ slightly from a slug’s: spaces are allowed and become hyphens, while a name that starts with a dot, which would hide the folder, or that keeps no letter or number once normalized, is rejected.

The slug of a saved entry is shown without the pencil button where it can’t meaningfully change: in a collection that doesn’t allow it with the editable slug option, on an entry awaiting deletion under the Editorial Workflow, and in a nested collection where entries don’t share one file name — with subfolders: false, or without the meta.path.index_file option: an entry is identified by its whole path below the collection folder there, and no part of that path belongs to the entry alone. The panel isn’t available for entries in file and singleton collections, whose file names are fixed in the configuration, or for Hugo’s special index file.

Deleting an Entry ​

The Delete Entry option in the 3-dot menu removes a saved entry along with the files in its entry-relative media folder, if it has one. Every entry that points at it through a Relation field is updated in the same commit, so no reference is left dangling: the confirmation dialog says how many entries will be updated, and refuses the deletion if clearing a reference would leave a required field empty or a multi-select field short of its minimum, listing the entries and fields in the way. See Cascading Deletions. Under the Editorial Workflow, the deletion is staged in a pull request instead of being committed right away.

The option isn’t offered in file and singleton collections, or in collections where entry deletion is disabled. To delete several entries at once, select them in the entry list.

View on Live Site ​

The 3-dot menu in the Content Editor includes a View on Live Site option. This allows users to quickly open the live version of the entry being edited, making it easy to check how the current content appears on the actual website.

View Source ​

When Developer Mode is enabled, the 3-dot menu in the Content Editor provides a View Source option. This allows users to quickly open the source file of the entry or asset in the Git repository, making it easy to review or edit the raw content.

I18n Support ​

If internationalization (i18n) is enabled in the Sveltia CMS configuration, the Content Editor provides support for managing translations of the content. Users can switch between different language versions of the content being edited, making it easy to create and maintain multilingual sites.

  • Language Switcher: A language switcher is available in the editor interface, allowing users to select the desired language for editing and preview. If there are any errors or missing translations, they will be indicated in the switcher.
  • Translate Button: A Translate button is provided to translate all or specific text-type fields using a third-party translation service. This feature can help speed up the process of creating translations for the content.
  • Copy Button: A Copy button is available to copy content from one language version to another, facilitating the translation process.

See also the Linking to Content Editor section for information on setting the editor pane locale via URL.

Keyboard Shortcuts ​

Sveltia CMS includes several keyboard shortcuts to enhance productivity while editing content.

  • Save an entry: Ctrl+S (Windows/Linux) or Command+S (macOS)
  • Cancel entry editing: Escape

Standard keyboard shortcuts are also available in the Markdown editor, including Ctrl+B/Command+B for bold text, Ctrl+I/Command+I for italics, Ctrl+K/Command+K to insert a link, and Tab to indent a list item. The bold, italic and link shortcuts work in both the rich text and raw Markdown editing modes.

Linking to Content Editor ​

Sveltia CMS supports linking directly to specific states of the Content Editor using URL query parameters. This can be useful for sharing links to specific entries or pre-filling fields when creating new entries.

Opening Specific Entries ​

Links can point directly to the Content Editor for a specific entry in an entry collection using the following URL format:

https://YOUR_DOMAIN/admin/#/collections/COLLECTION_NAME/entries/ENTRY_ID

Where ENTRY_ID is the entry’s file path within the collection folder, without the file extension. The same format works for a file/singleton collection, where ENTRY_ID is the file’s name in the configuration.

Migrating from Netlify/Decap CMS

Netlify/Decap CMS also accepts a shorthand for the same link, which it documents alongside its Open Authoring feature:

https://YOUR_DOMAIN/admin/#/edit/COLLECTION_NAME/ENTRY_ID

Sveltia CMS accepts it too and redirects to the URL above, so any link already shared keeps working. Use the full format for new links.

Dynamic Default Values ​

Sveltia CMS supports dynamic default values passed with URL query parameters. This allows pre-filling certain fields when creating new entries in an entry collection.

The URL format for pre-filling fields is as follows:

https://YOUR_DOMAIN/admin/#/collections/COLLECTION_NAME/new?field1=value1&field2=value2

Where field1, field2, etc. are the names of the fields to pre-fill with value1, value2, etc. Some notes on using this feature:

  • Make sure to URL-encode the parameter values.
  • Use dot notation to target nested fields (e.g. author.name=John%20Doe).
  • Use a comma-separated list (e.g. tags=value1,value2) or multiple query parameters (e.g. tags=value1&tags=value2) for multi-select fields.

For example, given the following collection configuration:

yaml
collections:
  - name: posts
    label: Posts
    folder: /content/posts
    fields:
      - name: title
        label: Title
      - name: author
        label: Author
        widget: object
        fields:
          - name: name
            label: Name
      - name: body
        label: Body
        widget: richtext
toml
[[collections]]
name = "posts"
label = "Posts"
folder = "/content/posts"
[[collections.fields]]
name = "title"
label = "Title"
[[collections.fields]]
name = "author"
label = "Author"
widget = "object"
[[collections.fields.fields]]
name = "name"
label = "Name"
[[collections.fields]]
name = "body"
label = "Body"
widget = "richtext"
json
{
  "collections": [
    {
      "name": "posts",
      "label": "Posts",
      "folder": "/content/posts",
      "fields": [
        { "name": "title", "label": "Title" },
        {
          "name": "author",
          "label": "Author",
          "widget": "object",
          "fields": [{ "name": "name", "label": "Name" }]
        },
        { "name": "body", "label": "Body", "widget": "richtext" }
      ]
    }
  ]
}
js
{
  collections: [
    {
      name: "posts",
      label: "Posts",
      folder: "/content/posts",
      fields: [
        { name: "title", label: "Title" },
        {
          name: "author",
          label: "Author",
          widget: "object",
          fields: [{ name: "name", label: "Name" }],
        },
        { name: "body", label: "Body", widget: "richtext" },
      ],
    },
  ],
}

The following URL will open the new entry editor with the title, author.name and body fields pre-filled:

https://example.com/admin/#/collections/posts/new?title=My%20First%20Post&author.name=John%20Doe&body=Hello%2C%20world!

Editor Pane Locale ​

By default, Sveltia CMS uses the default locale for the Content Editor pane. However, a different locale can be specified for the editor pane using a URL query parameter when i18n support is enabled.

To set the editor pane locale, append the _locale query parameter to the CMS URL with the desired locale code. For example, to open the editor pane in French (fr), use the following URL:

https://YOUR_DOMAIN/admin/#/collections/COLLECTION_NAME/entries/ENTRY_ID?_locale=fr

For a new entry:

https://YOUR_DOMAIN/admin/#/collections/COLLECTION_NAME/new?_locale=fr

The query parameter can be combined with dynamic default values to pre-fill field values via URL.

Entry Slug ​

When creating a new entry, a slug can also be given with the _slug query parameter. For example:

https://YOUR_DOMAIN/admin/#/collections/COLLECTION_NAME/new?title=My%20First%20Post&_slug=2025-06-15-my-first-post

The slug is only used if the collection allows users to edit the slug when creating an entry, which is the default. See Making Slugs Editable. It shows up in the Slug panel like a slug typed by the user, and it’s checked the same way when the entry is saved. If slugs are localized, it applies to the default locale.

Saving Behavior ​

Save and Publish Options ​

When the skip_ci backend option is enabled, the Save button in the Content Editor has a dropdown menu that allows users to choose between two saving options. See the Disabling Automatic Deployments section for more details.

Auto-Close Editor ​

When a user saves changes, the Content Editor automatically closes the editing interface and returns to the collection or file list. This streamlines the workflow by reducing the number of clicks needed to return to the main interface after saving. Users who prefer to stay in the editor after saving can change this behavior in User Preferences.

Conflict Resolution ​

Several people can work on a site at the same time. Sveltia CMS keeps an eye on the repository so that a change one of them pushes isn’t lost when another saves over it:

  • When a user opens an entry, the branch is checked for new commits, so they start from the entry as it is, not as it was when they signed in.
  • While a user edits, the check is repeated every minute and whenever they come back to the tab. It’s a single small request to the backend, and only files that have actually changed are fetched, so the entry and asset lists follow the repository without a reload. If someone changes the entry that is open, a notice appears at the top of the editor saying who changed it and when. Reload Entry starts over from their version — after asking, if there are unsaved changes — while dismissing the notice lets the user carry on with their own.
  • When a user saves, the branch is checked once more. If the entry has been changed or deleted since it was opened, a dialog says so, and nothing is written until the user chooses Save Anyway. Saving over a change replaces it with theirs; saving a deleted entry creates it again.
  • On GitHub, the commit also names the branch head it expects, so a commit against a branch that moved in the last moment is refused by GitHub rather than applied. Sveltia CMS then explains what happened, and saving again picks the other change up first.

Under the Editorial Workflow, each unpublished entry lives on its own branch that nobody else writes to, so these checks don’t apply there; a conflict with the main branch, if any, is dealt with when the entry is published.

Only entries on the configured branch are watched. Changes to a colleague’s draft, or to the same entry in the local development workflow, aren’t detected.

Preview Pane ​

Developers can enhance the content editing experience by providing real-time previews of how the content will appear on the live site. Sveltia CMS offers several options for customizing and controlling the preview feature.

INFO

Please note that, due to the nature of framework-agnostic design, we don’t plan to support live site previews that fetch data from the actual website. If this feature is needed, consider using a framework-specific CMS solution.

Disabling Previews ​

Previews are enabled by default. However, to disable the preview feature entirely, do so at different levels:

Global ​

Add the following configuration to the top level of the config.yml file:

yaml
editor:
  preview: false
toml
[editor]
preview = false
json
{
  "editor": {
    "preview": false
  }
}
js
{
  editor: {
    preview: false,
  },
}

Collection-Level ​

Add the same editor option to a specific collection in the config.yml file:

yaml
collections:
  - name: blog
    label: Blog
    folder: /content/blog
    editor:
      preview: false
toml
[[collections]]
name = "blog"
label = "Blog"
folder = "/content/blog"
[collections.editor]
preview = false
json
{
  "collections": [
    {
      "name": "blog",
      "label": "Blog",
      "folder": "/content/blog",
      "editor": {
        "preview": false
      }
    }
  ]
}
js
{
  collections: [
    {
      name: "blog",
      label: "Blog",
      folder: "/content/blog",
      editor: {
        preview: false,
      },
     },
  ],
}

File-Level ​

Add the same editor option to a specific file in the config.yml file:

yaml
files:
  - name: about
    label: About Page
    file: /content/about.md
    editor:
      preview: false
toml
[[files]]
name = "about"
label = "About Page"
file = "/content/about.md"
[files.editor]
preview = false
json
{
  "files": [
    {
      "name": "about",
      "label": "About Page",
      "file": "/content/about.md",
      "editor": {
        "preview": false
      }
    }
  ]
}
js
{
  files: [
    {
      name: "about",
      label: "About Page",
      file: "/content/about.md",
      editor: {
        preview: false,
      },
     },
  ],
}

Field-Level ​

Add the preview option to a specific field in the config.yml file:

yaml
fields:
  - name: body
    label: Body
    widget: richtext
    preview: false
toml
[[fields]]
name = "body"
label = "Body"
widget = "richtext"
preview = false
json
{
  "fields": [
    {
      "name": "body",
      "label": "Body",
      "widget": "richtext",
      "preview": false
    }
  ]
}
js
{
  fields: [
    {
      name: "body",
      label: "Body",
      widget: "richtext",
      preview: false,
    },
  ],
}

Advanced Customization ​

Sveltia CMS allows developers to create custom preview templates and styles to provide a more accurate representation of how the content will appear on the live site.

  • Custom Preview Styles: Register custom CSS styles for the preview pane, allowing for better visual fidelity with the live site.
  • Custom Preview Templates: Create custom preview templates for specific collections or files, allowing for tailored preview experiences.

Live Preview ​

Sveltia CMS does not plan to support WYSIWYG live site previews that fetch data from the actual website, due to its framework-agnostic design. If this feature is required, consider using a framework-specific CMS solution.

User Settings ​

End-users can control the editor layout in the CMS UI using the menu located at the top-right corner of the editor interface. These preferences are saved in the browser, allowing users to maintain their preferred layout across sessions.

  • Show Second Pane: Shows or hides the second pane, giving the Edit Pane the full width of the editor when it’s off. The option is unavailable when there’s nothing to put in the second pane, that is, when the entry has neither a preview nor a second locale. The pane layout, including any width set by dragging the divider and whether the panes have been swapped, is remembered per collection and restored when the option is turned back on.
  • Show Preview: Chooses whether the second pane shows the preview. When i18n support is enabled, turning it off puts another locale’s Edit Pane in the second pane instead.
  • Sync Scrolling: Turns scroll synchronization between the two panes on or off. This is enabled by default.

Show Preview and Sync Scrolling only take effect while the second pane is visible, so both are unavailable when Show Second Pane is turned off.

These are display preferences only. To disable previews for everyone, use the configuration options described under Disabling Previews.

Copyright © 2026 Kohei Yoshino