Drupal Compatibility
Strata supports Drupal 10 and 11 projects. The registry automatically adapts to your project's target version, filtering field types, widgets, formatters, and plugins to show only what's available.
Version support
When you create a project, you select a target Drupal version (10 or 11). Strata uses this to filter every registry lookup — field types, widgets, formatters, media sources, Views plugins, image effects, and more — to only show entries available in your version.
Registry entries can specify min_drupal_version and max_drupal_version bounds. For example, the image_convert_avif image effect is only available in Drupal 11. If your project targets Drupal 10, it won't appear in the image effects list.
The version filter is applied by the project's capability profile (getProfileForProject), which is the single source of truth for all registry reads. Changing a project's Drupal version immediately updates all available plugins without re-seeding.
The registry
The registry is a database of all Drupal plugins that Strata knows about. It is derived directly from Drupal core source code, not hand-maintained, so it stays accurate across releases.
Registry tiers
The registry operates in two tiers:
- Global tier — seeded from Drupal core, visible to every project. Contains 15 registry types with 119 entries and 28 modules. Managed by the
pnpm seedcommand. No application write path can produce global rows. - Project tier — custom entries scoped to a specific project. Used for contributed modules (Paragraphs, Address, Geolocation, etc.) that are not in core. Managed through the project settings registry page.
Resolution is always global + project, narrowed by the project's Drupal version. Both tiers are queried together so you see a unified list of available plugins.
Registry types
The global registry includes the following plugin types:
| Plugin type | What it provides |
|---|---|
| Field Types | Storage types like Text, Integer, Entity Reference, Image, Link, Date, Boolean, etc. |
| Field Widgets | Form input widgets for each field type (text field, autocomplete, select list, date picker, etc.) |
| Field Formatters | Display formatters for rendering field values (plain text, trimmed, image, link, label, etc.) |
| Media Sources | Source plugins for media entities (file, image, audio_file, video_file, oembed:video) |
| Views Display Plugins | Display types for Views (page, block, embed, feed, entity_reference) |
| Views Style Plugins | Style plugins for rendering Views output (default, HTML list, table, grid, RSS) |
| Views Row Plugins | Row plugins for rendering individual Views rows (fields, entity, RSS) |
| Views Pager Plugins | Pager plugins for Views pagination (full, mini, some, none) |
| Views Access Plugins | Access control plugins for Views (unrestricted, permission, role) |
| Views Cache Plugins | Cache strategy plugins for Views (none, tag, time) |
| Views Exposed Form Plugins | Exposed form plugins for Views filters (basic, input required) |
| Image Effects | Image style effects (scale, crop, resize, desaturate, rotate, convert, etc.) |
| Text Formats | Text filter formats (plain, basic HTML, full HTML) |
| Paragraph Behavior Plugins | Behavior plugins for paragraph types (contributed, empty by default) |
| Entity Types | Content entity types (node, taxonomy_term, media, user, etc.) and bundle mappings |
Compatibility mapping
Widgets and formatters declare which field types they're compatible with via a compatible_with mapping. Strata uses these mappings to filter the widget and formatter dropdowns when you define a field.
For example, the options_select widget is compatible with entity_reference, list_integer, list_float, and list_string field types. When you select one of these as your field type, the Select list widget appears as an option.
This filtering applies at multiple levels:
- In the field form — widget and formatter dropdowns are constrained by the selected field type
- In the display field configuration — widgets (form displays) and formatters (view displays) are constrained by the parent field's type
- In spreadsheet import — specified widgets and formatters are validated for compatibility
- In manifest import — registry references are validated against the target project's registry
Entity types
Strata understands Drupal's entity type hierarchy. Each content entity type has a corresponding bundle entity type (which defines the content types, vocabularies, etc.):
| Content entity | Bundle type | Strata tab |
|---|---|---|
node | node_type | Content Types |
taxonomy_term | taxonomy_vocabulary | Taxonomy Vocabularies |
media | media_type | Media Types |
block_content | block_content_type | Block Types |
paragraph | paragraph_type | Paragraph Types (contrib) |
Paragraph types require the contributed drupal/paragraphs module. Entity types that require contributed modules appear once those modules are added to your project's registry.
Module dependencies
When you use a field type, widget, or formatter that comes from a contributed module (rather than Drupal core), Strata automatically tracks that module as a dependency of your project. Dependencies are synced before every export and appear in the manifest.
Each dependency includes the module name, Composer package name (drupal/...), and a list of which fields require it, with their context (field name, widget/formatter, parent bundle). This makes it easy to know exactly which modules to install and why.
Contributed modules
The global registry covers Drupal core plugins. For contributed modules (Paragraphs, Address, Geolocation, Layout Builder, etc.), you can add custom registry entries scoped to your project.
Navigate to Project Settings > Registry to add custom field types, widgets, formatters, and modules. These entries are project-scoped — they only appear in the project they belong to, and are never mixed with other projects or the global catalogue.
When you export a manifest (v2.0), your project-scoped registry entries are included in the registry block. When you import a manifest that includes a registry block, the entries are added to the target project (additive upsert, never deletes).
Project cloning copies the source project's custom registry entries into the clone, so the new project starts with the same contributed module support.
Version-aware field filtering
Every registry query passes through the project's drupal_version filter. An entry is visible only when:
min_drupal_versionis null or the project version is greater than or equal to itmax_drupal_versionis null or the project version is less than or equal to it
This means plugins that were introduced in Drupal 11 won't appear in Drupal 10 projects, and plugins deprecated in Drupal 11 won't appear in Drupal 11 projects. The filtering happens at the query level, so switching a project's target version immediately updates all available plugins.