Drupal CMS

#3584002: The site exporter should try to actually determine package names, rather than assuming they all start with `drupal/`

Thu, 09 Apr 2026 19:40:45 +0000

Project: Drupal CMS
Type: Normal bug report
Status: Fixed
Diff: 61236c8
Discussion: #3584002 · 1 contributor · 8 comments
Followers: 1

Summary

The site exporter previously assumed all non-core extensions had Composer package names starting with drupal/. This confused people and created extra work when extensions used a different vendor namespace. The exporter now asks Composer for the actual package name, falling back to drupal/ only when it cannot be determined.

Impact

No upgrade or configuration changes required.

Technical details

The SiteExporter class in drupal_cms_helper builds a list of Composer dependencies when exporting a site as a recipe. In getExtensionRequirements(), the old code derived the package name with 'drupal/' . ($extension->info['project'] ?? $name), which is wrong for any extension whose Composer package uses a non-drupal vendor prefix.

The fix adds a private getPackageName() method that runs composer config name --working-dir=<extension path> via Symfony\Component\Process\Process to read the actual package name from the extension's composer.json. The PHP interpreter and Composer executable paths are statically cached across calls since they are "a tad expensive to compute." Composer is located using ExecutableFinder (with .phar added as a suffix), checking both the system PATH and a locally installed composer/composer package via InstalledVersions::getInstallPath().

If the process fails, the method falls back to the old drupal/ prefix logic and logs a warning. The author acknowledged this is a performance hit but noted that exporting a site is not performance-sensitive.

Contribution

Timeline

Opened: April 9, 2026
Committed: April 9, 2026

Key contributors

phenaproxima (Acquia)
antiorario

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3580694: The project template should always place config outside the web root by default

Tue, 24 Mar 2026 21:33:54 +0000

Project: Drupal CMS
Type: Normal feature request
Status: Fixed
Diff: 1accade
Discussion: #3580694 · 1 contributor · 6 comments
Followers: 3

Summary

The Drupal CMS project template now places the configuration sync directory outside the web root by default. New sites created from the template will store exported configuration in a config/sync directory at the project root, preventing direct web access to configuration files. This follows Drupal security best practices. Existing sites are not affected.

Impact

Affects site owners.

Config change: New projects place config sync directory at ../config/sync (outside web root) by default

Technical details

The project template already uses a relocated web root at web/. This change adds a config/sync directory as a sibling to the web root, keeping configuration files outside the publicly accessible directory tree.

The implementation uses the drupal-scaffold Composer plugin's file-mapping feature to append settings to default.settings.php. A new assets/append-default.settings.php.txt file contains PHP code that sets $settings['config_sync_directory'] to realpath('../config/sync') if that directory exists. The template includes an empty config/sync directory with a .gitkeep file.

The test suite in SiteTemplateInstallTest.php was updated to mirror the new assets/ directory along with composer.json. The test switched from using copy() to Filesystem::mirror() with a Finder to include both the assets directory and composer.json file.

Contribution

Timeline

Opened: March 21, 2026
Committed: March 24, 2026 (2 days and 2 commits later)

Key contributors

phenaproxima (Acquia)
brianperry
dorficus (HeroDevs)

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3580308: Add 'Created by' to the site template listing in the installer

Thu, 19 Mar 2026 15:56:56 +0000

Project: Drupal CMS
Type: Normal task
Status: Fixed
Diff: 5c4207f
Discussion: #3580308 · 2 contributors · 8 comments
Followers: 2

Summary

The Drupal CMS installer now displays who created each site template on the installation card. This helps site builders understand the source and authorship of available templates when choosing which one to install. Templates now show a "Created by" line with the organization or individual responsible for the template.

Impact

No upgrade or configuration changes required.

Technical details

The SiteTemplate class now includes an optional creator property that stores the name of the template's creator or organization. This property is populated from the site-templates.yml configuration file for contributed templates, or from a recipe's extra.drupal_cms_installer.creator key for recipe-based templates.

The constructor was updated to accept the creator parameter and pass it through to the template preprocessor. The fromRecipe() method was also updated to extract creator information from the recipe's extra metadata.

The template card rendering adds a new "Created by" line in the description area, styled with smaller text and lighter color to distinguish it from the main description. The Twig template checks if a creator is set and displays it using a translatable string. CSS adjustments ensure proper spacing between the template name, creator attribution, and description text.

A default screenshot file was also added to serve as a fallback when templates don't provide their own screenshot, and the $screenshot parameter now defaults to this file if not explicitly provided.

Contribution

Timeline

Opened: March 19, 2026
Committed: March 19, 2026

Key contributors

pameeela (Technocrat)
phenaproxima (Acquia)

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3580130: Add a generic AGENTS.md to the project template

Thu, 19 Mar 2026 02:18:51 +0000

Project: Drupal CMS
Type: Normal feature request
Status: Fixed
Diff: d6f6733
Discussion: #3580130 · 1 contributor · 10 comments
Followers: 2

Summary

New Drupal projects now include an AGENTS.md file that provides guidance for AI coding assistants. This file documents common commands, workflows, and best practices for working with a Drupal site using DDEV and Composer. It helps AI agents understand how to start the local environment, install modules, manage configuration, and follow project conventions. The file is intended as a starting point that can be customized for specific projects.

Impact

No upgrade or configuration changes required.

Technical details

The AGENTS.md file is added to the project_template directory and provides machine-readable guidance for AI coding assistants working with Drupal projects. The file covers four main sections: local DDEV environment commands, common Drupal workflows (adding modules, running updates, importing and exporting configuration), guardrails to prevent common mistakes (like committing secrets or vendor directories), and references to DDEV and Drupal configuration management documentation.

The file assumes a standard Composer-based Drupal installation with DDEV for local development. It uses simple bullet-point format with concrete command examples that AI agents can parse and execute. All commands are prefixed with ddev to run in the containerized environment.

The tagging script was updated to transform the file for the cPanel template variant, which uses the current directory as webroot instead of a web/ subdirectory. This transformation strips web/ prefixes from paths mentioned in the AGENTS.md file to match the cPanel project structure.

Contribution

Timeline

Opened: March 19, 2026
Committed: March 19, 2026

Key contributors

phenaproxima (Acquia)
scott falconer (Acquia)

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3579194: Add the partner templates to the installer

Wed, 18 Mar 2026 17:24:28 +0000

Project: Drupal CMS
Type: Normal task
Status: Fixed
Diff: 37d8c2a
Discussion: #3579194 · 3 contributors · 10 comments
Followers: 4

Summary

Drupal CMS now includes six site templates in the installer: Meridian Charter School (a paid template), Archimedes, Convivial Gov, Healthcare, Pulse, and Local. These templates provide ready-to-use starting points for education, government, healthcare, and local council websites. Site builders can now select from these professionally designed templates during installation to quickly launch sites tailored to specific sectors.

Impact

No upgrade or configuration changes required.

Technical details

The site-templates.yml file in the drupal_cms_installer module now defines six site templates instead of an empty array. Each template entry specifies its name, description, screenshot URL, package name, and related links. One template (Meridian Charter School) includes purchase information with pricing, purchase URL, and a validation URL for license key verification.

The ContentLoader class was updated to exclude easy_email entities from export, alongside the existing search_api_task exclusion. This prevents email entities from being inadvertently included in content exports when creating site templates.

The SiteTemplate::createFromRecipe() method now reads an optional links array from the recipe's extra metadata under the drupal_cms_installer key, allowing recipe-based templates to define their own related links.

CSS changes were made to improve the installer UI. The arrow-up-right icon that was previously only shown for premium template links is now displayed for all external links in template descriptions. The max-width restriction on template descriptions was removed, and some CSS selectors were consolidated between the add-ons and premium template stylesheets.

The site-templates.yml file is always pulled from the default branch of the repository, so it was removed from the 2.1.x release branch during the cherry-pick to avoid conflicts.

Contribution

Timeline

Opened: March 13, 2026
Committed: March 18, 2026 (4 days and 2 commits later)

Key contributors

pameeela (Technocrat)
phenaproxima (Acquia)
mherchel (Dripyard)

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3579163: Add support for listing paid site templates in the installer

Tue, 17 Mar 2026 22:08:57 +0000

Project: Drupal CMS
Type: Normal feature request
Status: Fixed
Diff: 689f589
Discussion: #3579163 · 3 contributors · 43 comments
Followers: 4

Summary

The Drupal CMS installer can now list and install paid site templates. During installation, site builders can browse premium templates, view pricing and purchase links, and install them using a license key provided by the vendor. When a paid template is selected, the installer opens a purchase URL in a new tab, then prompts for a license key that authorizes Composer to download the package from the vendor's repository. This infrastructure supports multiple site template vendors offering commercial starter kits through the installer.

Impact

No upgrade or configuration changes required.

Technical details

The installer's site template infrastructure was extended to represent both free and paid templates through a SiteTemplate value object. This object encapsulates metadata including name, description, screenshot, package information, pricing, purchase URLs, and repository details.

The SiteTemplateForm reads template definitions from a remotely curated site-templates.yml file, and supports a per-site override via sites/default/site-templates.php for hosts or testing scenarios. Templates can specify an alternate Composer repository and an authorization type (currently only bearer tokens are supported).

When a paid template is selected, the installer collects a license key through a modal dialog with client-side UUID formatting. The key is validated by attempting to query the package from the vendor's repository. If successful, Composer is configured with the bearer token in auth.json and the repository is added to composer.json. The installer then proceeds with normal template installation.

The implementation includes comprehensive test coverage through kernel tests for the SiteTemplate class, functional tests for the installer flow, and a build test that simulates installing a paid template from a protected repository using a test HTTP server.

Contribution

Timeline

Opened: March 13, 2026
First commit: March 14, 2026 (1 day later)
Last commit: March 17, 2026 (3 days and 14 commits later)

Key contributors

phenaproxima (Acquia)
mherchel (Dripyard)
andyg5000 (Dripyard)
pameeela (Technocrat)

Collaboration

This feature was developed through close collaboration between Acquia (phenaproxima) and Dripyard (mherchel, andyg5000), with design review from pameeela. The work progressed through multiple merge requests over several days, with phenaproxima building the backend infrastructure and validation logic, mherchel implementing UI/UX and styling, andyg5000 adding server-side license validation, and pameeela contributing style refinements. The implementation required updating a core patch to make profile build tests discoverable by PHPUnit.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3579729: Add an `overwrite` option to `drush site:export`

Tue, 17 Mar 2026 16:37:23 +0000

Project: Drupal CMS
Type: Normal feature request
Status: Fixed
Diff: 73ee652
Discussion: #3579729 · 1 contributor · 6 comments
Followers: 1

Summary

The drush site:export command now supports an --overwrite option that allows you to re-export a site to an existing directory. Previously, the command would fail if the destination directory already existed, requiring manual deletion before exporting again. This makes it easier to iterate on site exports during development without manually cleaning up directories between runs.

Impact

No upgrade or configuration changes required.

Technical details

The SiteExportCommand class in the drupal_cms_helper module now accepts an --overwrite option. When this option is provided, the command skips the check that would normally fail if the destination directory exists.

The underlying SiteExporter::copyBaseRecipe() method was also updated to exclude config and recipe.yml from the base recipe when mirroring files, in addition to the existing content exclusion. This ensures these key files are always regenerated during export. The delete option was removed from the Filesystem::mirror() call, which means overwriting will only update files that are part of the export, not delete everything in the destination first. This preserves any additional files in the destination directory (like .git directories from version control).

The test coverage confirms that overwriting replaces exported files like recipe.yml while leaving untouched files like .git directories intact.

Contribution

Timeline

Opened: March 17, 2026
Committed: March 17, 2026

Key contributors

phenaproxima (Acquia)

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3579616: The site:export command should always use drupal_cms_site_template_base as a base, if available

Tue, 17 Mar 2026 02:17:21 +0000

Project: Drupal CMS
Type: Normal feature request
Status: Fixed
Diff: c72081f
Discussion: #3579616 · 1 contributor · 7 comments
Followers: 2

Summary

The site export command now defaults to using the Drupal CMS site template starter kit as a base, making it easier to create new site templates. Running drush site:export with no arguments produces a complete, working recipe with documentation, tests, and a screenshot. The exported recipe is self-contained and does not depend on other recipes, simplifying the site template creation workflow for DrupalCon Chicago and the Drupal CMS marketplace.

Impact

No upgrade or configuration changes required.

Technical details

The site:export command previously allowed exporting to any base recipe and attempted to merge changes into existing recipe files. This approach was overcomplicated and error-prone for the primary use case: creating new site templates for the Drupal CMS marketplace.

The command now automatically uses drupal_cms_site_template_base (the site template starter kit) as the default base if available. Both the Drush command and the UI export controller check for the starter kit's existence using a new SiteExporter::getRecipePath() method, which determines where Composer installs recipes by parsing the project's composer.json.

The export process now completely overwrites recipe.yml and composer.json rather than merging changes. The generated recipe.yml contains only the site name, type, installed extensions, and config actions—no references to other recipes. The composer.json file is rebuilt from scratch with requirements for all installed extensions, removing any starter kit development dependencies.

This produces monolithic site templates that are self-contained and ready to publish. The export includes all content, configuration, documentation, tests, and supporting files from the starter kit (README, CI configuration, screenshots), but excludes the starter kit's sample content.

The installer form no longer stores the selected base template in state, since the export functionality now handles this automatically.

Contribution

Timeline

Opened: March 16, 2026
Committed: March 17, 2026

Key contributors

phenaproxima (Acquia)

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3560518: Insecure credential storage used by drupal_cms_ai recipe as default

Mon, 16 Mar 2026 20:10:59 +0000

Project: Drupal CMS
Type: Normal task
Status: Fixed
Diff: 5df700f
Discussion: #3560518 · 6 contributors · 84 comments
Followers: 11

Summary

The Drupal CMS AI recipe now uses the Easy Encryption module to protect API keys and other sensitive credentials. Previously, credentials were stored in plain text within Drupal configuration, where they could be exported to version control or database backups. Easy Encryption automatically intercepts key creation and transparently encrypts values at rest using libsodium sealed box encryption. Encryption keys are stored outside the web root when possible, falling back to Drupal state when write access is unavailable. This happens automatically when applying the AI recipe or creating keys through the UI, with no additional steps required from site owners.

Impact

Affects module maintainers.

New API: New easy_encryption module dependency provides transparent encryption of credentials stored via the Key module.

Technical details

The drupal_cms_ai recipe adds a dependency on the Easy Encryption module to secure credentials by default. Easy Encryption provides a Key provider plugin that intercepts key creation and automatically upgrades Configuration (plaintext) providers to Easy Encrypted providers. It uses libsodium's sealed box design (sodium_crypto_box_seal), which allows encryption with a public key and decryption only with the corresponding private key stored on the server.

When a new Key entity with the Configuration provider is created, Easy Encryption transparently switches it to use encrypted storage. The module attempts to write encryption keys to a directory outside the web root with restrictive permissions (0700). If that fails, it falls back to storing the encryption key in Drupal's state system, which is not exported with configuration. A warning appears in the status report when this fallback is active.

The sealed box design supports future workflows where credentials can be encrypted off-server using only the public key, then deployed to production where only the private key can decrypt them. This aligns with patterns used in Symfony's secrets management.

The drupal_cms_ai recipe was refactored to create a single ai key entity with an encrypted provider, replacing the previous approach of separate plaintext keys per AI provider. The recipe uses an environment variable default for the API key input, allowing non-interactive application via environment variables.

Upgrade

No code changes are required for existing Drupal CMS sites. The Easy Encryption module is added as a dependency and works transparently.

For sites applying the drupal_cms_ai recipe after this change, API keys will be encrypted automatically. For sites that already applied the recipe before this change, existing keys remain in plaintext configuration. Site owners can manually re-create keys to benefit from encryption, or use Easy Encryption's export/import functionality to transfer keys between environments.

When moving a site between environments, encryption keys must be transferred separately from configuration exports. Easy Encryption provides an admin UI at /admin/config/system/easy-encryption to export and import encryption keys. See the Easy Encryption documentation for transfer workflows.

Contribution

Timeline

Opened: November 28, 2025
First commit: December 6, 2025 (7 days later)
Last commit: March 16, 2026 (3 months and 6 commits later)

Key contributors

mxr576 (Pronovix)
phenaproxima (Acquia)
longwave (Full Fat Things)
pameeela (Technocrat)

Collaboration

This issue underwent significant evolution over nearly four months. The original proposal called for using the Key module with file-based storage for encryption keys. An early implementation attempted to set up AES encryption with keys stored in a .keychain directory outside the web root, but was reverted after concerns that storing encryption keys in plaintext on the filesystem provided only security theater.

Extensive discussion with security team members and cryptography experts led to the conclusion that no zero-configuration solution can provide perfect security. The team requested formal security review, but learned that the Drupal security team reviews reported vulnerabilities rather than proposed architectures. This left the architectural decisions to the Drupal CMS team.

After exploring options including HSM integration, external key management services, and hosting provider partnerships, the team settled on Easy Encryption, a new module created specifically to address this credential security challenge. The module was developed in a sandbox, then promoted to a full project with extensive documentation and architecture decision records.

A key debate centered on whether the state storage fallback constituted acceptable security versus security theater. The consensus was that encrypting credentials in configuration and storing the encryption key in state is meaningfully better than plaintext credentials in exportable configuration, even if it does not defend against a fully compromised server. This pragmatic approach acknowledges that Drupal CMS targets marketers and small site owners who would otherwise have no credential protection at all.

The final implementation was committed to Drupal CMS 2.x and 2.1.x, with documentation follow-up deferred to a separate issue.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3578624: Fix utility page content template config

Wed, 11 Mar 2026 21:59:33 +0000

Project: Drupal CMS
Type: Major bug report
Status: Fixed
Diff: 9c81398
Discussion: #3578624 · 3 contributors · 12 comments
Followers: 3

Summary

Drupal CMS 2 using the Mercury starter template displayed an error on utility pages like the Privacy Policy page. The error occurred because the heading component in the page content template was configured with "No URL" as a default value, which the component rejected as an invalid URL format. The fix changes this default to an empty string, eliminating the error while still allowing URLs to be added when needed.

Impact

No upgrade or configuration changes required.

Technical details

The canvas.content_template.node.page.full.yml configuration file in the drupal_cms_starter recipe defined a heading component with a url input value of "No URL". The Mercury heading component validates URL inputs and throws a runtime error when it receives "No URL" as a value, treating it as an invalid URL format.

The fix changes the default url input from "No URL" to an empty string in the configuration. An empty string is accepted by the component's validation, allowing pages to render without errors. The component still supports the URI format with autocomplete widget functionality when a URL is actually provided.

This was a configuration issue in the starter recipe rather than a code bug. The initial "No URL" value was likely intended as a placeholder but did not match what the component expected for an empty state.

Contribution

Timeline

Opened: March 11, 2026
Committed: March 11, 2026

Key contributors

roaguicr
pameeela (Technocrat)

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3578145: Strip site name & email from the site:export

Tue, 10 Mar 2026 02:22:25 +0000

Project: Drupal CMS
Type: Normal task
Status: Fixed
Diff: 2fc20b4
Discussion: #3578145 · 2 contributors · 11 comments
Followers: 2

Summary

The drush site:export command in Drupal CMS now excludes the site name and email address from exported site templates. These values are typically collected during installation and vary between sites, so they should not be part of a reusable template. This ensures that exported site templates are cleaner and can be applied to new sites without carrying over site-specific information.

Impact

No upgrade or configuration changes required.

Technical details

The SiteExporter class now explicitly unsets the name and mail keys from the system.site configuration before writing the recipe YAML file. This prevents site-specific values collected during installation from being included in exported site templates.

The change also includes a fix for a related bug where user 1 could be statically cached with stale field definitions during command-line installation with a monolithic site template. The RecipeSubscriber::onApply() method now accepts the RecipeAppliedEvent parameter and resets the user storage cache for user 1 when applying a Site-type recipe during CLI installation. This prevents errors when the user account is modified by SiteConfigureForm during installation.

Test coverage was added to verify that the site name and mail are not present in the exported recipe configuration.

Contribution

Timeline

Opened: March 10, 2026
Committed: March 10, 2026

Key contributors

pameeela (Technocrat)
phenaproxima (Acquia)

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3577923: SiteExporter should remove recipe dependencies

Mon, 09 Mar 2026 13:01:54 +0000

Project: Drupal CMS
Type: Normal task
Status: Fixed
Diff: 577686e
Discussion: #3577923 · 1 contributor · 6 comments
Followers: 1

Summary

Drupal CMS now exports sites as truly standalone packages. When exporting a configured site as a recipe, the exporter now removes references to any recipes that were originally applied during setup. This eliminates redundant dependencies and makes exported sites cleaner and faster to install. The exported recipe contains all the configuration and content from those original recipes, so keeping them as dependencies was unnecessary and confusing.

Impact

No upgrade or configuration changes required.

Technical details

The SiteExporter class creates monolithic recipes that include all configuration from a site. Previously, if a site was built from recipes (like Drupal CMS starter kits), the exporter preserved the recipes key in recipe.yml and the corresponding Composer dependencies in composer.json. This was redundant because the exported recipe already includes everything those base recipes provided.

The change refactors the export flow. The updateRecipe() method now returns the list of recipe names extracted from the recipes key before removing it from recipe.yml. This list is passed to updateComposerJson(), which filters out matching packages from the requirements. The matching uses basename() to compare the recipe name from recipe.yml against package names.

The implementation also reorders operations: updateComposerJson() now runs after updateRecipe() so it can receive the recipe list. Test coverage was expanded to verify recipes are removed from both files and that starter kit-specific configuration is cleaned up.

Contribution

Timeline

Opened: March 9, 2026
Committed: March 9, 2026

Key contributors

phenaproxima (Acquia)

Collaboration

This issue was opened and resolved by phenaproxima in a single day. The contributor manually tested the changes and confirmed solid test coverage before merging to both the 2.x and 2.0.x branches. The straightforward execution suggests this was a clear improvement identified during Drupal CMS development.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3575283: Add the ability to export a site template as a ZIP file

Mon, 09 Mar 2026 00:30:57 +0000

Project: Drupal CMS
Type: Normal feature request
Status: Fixed
Diff: dfd34d6
Discussion: #3575283 · 4 contributors · 24 comments
Followers: 6

Summary

Drupal CMS now provides an internal route that exports the current site as a downloadable ZIP file containing a recipe. This makes it possible to capture a customized site's configuration and content for reuse. The route is not exposed in the UI by default, allowing individual site templates to decide where and when to make it available. Sites based on the starter kit can optionally include this export capability.

Impact

No upgrade or configuration changes required.

Technical details

The drupal_cms_helper module adds a new route at /admin/config/development/site-export that returns a ZIP archive containing a site recipe. The route controller ExportController uses the existing SiteExporter service to generate the recipe, which includes configuration, content, and metadata.

The SiteExporter::export() method now accepts an optional $base parameter to copy files from a base recipe template. During installation, when a user selects the starter kit template, the installer stores its path in state. The export controller retrieves this path to include template-specific files like README and CI configuration in the exported archive.

The route requires the administer site configuration permission but is intentionally not linked anywhere in the UI. Individual site templates can add menu links or other UI elements to expose this functionality where appropriate. The .htaccess file is removed from the exported config directory since site templates are meant to be shared.

The implementation went through several iterations, first attempting to add a button to the config export form, then reverting due to UX concerns, and finally settling on an invisible route that templates can expose as needed.

Contribution

Timeline

Opened: February 23, 2026
First commit: February 23, 2026
Last commit: March 9, 2026 (13 days and 8 commits later)

Key contributors

phenaproxima (Acquia)
thejimbirch (Kanopi Studios)
penyaskito (Acquia)
pameeela (Technocrat)

Collaboration

The change took a winding path to its final form. Initially committed with a button in the config management UI, it was quickly reverted after UX review found that location confusing. Discussion then explored creating a separate module, but the maintainer preferred keeping the functionality in drupal_cms_helper alongside existing dev tooling.

The breakthrough came when the team decided to create an invisible route that individual site templates could expose through menu links. This approach ensures only sites meant for customization and export would show the feature. Over eight commits and two weeks, the implementation was refined to remove unnecessary access checks and properly integrate with the installer's template selection.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3577570: SiteExporter should not set a version in the exported composer.json

Fri, 06 Mar 2026 15:47:38 +0000

Project: Drupal CMS
Type: Normal bug report
Status: Fixed
Diff: 8c4a8fe
Discussion: #3577570 · 1 contributor · 7 comments
Followers: 1

Summary

The site export tool now leaves version numbers out of the exported composer.json file. Previously, it would set a default version of 1.0.0 if none was defined. This caused problems when trying to install development branches of exported recipes using Composer. The packaging pipeline will now handle version numbering instead, allowing dev branches to work correctly.

Impact

No upgrade or configuration changes required.

Technical details

The SiteExporter class previously set a default version: 1.0.0 in the exported composer.json if no version was already present. This was done alongside setting a default package name to ensure the recipe was installable by Composer.

However, hardcoding a version in the exported recipe made development branches uninstallable. Composer expects dev branches to follow specific version constraints, and a static 1.0.0 conflicts with those expectations.

The fix removes the line that sets a default version ($data['version'] ??= '1.0.0'), delegating version assignment to the packaging pipeline. The exporter still sets a default package name based on the export directory name, which remains required for Composer compatibility.

The change also includes updates to DefaultContentSubscriber to handle taxonomy term references with target ID 0 (terms at the vocabulary root), preventing export failures. This is a workaround for a separate issue tracked in the codebase.

Additionally, when an extension package version cannot be determined, the exporter now falls back to a wildcard constraint (*) with a warning, rather than skipping the requirement entirely.

Contribution

Timeline

Opened: March 6, 2026
Committed: March 6, 2026

Key contributors

phenaproxima (Acquia)

Collaboration

This issue was opened and resolved on the same day (March 6, 2026) by phenaproxima. The problem was discovered when exported recipes could not be installed from development branches, blocking workflow. The fix was straightforward once identified: simply stop setting a default version and let the packaging infrastructure handle it. The rapid turnaround suggests this was a critical blocker for the Drupal CMS project's recipe export functionality.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3576540: Authenticated users should not have permission to access the dashboard by default, because there's nothing for them to do there

Fri, 06 Mar 2026 14:14:26 +0000

Project: Drupal CMS
Type: Normal bug report
Status: Fixed
Diff: bb5f874
Discussion: #3576540 · 4 contributors · 25 comments
Followers: 4

Summary

Drupal CMS no longer grants dashboard access to regular authenticated users by default. Previously, the admin UI recipe gave all authenticated users permission to view the dashboard, even though they had no administrative tasks to perform there. This created a confusing experience where users were redirected to an empty dashboard. The dashboard permission is now granted only to content editors, who actually have work to perform there. Regular authenticated users will no longer see or be redirected to the dashboard unless a site explicitly grants them that permission.

Impact

No upgrade or configuration changes required.

Technical details

The drupal_cms_admin_ui recipe previously granted six permissions to the authenticated user role, including view welcome dashboard. This caused authenticated users to be redirected to a dashboard they couldn't use.

The fix removes view welcome dashboard from the authenticated role and instead grants it to the content_editor role. However, the two recipes that need to coordinate (drupal_cms_admin_ui and drupal_cms_content_type_base) cannot depend on each other without creating undesirable coupling between foundational recipes.

The solution introduces a new grantPermissionsIfExist config action plugin. This action works like the core grantPermissions action but silently ignores permissions that don't exist. The drupal_cms_content_type_base recipe uses this action to grant dashboard permissions to content editors only if those permissions are available (meaning the dashboard recipe has been applied). The recipe YAML uses the ? prefix for optional config targeting.

A core issue #3577548 was opened to potentially add this action to core. The current implementation is marked internal and acts as a polyfill.

Contribution

Timeline

Opened: March 2, 2026
Committed: March 6, 2026 (4 days and 2 commits later)

Key contributors

rajab natshah (Vardot)
phenaproxima (Acquia)
penyaskito (Acquia)
pameeela (Technocrat)

Collaboration

The issue evolved from a simple permission removal request into a more nuanced solution that preserves recipe independence. Initial discussion focused on whether to remove all the authenticated user permissions or just redirect behavior. The product owner confirmed that regular authenticated users don't need dashboard access by default and questioned why these permissions existed at all.

The key insight came when the architecture lead explained that granting permissions to authenticated users was an "end-run" around making drupal_cms_content_type_base depend on drupal_cms_admin_ui. This allowed the content editor role (which inherits from authenticated) to get foundational permissions without explicit dependencies. The solution needed to remove the confusing dashboard permission while preserving this dependency isolation pattern.

The final approach introduced the grantPermissionsIfExist action, allowing lightweight optional integration between recipes. This maintained architectural separation while solving the user experience problem. The issue was resolved within four days from opening to commit.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3577313: The installer should allow site templates to scaffold files

Thu, 05 Mar 2026 16:28:03 +0000

Project: Drupal CMS
Type: Normal feature request
Status: Fixed
Diff: 4b00c23
Discussion: #3577313 · 1 contributor · 5 comments
Followers: 1

Summary

The Drupal CMS installer now allows site templates to provide additional files in the project root directory. Site templates can scaffold files like AGENTS.md to give AI assistants instructions for working with a specific site template. This happens automatically when a site template is applied during installation. The installer adds the template package to Composer's scaffold allow-list so these files can be placed where they need to go.

Impact

No upgrade or configuration changes required.

Technical details

The installer now executes two Composer commands when requiring a recipe package. First, it adds the package name to the extra.drupal-scaffold.allowed-packages configuration using composer config with the --merge and --json flags. This allows the package to provide scaffold files. Second, it requires the package as before.

A new ComposerExecutor class was extracted to centralize Composer command execution. It handles finding the PHP executable, locating the Composer binary, setting the project root as the working directory, and automatically adding the --no-interaction flag. The original inline Process execution was refactored to use this helper.

The _drupal_cms_installer_require_recipe() function now makes two separate calls to ComposerExecutor::execute(). The scaffold configuration is updated before requiring the package, ensuring any scaffold operations defined in the recipe's composer.json run during the requirement step.

This change is specific to the Drupal CMS installer profile and does not affect standard Drupal core installation or general recipe application outside this context.

Contribution

Timeline

Opened: March 5, 2026
Committed: March 5, 2026

Key contributors

phenaproxima (Acquia)

Collaboration

This feature was implemented in a single day by phenaproxima. The issue was opened and committed on March 5, 2026. The implementation was straightforward with minimal discussion required, reflecting clear requirements and a well-understood solution path.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3576882: Use focal point widget on image and SVG forms

Thu, 05 Mar 2026 04:58:54 +0000

Project: Drupal CMS
Type: Normal bug report
Status: Fixed
Diff: 8eaabed
Discussion: #3576882 · 2 contributors · 15 comments
Followers: 4

Summary

Drupal CMS Media forms now consistently display the name field and hide the path field across all media types and form modes. Image media types now use the Focal Point widget on all forms, not just the default form. The source field (like the image upload field) appears on default forms for all media types and on media library forms only for image-based media. This standardizes the editing experience and ensures focal point selection works properly when adding or editing images.

Impact

No upgrade or configuration changes required.

Technical details

The drupal_cms_media recipe was not properly configuring form displays for media types. Static configuration files existed for media library form modes but were incomplete and inconsistent. The fix removes the static configuration files and instead uses recipe config actions to programmatically configure all media form displays.

The recipe now uses wildcard patterns (core.entity_form_display.media.*.*) to ensure the name field is always visible and the path field is always hidden on all media forms. A second action targets image media forms specifically (core.entity_form_display.media.image.*) to configure the field_media_image field to use the image_focal_point widget type.

The test coverage was expanded to verify that every media form display follows these rules: name field visible, path field hidden, source field visible based on media type and form mode, and focal point widget used for image media. The test iterates through all form displays and validates each configuration programmatically rather than relying on static snapshots.

Contribution

Timeline

Opened: March 4, 2026
Committed: March 5, 2026 (1 day and 2 commits later)

Key contributors

pameeela (Technocrat)
phenaproxima (Acquia)
mortona2k

Collaboration

This issue was resolved quickly, within one day from report to commit. The reporter identified that the media forms were not using focal point and that the configuration was not persisting, suspecting interference from the core image recipe. The assignee discovered the media configuration was a "mess" and worked with the reporter to establish clear rules for normalizing all media form displays. After initial implementation, the reporter tested and found the media library forms were not being configured. The final solution replaced static config files with programmatic recipe actions and added comprehensive test coverage to prevent regressions.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3577153: SiteExporter repeats indexed arrays, potentially bloating recipe.yml to tens of thousands of lines

Thu, 05 Mar 2026 03:36:45 +0000

Project: Drupal CMS
Type: Major bug report
Status: Fixed
Diff: 7edee58
Discussion: #3577153 · 1 contributor · 6 comments
Followers: 1

Summary

The Site Exporter in Drupal CMS Helper had a bug that caused recipe files to grow exponentially when exported multiple times. Each time a recipe was exported, user permissions and other indexed array values were duplicated instead of being replaced. This could cause recipe.yml files to balloon to tens of thousands of lines, making them unmanageable and potentially causing performance issues. The fix ensures that config actions are completely replaced on each export rather than merged, preventing this duplication.

Impact

No upgrade or configuration changes required.

Technical details

The SiteExporter class was using NestedArray::mergeDeep() to combine new config actions with existing ones in the recipe file. This method preserves integer keys, which is problematic for indexed arrays like user permissions. When merging ['permission_a'] with ['permission_b'], the result was ['permission_a', 'permission_b'] instead of just ['permission_b']. Each subsequent export would add another copy of all permissions, causing exponential growth.

The fix replaces the deep merge with a simple array union operator: $actions + ($recipe['config']['actions'] ?? []). This ensures that new config actions completely overwrite existing ones for the same config object or entity, while preserving any config actions that aren't being updated. The test verifies that when a recipe contains one permission and the site has a different permission, the export replaces rather than merges the permissions list.

Contribution

Timeline

Opened: March 5, 2026
Committed: March 5, 2026

Key contributors

phenaproxima (Acquia)

Collaboration

This issue was opened and fixed by phenaproxima on the same day, March 5, 2026. The fix went through two commits, both on the same day. The rapid turnaround suggests this was discovered during active development or testing of the Drupal CMS Helper module, likely while working with recipe exports. The straightforward nature of the fix and the clean test coverage indicate the root cause was quickly identified and addressed.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3574824: When doing internal development, add cweagans/composer-patches to Package Manager's list of trusted plugins

Sun, 01 Mar 2026 15:22:14 +0000

Project: Drupal CMS
Type: Normal bug report
Status: Fixed
Diff: ffdc9a3
Discussion: #3574824 · 2 contributors · 16 comments
Followers: 3

Summary

Drupal CMS developers encountered an error when applying recipes through the Project Browser UI. The system blocked operations because cweagans/composer-patches was not recognized as a trusted Composer plugin. This only affected developers working on Drupal CMS itself, not production sites. The fix adds internal development configuration that automatically trusts the patches plugin and enables direct-write mode for Package Manager when working in the Drupal CMS development environment.

Impact

No upgrade or configuration changes required.

Technical details

The Drupal CMS project uses cweagans/composer-patches as a development dependency. When developers tried to apply recipes through Project Browser, Package Manager rejected the operation because this plugin was not in the trusted list. The initial approach used environment variables and a config override service in the drupal_cms_helper module to detect DDEV projects by name. The final solution moved this logic to a standalone service class (PackageManagerSettings) registered through a custom services.yml file in sites/default. The Composer scaffold configuration copies this file from scripts/services.yml during installation. The service implements both ConfigFactoryOverrideInterface to add the patcher to package_manager.settings trusted plugins list and EventSubscriberInterface to enable package_manager_allow_direct_write on kernel request. This approach isolates development tooling from the shipped module code and only affects the internal development environment.

Contribution

Timeline

Opened: February 20, 2026
First commit: February 20, 2026
Last commit: March 1, 2026 (8 days and 6 commits later)

Key contributors

thejimbirch (Kanopi Studios)
phenaproxima (Acquia)

Collaboration

phenaproxima quickly diagnosed the issue and implemented multiple iterations to find the cleanest solution. They moved from an environment-variable-based approach to a scaffold-based service registration pattern that keeps development infrastructure separate from production code. thejimbirch reported the bug with clear reproduction steps and confirmed the fix worked.

This content is AI-generated and may contain errors. See Drupal Digests for more.

#3574664: The `site:export` command should be able to export on top of another recipe

Fri, 27 Feb 2026 19:33:22 +0000

Project: Drupal CMS
Type: Normal feature request
Status: Fixed
Diff: 8670479
Discussion: #3574664 · 1 contributor · 12 comments
Followers: 1

Summary

The site export command in Drupal CMS now allows you to build on top of an existing recipe template, preserving important scaffolding like CI configuration, license files, and documentation. This makes it easier to share custom site configurations while keeping best practices intact. The command also fixes several export bugs that affected menu hierarchies and front page paths, ensuring exported recipes work correctly when shared with others.

Impact

No upgrade or configuration changes required.

Technical details

The drush site:export command gains a --base option that accepts a path to an existing recipe. When specified, the command uses Symfony Filesystem to mirror the base recipe's files (excluding version control and content) into the destination, then exports the current site configuration on top. Files with a .example suffix are automatically renamed to their active form.

Three export bugs are also fixed with temporary shims pending core releases. First, system.site config now exports front page paths as aliases rather than system paths by using AliasManagerInterface during the transform. Second, DefaultContentSubscriber ensures menu link content entities export their parent dependencies by loading parent menu links by UUID and adding them to export metadata. Third, the command prevents overwriting existing destinations by checking for directory existence upfront.

The GenericConfigurationListener class changes from readonly to mutable to support the conditional front page transformation. Test coverage validates base recipe copying, file renaming, content exclusion, and the menu link dependency fix.

Contribution

Timeline

Opened: February 19, 2026
First commit: February 19, 2026
Last commit: February 27, 2026 (7 days and 4 commits later)

Key contributors

phenaproxima (Acquia)
andyg5000 (Dripyard)
vishalkhode (Acquia)

Collaboration

phenaproxima authored, reviewed, and committed this feature independently over nine days across four commits. The issue originated from feedback by Andy from Dripyard, who reported the export bugs affecting site template creators. phenaproxima acknowledged the urgency of unblocking site template development and merged the changes with confidence after adding comprehensive test coverage.

This content is AI-generated and may contain errors. See Drupal Digests for more.