Editor Interfaces
An editor interface represents the look and feel of the entry editor in the web app. They are tightly coupled to a content type and define which widgets are rendered in both content fields and the sidebar.
For example, the following content type describes a typical blog post data structure. It has a title, a body, and a category that can be either “General”, “iOS” or “Android”.
An editor interface could, for example, define that the title field should be rendered as an input field (the widget ID is singleLine and it comes from a builtin widget the web app provides). It could then define that the body should be a normal text area (the widget id is multipleLine), and that the category should be rendered as a dropdown field (the widget id is dropdown).
The editor interface would look like this:
There are sets of compatible builtin widgets per content type field type:
Field control settings
You can pass custom settings to a field control that change the behavior or presentation of a widget.
The entry for a field of type Boolean, for example, would look like this.
If present, the settings object of a control must be an object. All widgets accept the helpText setting and use it to render extra information with the widget. Other settings are widget specific.
Custom field control widgets
Editor interfaces can be used to assign custom widgets to a field, sidebar or the entire entry editor. Currently there are two types of custom widgets: Apps and UI Extension. To do so just use one of app or extension namespaces and provide the widget ID:
Field groups
Field groups allow to organize how fields are displayed in the entry editor. Groups are defined with two properties editorLayout and groupControls, like in the following example:
Editor Layout
editorLayout describes the hierarchical organization of fields and groups. Groups are containers of fields or nested groups.
Items in editorLayout are of two types: group items or field items. These can, respecting some constraints,
be positioned in the layout as needed. When it’s present, editorLayout redefines the order in which fields are rendered in the entry editor. Leaf field items are displayed in the order they appear in the hierarchy.
Fields that are not assigned to a group will be automatically added to the first group defined in editorLayout.
Group controls
Similar to field controls, groupControls defines the widgets that render the groups present in editorLayout.
At the moment custom group widgets are not supported.
Like field controls, group controls can specify widget settings. The helpText property in settings contains textual information displayed in the group heading. The collapsedByDefault property controls whether the field set is collapsed at page load, false by default.
Groups constraints
- Top level items in
editorLayoutmust be group items, they must map to a group control with topLevelTabwidgetId. - Non top level groups must not map to to a group control with topLevelTab
widgetId. - Groups cannot be nested more than 1 level, top level group can have groups as children, but those can only contain fields.
Sidebar
By default the web app renders a set of predefined widgets (like “Status” or “Preview”) in the entry editor sidebar. Using the editor interface, it’s possible to alter the default sidebar by hiding, rearranging built-in widgets and/or adding custom widgets.
Sidebar items are rendered in exactly the same order as they are defined in the sidebar property. The sidebar above will render two widgets, the first being the builtin preview widget and the other one using an app.
Builtin sidebar widgets (widgets in the sidebar-builtin namespace) have the following IDs:
- Status (publish button):
publication-widget - Entry tasks:
content-workflows-tasks-widget - Content preview:
content-preview-widget - Incoming links:
incoming-links-widget - Translations (locale selection):
translation-widget - Entry-level versioning:
versions-widget
If the sidebar is in its default state and therefore only displays our built-in widgets, the sidebar property is left out from the editor interface. The default state is:
Custom editor
It is possible to add an editor or even completely replace the default entry editor provided by the web app with a custom editor implemented as an App or a UI Extension.
Once you’ve built your custom editor, you can use it by setting an optional editors property with your custom editor. This will render both the custom editor and the default editor. You can also disable the default editor, by including it in the list and marking it as disabled.
Similarly to field and sidebar configuration, instance parameters for an app or UI Extension can be passed as settings.
If the editor is in its default state and therefore only displays the default entry editor, the editor property is left out from the editor interface. The default state is:
Default configuration
In the EditorInterface entity, editors, sidebar and controls are optional fields.
Therefore, general defaults are defined which will be rendered if none of them is specified.
Groups properties editorLayout and groupControls are conditionally required, they are optional, but if one the two is part of an editor interface
then the other has to be too.
These defaults are defined and provided by the contentful-management.js library. To get these defaults, you can import them from the library as follows:
The default for controls are not constants, because they depend on which fields are defined. To solve this, contentful-management.js provides
a function that returns the default control for a given field.
Configuring editor interfaces with apps
Apps are able to edit editor interfaces as part of their configuration process. Details on how this works can be in our article about target state.
Access and modify editor interfaces
Using contentful-management.js you can access and modify editor interfaces. The following example shows how to retrieve an editor interface for a content type.
You can also modify editor interfaces using the client. The following example shows how to add (and then remove) a sidebar widget to an editor interface.
Custom apps can also be added to editor interfaces using the client. The following example shows how to add a custom app to an editor interface.