'Slug type' field which values can be auto-generated via a template

Currently, the slug is generated based on the name of the Story (Entry or Folder). In its default form, this field cannot be translated unless the ‘Translatable slugs’ app is installed (when using ‘Field level translations’). It’s also used as the default path in the visual editor and API (e.g. slugs that are returned in the ‘alternates’ array, ‘resolve_links’ object, links API, etc. ). This assumes that:

  • The customer wants the slugs to be based on the ‘Name’ of the Entry / Folder.
  • The content structure or hierarchy in Storyblok is identical to the website URL structure. If it is not, the Visual Editor will request a URL from the website that does not exist (resulting in a 404 page).

Note: the ‘Advanced paths’ app can be used as a workaround for this issue but currently this does not work in combination with the ‘Translated slugs’ app and alway requires a manual action from content editors (‘Real path’ needs to be defined for each Story).

  • By default, slugs don’t need to be translated.
  • The customer wants to base the URL structure of the website on the logic of the ‘Slug’ field.

Proposed solution:
Introduce a ‘Slug type’ field which can be added to ‘Content type’ components (but is not mandatory). It should have the following functionality:

  • The auto-generated value can be based on a template that can be set when the ‘Content type’ component is created. Example: {{prefix-field-X-field-Y-field-Z-suffix}}. Values from multiple fields can be used as input, concatenated by a separator (e.g. ‘-’). A fallback value can also be defined.
  • The auto-generated value can be overridden at any time by the content editor.
  • The ‘Slug type’ field can be set to ‘Translatable’ just like any other field.
  • Since it’s a ‘Slug type’ field values are automatically converted to URL friendly values (e.g. convert to lowercase, remove spaces, convert diacritics, etc.).
  • The field is exposed in the API’s and replaces the default ‘Slug’. Translated and alternate variations of a slug are always included in the response (e.g. a request for an English version of a published Story returns a response that includes published slugs for all configured languages as well as published slugs for alternate Stories). This simplifies the creation of Hreflang tags on pages or in sitemaps.
  • A maximum of one ‘Slug type’ can be added to a Content type component.
  • In case no ‘Slug type’ field is defined in a Content type component, the Visual Editor is disabled.
  • The Visual Editor can be configured to use the ‘Slug type’ field instead of the default Slug for a Content type.
  • The Visual Editor can be configured to use the routes (URL structure) that are actually used on the website in case the content hierarchy in Storyblok is different from the website.

Examples from other Headless CMS providers:

I am looking forward to hearing your feedback!

One more thing:

  • Uniqueness function to check if the slug is unique according to conditions that can be defined.

A Story is rendered as a page on the German website. A similar Story is rendered on the Austrian website. Both use the German locale, share the same slug and are managed from the same space. Since the websites are separate (e.g. different top level domains, subdomains, subdirectory) this would not cause a URL collision.

Current behaviour:
According to Storyblok these slugs are duplicates. Duplicate slugs are not allowed.