Displays
Drupal separates what data a content type stores (fields) from how that data appears on forms and rendered pages. Strata models both sides so you can plan your display configuration alongside your content architecture.
Form displays vs. view displays
In Drupal, every fieldable bundle type — Content Types, Taxonomy Vocabularies, Media Types, Block Types, and Paragraph Types — has two categories of display configuration:
- Form displays control how the editing form is rendered. They determine which widget each field uses (e.g. autocomplete vs. select list for an entity reference), the order fields appear in, and whether a field is visible or hidden on a given form mode.
- View displays control how content is rendered for visitors. They determine which formatter each field uses (e.g. rendered entity vs. label for an entity reference), the field ordering, label visibility, and which fields are included or excluded from a given view mode.
Strata mirrors this separation. When you open a bundle entry (for example, a Content Type) you will see both a Form Displays tab and a View Displays tab alongside the Fields tab.
Default displays
When you create a new bundle entry — a Content Type, Media Type, Taxonomy Vocabulary, Block Type, or Paragraph Type — Strata automatically creates a Default form display and a Default view display, just as Drupal does when you add a new bundle through its admin UI.
Both default displays are created with mode set to default and status set to enabled. You do not need to create them manually. The auto-creation happens inside the same changeset as the bundle entry itself, so the change log records them together.
If you need additional display modes beyond the default (for example, teaser, full, or search_result), you can add them manually from the Form Displays or View Displays tab.
Managing display modes
A display mode is a named configuration that tells Drupal how to render a bundle in a particular context. The default mode is always present. Common additional modes include:
| Mode | Type | Typical use |
|---|---|---|
| default | Form & View | The standard editing form and full rendered output |
| teaser | View | Compact summary shown in listings and search results |
| search_result | View | Optimized layout for search result pages |
| search_index | View | Controls which fields are indexed for search |
| rss | View | Fields included in RSS feed output |
| register | Form | The user registration form (User entity) |
Each display mode entry has the following columns:
| Column | Description |
|---|---|
| Mode | The machine name of the display mode (e.g. default, teaser, full). Unique within the parent bundle. |
| Enabled | Whether this display mode is active. Disabled modes are defined but not used. |
| Field Groups | Optional JSON structure defining form tab/group layout from the field_group module. |
| Fields Configured | A computed count of per-field configuration entries nested under this display. |
Mode names must be unique within each bundle. You can add as many modes as your site design requires.
Display field configurations
Each display mode can have per-field configuration entries that override how individual fields behave in that display. These are nested one level deeper: a display field configuration belongs to a form display or view display, which itself belongs to a bundle.
To configure a field within a display, open the bundle entry, switch to the Form Displays or View Displays tab, then open the display mode you want to configure. Inside, you will see a Field Configuration tab where you can add entries.
Common columns
Every display field configuration entry has these columns, regardless of whether it belongs to a form display or a view display:
| Column | Description |
|---|---|
| Field | A reference to one of the fields defined on the parent bundle. Each field can appear at most once per display. |
| Visible | Whether the field is shown in this display. Hidden fields are excluded from rendering. |
| Weight | Controls the display order. Lower weights appear first, matching Drupal's ordering convention. |
| Region | The display region: "Content" (included in output) or "Hidden" (excluded entirely). |
Form display columns
When a field configuration belongs to a form display, these additional columns are available:
| Column | Description |
|---|---|
| Widget | The form widget to use for this field in this display mode. Constrained to widgets compatible with the field's type. |
| Widget Settings | Plugin-specific settings for the selected widget (JSON). Available settings are driven by the widget's registry entry. |
View display columns
When a field configuration belongs to a view display, these additional columns are available:
| Column | Description |
|---|---|
| Formatter | The field formatter that renders this field's value. Constrained to formatters compatible with the field's type. |
| Formatter Settings | Plugin-specific settings for the selected formatter (JSON). Available settings are driven by the formatter's registry entry. |
| Label | How the field label is displayed: "Above" (on its own line), "Inline" (beside the value), "Hidden", or "Visually hidden" (accessible but not visible). |
How displays relate to fields
The Fields tab and the display tabs are complementary. The Fields tab defines what data the bundle stores — each field has a type, a default widget, and a default formatter. The Form Displays and View Displays tabs define how those fields are presented in different contexts.
A field's widget and formatter on the Fields tab serve as the baseline. Display field configurations let you override that baseline per display mode. For example, a field_tags entity reference field might use an autocomplete widget on the default form but a select list widget on a simplified form mode.
Display field configuration entries reference fields through an entry_ref scoped to the grandparent — that is, the bundle that owns both the fields and the displays. This means the field picker in a display configuration shows only fields belonging to the same bundle, keeping references consistent.
Widget and formatter selections in display field configurations are constrained by the referenced field's type. Strata resolves the field type through the reference and filters the widget or formatter registry to show only compatible options. This matches Drupal's behavior where, for instance, you cannot assign an image formatter to a text field.
Supported bundle types
Form displays and view displays are available on all fieldable bundle types in Strata:
- Content Types
- Taxonomy Vocabularies
- Media Types
- Block Types
- Paragraph Types
Each of these bundle types receives automatic default form and view displays on creation and supports the full display field configuration workflow described above.
Views displays (Views module)
Strata also models Views displays as inline entries under the Views tab. These are conceptually different from the bundle view displays described above — they configure how a Views listing is presented (page, block, feed, etc.) rather than how a single entity's fields are rendered.
Each Views display entry has its own set of plugin references:
| Column | Description |
|---|---|
| Display Plugin | The display type (e.g. Page, Block, Feed, Attachment) |
| Path | The URL path for page displays |
| Style Plugin | How results are laid out (e.g. Table, Unformatted list, Grid) |
| Row Plugin | How each result row is rendered (e.g. Content, Fields) |
| Pager Plugin | Pagination style (e.g. Full, Mini, None) |
| Items Per Page | Number of results per page |
| Access Plugin | Access control for the display (e.g. Permission, Role, None) |
See the Content Architecture documentation for more on the Views tab and other entity types.
Next steps
- Read Content Architecture for the full set of entity types, fields, and inline editing
- Learn about Getting Started for a walkthrough of creating your first project and content types
- See the Manifest & Export documentation to understand how display configuration is exported