The Droost CMS recipe

Droost CMS is a drupal-recipe of type Site that layers on drupal_cms_starter. It exists so the whole stack (module, workflow, theme, the SDC display substrate and Canvas) arrives wired and consistent in one apply, and so there is one reference install every eval and every fix is measured against. droost.org runs on it.

What it composes

Layer	Provided by
Page building, media, SEO, admin UI	`drupal_cms_starter`
Tools, brain, search, router, gated build surfaces	`droost`, `droost_examples`, `droost_ui_patterns`, `droost_canvas`
The pipeline	`droost_workflow`
Structured-entity display through components	`ui_patterns`, `ui_patterns_field_formatters`
The MCP transport	`mcp_server`, configured with pagination 200, server name "Droost CMS", server instructions that mention the workflow
The theme	`droost_theme`, installed and set default; Mercury stays installed

The recipe deliberately carries no droost.settings action. Gates are the site owner's decision, so the recipe leaves every allow_* flag off and lets drush droost:install ask.

The shipped design pattern

config/core.entity_view_display.node.event.default.yml renders every field of the event content type through a single-directory component via UI Patterns component formatters: field label → heading prop, field value → content slot through the field's own core formatter. It was authored deterministically by droost_display_compose and round-trips byte-identically, so an agent can read it with droost_display_get, modify it, and re-compose it. A fresh site demonstrates the entity fields → props and slots → render pattern before anyone builds anything.

Theme blocks

Droost Theme ships its block placements (branding, main menu, messages, local tasks) as theme config/optional, which recipe-driven theme installs can skip. The recipe therefore ships the same block configs in its own config/ so a fresh site always gets the navbar. The theme's optional title block is deliberately not placed: Canvas pages and composed displays carry their own headings.

Verifying an install

bash

scripts/assert-recipe-applied.sh <ddev-site-dir>

The script checks the module roster, that droost_theme is default, the mcp_server settings, that the recipe carries no droost.settings action while the live site reports what is armed, that the front page returns 200 through Droost Theme, and that config schema validates. It refuses to say OK otherwise, and it is what the reference install is graded with.

Requirements and nuances

Drupal CMS 2.1+; the canvas + ui_patterns pair coexists with no root patch because droost_canvas bridges #3561618 while enabled.
Root-require droost, droost_theme and droost_cms with explicit constraints until they have stable releases.
The event machine name is unprefixed; see Install Droost CMS for the forward risk.
Local development only: do not deploy the result with Droost enabled.