chore: shrink flat install: list by composing upstream drupal_cms_* recipes

[scottfalconer]

Context

From the architect review: the recipe currently flat-installs ~100 modules in install: but only applies one upstream recipe (drupal_cms_search) in recipes:, despite requiring nine drupal_cms_* packages in composer.json. PR #8's note explicitly deferred this cleanup, noting it "needs a controlled comparison against Drupal CMS recipe imports so we do not silently remove config Umami currently relies on."

Separately, while implementing PR #13 (SEO stack) I hit a concrete instance of the underlying issue: Drupal recipes do not auto-import config entities from install:-listed modules' config/install directories — only simple config (.settings.yml-style). That's why metatag.metatag_defaults.* (7 config entities) were all missing on a fresh install until I added explicit config.import: metatag: '*'.

This means the flat install: list is not only an architectural smell — it is actively shedding config entities from every contrib module in the list that ships them. The recipe's own bloated config/ directory is where those entities have been re-captured, which is why a drush site:export baseline was needed in the first place.

Goal

Shrink install: by composing upstream drupal_cms_* recipes instead of re-enumerating their modules.

Candidate upstream recipes to apply

From composer.json, already required:

recipes:
  - drupal_cms_admin_ui       # Gin + admin UX
  - drupal_cms_anti_spam      # honeypot, captcha, friendlycaptcha
  - drupal_cms_authentication # login_emailusername, gin_login
  - drupal_cms_forms          # webform, webform_ui
  - drupal_cms_helper         # already installed as module
  - drupal_cms_media          # media types, media_library, focal_point
  - drupal_cms_privacy_basic  # klaro, GDPR prep
  - drupal_cms_search         # already applied
  - drupal_cms_seo_basic      # easy_breadcrumb, redirect, redirect_404 (less than you'd think — it's basic hygiene, not metatag/sitemap; see PR #13)

Each of those recipes applies its own module set and configures it. The corresponding modules in Umami's current install: list can then come out.

Recommended approach

This cleanup is risky because the recipe has been shedding config entities the whole time, and config/ has ~500+ YAML files that encode what's been lost. A naive "move modules from install: to recipes:" will cause upstream recipe config to collide with Umami's shipped config.

Do it in phases, verified at each step by a fresh make dev-test-install:

Phase 1 — instrument

For each module currently in install:, determine:

• Does it ship any config entities in config/install/? (These are what the flat list silently loses.)
• Are any of those config entities currently re-shipped in Umami's config/ directory?
• Does any upstream drupal_cms_* recipe install this module with different config?

A small Drush/PHP script can enumerate this. Output a spreadsheet: module → ships entities? → currently captured in Umami config? → covered by which upstream recipe?

Phase 2 — apply one upstream recipe at a time

Start with the safest: drupal_cms_admin_ui. Apply it in recipes:, remove the modules it installs from Umami's install:, delete any Umami-config/ files that are upstream-owned rather than Umami-authored. Run make dev-test-install, diff the resulting drush config:export against the pre-change baseline, resolve deltas.

Repeat for drupal_cms_media, drupal_cms_forms, drupal_cms_anti_spam, drupal_cms_privacy_basic, drupal_cms_authentication.

Phase 3 — cleanup

Once all upstream recipes are applied, audit Umami's config/ directory for files that are no longer Umami's to own. Common suspects:

• block.block.claro_* / gin_* / stark_* — admin-theme block placements (likely owned by drupal_cms_admin_ui or the themes themselves)
• canvas.component.block.* — many are Canvas module defaults (owned by canvas)
• canvas.component.sdc.mercury.* — owned by mercury theme
• Most klaro.klaro_app.* — owned by drupal_cms_privacy_basic
• Most easy_email_override.* — owned by easy_email or easy_email_express

Phase 4 — fix the config.import gotcha for modules that stay flat

For any module that legitimately remains in install: (e.g., editoria11y, scheduler, klaro, or Umami-specific choices), check whether it ships config entities and add config.import: <module>: '*' if needed — same pattern PR #13 established for metatag.

Acceptance criteria

• install: list shrinks to ≤ 30 modules (Umami-specific + core additions not covered by any upstream recipe).
• recipes: list includes 6-8 drupal_cms_* recipes plus drupal_cms_search.
• config/ directory shrinks to only Umami-owned config: the Umami Canvas components, theme block placements, the basic_editorial workflow config, content type / field definitions, Umami views, Umami pathauto patterns, and Umami-specific config actions. Rough target: 100-150 files, down from the current ~500.
• Fresh make dev-test-install still passes the existing tests/src/Functional/ValidationTest.php assertions.
• All public routes remain 200, including the SEO-pack outputs from PR feat: add baseline SEO stack (metatag, schema_metatag, simple_sitemap) #13.
• drush config:export diff between post-cleanup and pre-cleanup is small and auditable.

Effort estimate

• Phase 1 (instrument): 2-4 hours.
• Phase 2 (apply recipes iteratively): 6-12 hours across multiple small PRs.
• Phase 3 (config/ cleanup): 4-6 hours.
• Phase 4 (config.import audit): 1-2 hours.

Total: ~2-3 days of focused work. Recommended as its own milestone, split across ~6 small PRs so each is independently verifiable.

Why it matters

Every module in the flat install: that ships config entities is a latent bug. Today that means default metatag settings, default editoria11y check presets, default klaro app definitions, default schema_metatag form mappings (if added) will not be there on a fresh install unless explicitly config.import-ed. PR #13 fixed this for metatag. A proper fix is to compose upstream recipes so the problem doesn't recur with every new contrib module anyone adds to the list.

Related

• PR chore: tighten recipe release hygiene #8 (chore: tighten recipe release hygiene) — deferred this work
• PR feat: add baseline SEO stack (metatag, schema_metatag, simple_sitemap) #13 (feat: add baseline SEO stack) — workaround for this issue on metatag/schema_metatag/simple_sitemap