Umami Drupal CMS Site Template

This repository is the working package for the Umami Drupal CMS site template, currently targeting Drupal CMS 2.1+ and Drupal core 11.3+. It is intentionally structured so the recipe can be installed and tested from a fresh Drupal CMS checkout before any Drupal.org project split happens.

Status: Public preview. This repository is ready to share and test from GitHub, but it is not an official Drupal.org release. Normal downstream use still depends on tagged drupal/umami_next and drupal/umami_next_theme releases instead of the local path packages in packages/.

Package Layout

.
├── composer.json
├── recipe.yml
├── config/
├── content/
├── docs/
└── packages/
    ├── umami_next/
    └── umami_next_theme/

The root package is the site-template recipe (drupal/umami). The package directories contain local Composer packages for the custom module and theme that the exported recipe currently depends on.

Development Install Test

Use the local DDEV helper to create or refresh a separate Drupal CMS tester, mirror this source package into source/, require the local path repositories, and reinstall the recipe:

make dev-test-install

By default this uses ../umami-site-template-test. Override TESTER_DIR and TESTER_NAME if you need a different local tester:

make dev-test-install TESTER_DIR=../umami-release-smoke TESTER_NAME=umami-release-smoke

Manual equivalent:

mkdir umami-site-template-test
cd umami-site-template-test
ddev config --project-type=drupal11 --docroot=web --project-name=umami-site-template-test
ddev start
ddev composer create-project drupal/cms .
cp -R /path/to/umami-site-template-codex source
ddev composer config repositories.umami path source
ddev composer config repositories.umami_next path source/packages/umami_next
ddev composer config repositories.umami_next_theme path source/packages/umami_next_theme
ddev composer require drupal/umami:^1@dev drupal/umami_next:^1@dev drupal/umami_next_theme:^1@dev --with-all-dependencies
ddev drush site:install recipes/umami --site-name=Umami --account-name=admin --account-pass=admin -y

After local source changes, refresh the tester copy before rerunning Composer or install checks:

make dev-sync-source

The acceptance gate is a fresh DDEV install that reaches the Umami site without manual UI changes.

Release Packaging

The root package is a Drupal CMS site-template recipe, but the module and theme under packages/ must be released as their own Composer packages before the recipe can be published for normal downstream use.

Release order:

1. Tag and release drupal/umami_next.

2. Tag and release drupal/umami_next_theme.

3. Update this recipe's composer.json to require tagged releases instead of local development constraints, for example:

   "drupal/umami_next": "^1.0@alpha",
   "drupal/umami_next_theme": "^1.0@alpha"

4. Run a clean install from packages.drupal.org with only:

   ddev composer require drupal/umami:^1.0@alpha --with-all-dependencies
   ddev drush site:install recipes/umami --site-name=Umami --account-name=admin --account-pass=admin -y

The ^1@dev constraints and path repositories are local development mechanics only. Do not ship a public release that depends on them.

The release archive excludes packages/, tests, CI configuration, and local development install notes via .gitattributes. Public releases should depend on tagged drupal/umami_next and drupal/umami_next_theme packages instead of bundling those development path repositories.

Before publishing to Drupal.org, confirm the final project namespace and package names. This source currently uses drupal/umami, but the Drupal.org umami namespace has existing history and may require maintainer coordination.

Validation

The fast local install gate is:

make dev-test-install

The repository also ships PHPUnit coverage for recipe requirements, installability, public routes, Canvas component references, editorial workflow coverage, sitemap output, and homepage curation. Those tests should be run in a fresh Drupal CMS project with the local recipe, module, and theme required as path repositories before tagging a release.

Configuration Ownership

This package is install-time source of truth for a new Drupal CMS site. Site structure, sample content, Canvas templates, menus, and block placement are owned by the recipe export in config/ and content/.

The recipe content intentionally keeps the original Drupal core Umami demo recipes and photography contributed by Drupal community members. Future content expansion should preserve that source and licensing pattern instead of replacing the community corpus with synthetic filler.

After installation, the downstream site owns normal Drupal configuration management. A production site should set its own config sync directory outside the web root and commit post-install site changes in that downstream project. Do not treat sites/default/files/sync from a local DDEV install as release source.

Environment-specific settings are intentionally not shipped in the recipe:

• trusted_host_patterns must be configured per environment. A permissive .* value is acceptable only in local DDEV-generated settings.
• file_private_path should point to a private directory outside the docroot for production and shared test environments, especially because Webform can collect uploads.
• CAPTCHA keys and outbound mail settings must be supplied by the installing site, not committed to this package.

Current State

This package started from a drush site:export baseline from the working Drupal CMS site. Several cleanup passes have already moved public discovery and site services onto Drupal-native foundations: recipe and story archives are Views, topics are taxonomy term pages with aliases, search uses the Drupal CMS Search API/View, contact uses Webform and editable social menu links, and metadata/sitemap discovery uses Metatag and Simple XML Sitemap.

The remaining cleanup passes should:

• Reduce the flattened recipe export toward Drupal CMS recipe dependencies where possible.
• Remove config inherited from the drush site:export baseline when an upstream Drupal CMS/core/contrib recipe owns it.
• Add per-bundle Schema.org JSON-LD mappings with Schema Metatag, especially for recipe structured data.
• Keep the custom module limited to code that cannot be expressed as recipe/config/theme.
• Continue moving presentation structure into fields, Views, menus, media, Canvas templates, and components instead of Twig/PHP hardcoding.
• Keep homepage recipe curation driven by Drupal's editable node flags: promote includes recipes in homepage curation and sticky pins the first row unless a future Canvas-native curation model replaces it.
• Preserve installability evidence for every cleanup pass.

See docs/RECIPE_OWNERSHIP.md for the current recipe ownership matrix and docs/VALIDATION.md for source-maintainer validation notes and upstream findings discovered during clean-install intent testing.