Sveltia CMS

Entry Operations ​

Sveltia CMS provides options to control entry creation, deletion and duplication, limit the number of entries, make content read-only, hide collections from the interface, and let editors reorder entries manually.

Disabling Creation and Deletion ​

You can disable entry creation and deletion by setting the create option to false and the delete option to false in the collection definition. This is useful for collections where entries are managed programmatically or through other means, and you don’t want editors to create or delete entries.

yaml
collections:
  - name: posts
    label: Blog Posts
    folder: /content/posts
    create: false
    delete: false
    fields:
      - { name: title, label: Title }
      - { name: body, label: Body, widget: richtext }
toml
[[collections]]
name = "posts"
label = "Blog Posts"
folder = "/content/posts"
create = false
delete = false

[[collections.fields]]
name = "title"
label = "Title"

[[collections.fields]]
name = "body"
label = "Body"
widget = "richtext"
json
{
  "collections": [
    {
      "name": "posts",
      "label": "Blog Posts",
      "folder": "/content/posts",
      "create": false,
      "delete": false,
      "fields": [
        { "name": "title", "label": "Title" },
        { "name": "body", "label": "Body", "widget": "richtext" }
      ]
    }
  ]
}
js
{
  collections: [
    {
      name: "posts",
      label: "Blog Posts",
      folder: "/content/posts",
      create: false,
      delete: false,
      fields: [
        { name: "title", label: "Title" },
        { name: "body", label: "Body", widget: "richtext" },
      ],
    },
  ],
}

Breaking change from Netlify/Decap CMS

In Sveltia CMS, the create option for entry collections defaults to true because, in 99.99% of cases, users want to create new entries and adding create: true to every collection is redundant. To disable entry creation, set create: false explicitly.

Disabling Duplication ​

You can disable entry duplication by setting the duplicate option to false in the collection definition. This is useful for collections where entries should not be duplicated, such as unique content types.

When the duplicate option is set to false, the “Duplicate” button will be disabled in the Sveltia CMS interface, preventing users from creating duplicate entries.

yaml
collections:
  - name: products
    label: Products
    folder: /content/products
    duplicate: false
toml
[[collections]]
name = "products"
label = "Products"
folder = "/content/products"
duplicate = false
json
{
  "collections": [
    {
      "name": "products",
      "label": "Products",
      "folder": "/content/products",
      "duplicate": false
    }
  ]
}
js
{
  collections: [
    {
      name: "products",
      label: "Products",
      folder: "/content/products",
      duplicate: false,
    },
  ],
}

Limiting Entry Count ​

You can limit the number of entries in an entry collection using the limit option. This is useful for collections where you want to restrict the number of items, such as featured articles or top products.

yaml
collections:
  - name: featured_articles
    label: Featured Articles
    folder: /content/featured_articles
    limit: 5
    fields:
      - { name: title, label: Title }
      - { name: body, label: Body, widget: richtext }
toml
[[collections]]
name = "featured_articles"
label = "Featured Articles"
folder = "/content/featured_articles"
limit = 5

[[collections.fields]]
name = "title"
label = "Title"

[[collections.fields]]
name = "body"
label = "Body"
widget = "richtext"
json
{
  "collections": [
    {
      "name": "featured_articles",
      "label": "Featured Articles",
      "folder": "/content/featured_articles",
      "limit": 5,
      "fields": [
        { "name": "title", "label": "Title" },
        { "name": "body", "label": "Body", "widget": "richtext" }
      ]
    }
  ]
}
js
{
  collections: [
    {
      name: "featured_articles",
      label: "Featured Articles",
      folder: "/content/featured_articles",
      limit: 5,
      fields: [
        { name: "title", label: "Title" },
        { name: "body", label: "Body", widget: "richtext" },
      ],
    },
  ],
}

With the above configuration, editors can only create up to 5 entries in the featured_articles collection. Once the limit is reached, the “Create new” button will be disabled in the Sveltia CMS interface.

The collection’s index file doesn’t take up a slot. It stands for the collection’s own page rather than for one of the entries in it, so a collection with limit: 5 and an index_file holds its index file plus 5 entries.

Making Content Read-Only ​

You can make content read-only with the readonly option. Editors can still browse, search and view read-only content, including its preview, but they can’t change it. The option can be set at three levels:

  • Globally: At the top level of the configuration, readonly: true puts the whole CMS in read-only mode. This is handy while your site is under maintenance or being migrated, when editors shouldn’t write to the repository.
  • Collection: On an entry collection, a file collection or an asset collection, readonly: true locks that collection only.
  • File: On a file in a file collection, or on a singleton, readonly: true locks that file only, while the other files stay editable.
yaml
collections:
  - name: archive
    label: Archive
    folder: /content/archive
    readonly: true
    fields:
      - { name: title, label: Title }
      - { name: body, label: Body, widget: richtext }
toml
[[collections]]
name = "archive"
label = "Archive"
folder = "/content/archive"
readonly = true

[[collections.fields]]
name = "title"
label = "Title"

[[collections.fields]]
name = "body"
label = "Body"
widget = "richtext"
json
{
  "collections": [
    {
      "name": "archive",
      "label": "Archive",
      "folder": "/content/archive",
      "readonly": true,
      "fields": [
        { "name": "title", "label": "Title" },
        { "name": "body", "label": "Body", "widget": "richtext" }
      ]
    }
  ]
}
js
{
  collections: [
    {
      name: "archive",
      label: "Archive",
      folder: "/content/archive",
      readonly: true,
      fields: [
        { name: "title", label: "Title" },
        { name: "body", label: "Body", widget: "richtext" },
      ],
    },
  ],
}

To put the whole CMS in read-only mode, add the option to the top level instead:

yaml
readonly: true
toml
readonly = true
json
{
  "readonly": true
}
js
{
  readonly: true,
}

A read-only level locks everything below it, and a lower level can’t opt out with readonly: false. For example, while the whole CMS is read-only, every collection and file is read-only as well.

For read-only content, Sveltia CMS:

  • Shows a message at the top of the entry list, the Content Editor and the Asset Library, saying that the content can be viewed but not changed. When the whole CMS is read-only, the message says so instead.
  • Disables creating, duplicating, deleting and reordering entries, including from the global Create menu and the Add button of a Relation field that creates related entries. The Create menu button itself is disabled when nothing can be created, as in read-only mode.
  • Opens entries and files with every field locked. The Save button, the slug and parent folder editors, the translation and copy options, and the reset options are not available.
  • Hides the Editorial Workflow controls for the entry, so it can’t be moved through the review stages, published or discarded.
  • Disables uploading, replacing, editing, renaming and deleting assets in the media folders of the read-only collection or file, as well as creating, renaming and deleting subfolders there. The global media folder is only read-only along with the whole CMS.

Read-only entries also stay intact when other content changes. Sveltia CMS normally updates the entries that refer to an entry or asset when it’s renamed or deleted, but it can’t update a read-only entry. Instead, it refuses to delete an entry or asset that a read-only entry refers to, and to rename such an entry or asset, and tells the editor which read-only entries are in the way.

Not a security measure

The readonly option only affects the Sveltia CMS interface. It doesn’t stop anyone with write access to the repository from changing the content through Git or the Git hosting service. Use your Git host’s permissions, such as branch protection rules, to restrict write access.

Hiding the Collection ​

You can hide an entry collection from the Sveltia CMS interface using the hide option. This is useful for collections that are managed programmatically or through other means, and you don’t want editors to see or modify them.

yaml
collections:
  - name: posts
    label: Blog Posts
    folder: /content/posts
    hide: true
    fields:
      - { name: title, label: Title }
      - { name: body, label: Body, widget: richtext }
toml
[[collections]]
name = "posts"
label = "Blog Posts"
folder = "/content/posts"
hide = true

[[collections.fields]]
name = "title"
label = "Title"

[[collections.fields]]
name = "body"
label = "Body"
widget = "richtext"
json
{
  "collections": [
    {
      "name": "posts",
      "label": "Blog Posts",
      "folder": "/content/posts",
      "hide": true,
      "fields": [
        { "name": "title", "label": "Title" },
        { "name": "body", "label": "Body", "widget": "richtext" }
      ]
    }
  ]
}
js
{
  collections: [
    {
      name: "posts",
      label: "Blog Posts",
      folder: "/content/posts",
      hide: true,
      fields: [
        { name: "title", label: "Title" },
        { name: "body", label: "Body", widget: "richtext" },
      ],
    },
  ],
}

When the hide option is set to true, the collection will not appear in the Sveltia CMS interface, and editors will not be able to access or modify its entries.

Reordering Entries ​

When the reorder option is set to true, Sveltia CMS enables manual reordering of entries in the listing view. This is useful for collections where the order of the entries matters, such as a list of featured products or a custom navigation menu.

With this option enabled, users can reorder entries by dragging and dropping them or using the arrow buttons.

In a single-file collection, the entries can always be reordered without this option, which can’t be used there. The order of the objects in the array is the order of the entries, so no order field is written.

yaml
collections:
  - name: posts
    label: Blog Posts
    folder: /content/posts
    reorder: true
    fields:
      - { name: title, label: Title }
      - { name: body, label: Body, widget: richtext }
toml
[[collections]]
name = "posts"
label = "Blog Posts"
folder = "/content/posts"
reorder = true

[[collections.fields]]
name = "title"
label = "Title"

[[collections.fields]]
name = "body"
label = "Body"
widget = "richtext"
json
{
  "collections": [
    {
      "name": "posts",
      "label": "Blog Posts",
      "folder": "/content/posts",
      "reorder": true,
      "fields": [
        { "name": "title", "label": "Title" },
        { "name": "body", "label": "Body", "widget": "richtext" }
      ]
    }
  ]
}
js
{
  collections: [
    {
      name: "posts",
      label: "Blog Posts",
      folder: "/content/posts",
      reorder: true,
      fields: [
        { name: "title", label: "Title" },
        { name: "body", label: "Body", widget: "richtext" },
      ],
    },
  ],
}

By default, orders are saved in an additional property named order in each entry’s data, starting from 1. However, you can customize this setting by providing an object with a key property that specifies a different field name for storing the order value. For example, to use the weight field for Hugo or Zola, configure it like this:

yaml
collections:
  - name: posts
    label: Blog Posts
    folder: /content/posts
    reorder:
      key: weight
    fields:
      - { name: title, label: Title }
      - { name: body, label: Body, widget: richtext }
toml
[[collections]]
name = "posts"
label = "Blog Posts"
folder = "/content/posts"
reorder = { key = "weight" }

[[collections.fields]]
name = "title"
label = "Title"

[[collections.fields]]
name = "body"
label = "Body"
widget = "richtext"
json
{
  "collections": [
    {
      "name": "posts",
      "label": "Blog Posts",
      "folder": "/content/posts",
      "reorder": { "key": "weight" },
      "fields": [
        { "name": "title", "label": "Title" },
        { "name": "body", "label": "Body", "widget": "richtext" }
      ]
    }
  ]
}
js
{
  collections: [
    {
      name: "posts",
      label: "Blog Posts",
      folder: "/content/posts",
      reorder: { key: "weight" },
      fields: [
        { name: "title", label: "Title" },
        { name: "body", label: "Body", widget: "richtext" },
      ],
    },
  ],
}

Reordering Within Groups ​

Entering reorder mode normally clears any active grouping, so the entry list becomes a single flat sequence. If the order value is only meaningful within a group — for example, articles ordered per category — you can instead keep the list grouped while reordering by adding a group property to the reorder option. Its value is the name of one of the collection’s view groups:

yaml
collections:
  - name: articles
    label: Articles
    folder: /content/articles
    reorder:
      group: categories
    view_groups:
      groups:
        - name: categories
          label: Categories
          field: category
    fields:
      - { name: title, label: Title }
      - { name: category, label: Category }
      - { name: body, label: Body, widget: richtext }
toml
[[collections]]
name = "articles"
label = "Articles"
folder = "/content/articles"
reorder = { group = "categories" }

[[collections.view_groups.groups]]
name = "categories"
label = "Categories"
field = "category"

[[collections.fields]]
name = "title"
label = "Title"

[[collections.fields]]
name = "category"
label = "Category"

[[collections.fields]]
name = "body"
label = "Body"
widget = "richtext"
json
{
  "collections": [
    {
      "name": "articles",
      "label": "Articles",
      "folder": "/content/articles",
      "reorder": { "group": "categories" },
      "view_groups": {
        "groups": [{ "name": "categories", "label": "Categories", "field": "category" }]
      },
      "fields": [
        { "name": "title", "label": "Title" },
        { "name": "category", "label": "Category" },
        { "name": "body", "label": "Body", "widget": "richtext" }
      ]
    }
  ]
}
js
{
  collections: [
    {
      name: "articles",
      label: "Articles",
      folder: "/content/articles",
      reorder: { group: "categories" },
      view_groups: {
        groups: [{ name: "categories", label: "Categories", field: "category" }],
      },
      fields: [
        { name: "title", label: "Title" },
        { name: "category", label: "Category" },
        { name: "body", label: "Body", widget: "richtext" },
      ],
    },
  ],
}

With the above configuration, the entry list is grouped by category whenever a user enters reorder mode, and entries can only be dragged within their own group. Dropping an entry into a different group is rejected, because that would not change the category field that determines which group it belongs to.

A few things to keep in mind:

  • The group is referenced by name, so the view group must have one. The name property is required in the extended syntax shown above, and can also be added to individual entries in the plain array syntax.
  • The configured group replaces whatever grouping the user has selected in the Group menu. Their own selection is restored once they leave reorder mode.
  • Order values are still assigned as a single sequence starting from 1, numbered group by group. They do not restart at 1 in each group, so the first entry of the second group continues from where the first group ended.
  • If the named group is not defined in view_groups, Sveltia CMS raises a configuration error on startup.

Copyright © 2026 Kohei Yoshino