We’ve recently changed the way you configure inputs. Check out our migration guide here.
The Data Editor uses a wide range of different inputs. Each input corresponds to a field in your front matter or data file, providing an editing interface for those values. Inputs have a type, label and a comment.
_inputs configuration has settings for input types, labels, comments, instance values, and input options.
Configuration for inputs is set with properties on the key matching the same name (e.g.
_inputs.image matches the
image front matter input).
Some configuration (notably input type) is automatically set for you based on the input key.
The above code shows the
_inputs configuration set in the same file, but you can choose where to set this for inputs across your site in the configuration cascade.
Changes the editing interface for an input. Each input appears and behave differently, takes different
options, and processes different values. See more details in the type section below.
For unknown types, or if the input contains an unsupported value (e.g. an array value in a text input), the
disabled type is used instead.
Changes the text above an input. Defaults to generating the label from the input key (e.g. “Page Title” for
Changes the subtext below the
label. Has no default. Supports a limited set of Markdown: links, bold, italic, subscript, superscript and inline code elements are allowed.
Useful for adding reminders or additional context for your team members on a specific input.
Configuration settings passed on to the input when displayed. These are specific to each input. The available types and their options are listed below.
Controls if and how the value of this input is instantiated when created. This occurs when creating files, or adding array items containing the configured input. Has no default. Must be one of
UUIDgenerates a uuidv4 (extremely unlikely to generate duplicates), useful for identifying unique items (e.g.
NOWgenerates the current datetime in the site’s configured timezone
hidden- Boolean or string
Toggles the visibility of this input. Useful for when you need an input to exist, but don’t want it edited or seen. Defaults to the naming convention,
true for input keys starting with an underscore and
If set as a boolean, the input is hidden based if
If set as a string, the input is hidden based on the value of another input. This can start with a
! to reverse the value.
publishedhides an input when the sibling input
!publishedhides an input when the sibling input
Specifies whether or not this input configuration should be merged with any matching, less specific configuration. Defaults to
The configuration cascade works by finding the most specific
_inputs entry. Usually, once an option is found in the cascade, there’s no reason to keep looking.
When this is
true, the cascade continues looking and each entry found is merged. This allows you to define a
comment globally, then a different
label for inputs in a collection without redefining the
comment. You can stop the cascade at any given point by setting
The type defines how inputs appear and behave. The type used for each field is based on (in order):
_inputsfor that key
colorwill give you a color picker)
This results in good defaults for unconfigured inputs, without hindering configured inputs. To change the type for an input you can use the
_inputs configuration, or the naming conventions:
Keys are converted into
snake_case before the convention is used, allowing you to use
Here are all the available input types, each with their own available options: