Drupal CMS

#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
Changes: 4 files, +21/−5 · txt +10 · php +8/−5 · json +3
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.

#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
Changes: 1 file, +2/−2 · css +2/−2
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
Changes: 3 files, +45/−10 · php +45/−10
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
Changes: 9 files, +161/−203 · php +161/−203
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.

#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
Changes: 6 files, +176/−36 · php +167/−36 · yml +9
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 8, 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.

#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
Changes: 2 files, +31/−1 · php +31/−1
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.

#3575789: If there's only one site template in the code base, choose it automatically

Thu, 26 Feb 2026 19:27:11 +0000

Project: Drupal CMS
Type: Normal feature request
Status: Fixed
Changes: 5 files, +82/−83 · php +82/−83
Diff: 8f0de40
Discussion: #3575789 · 1 contributor · 6 comments
Followers: 2

Summary

The Drupal CMS installer now automatically selects a site template if only one is available in the codebase. Previously, the installer always displayed a selection form even when only a single template was present. This streamlines the installation process by skipping the unnecessary selection step. This change prepares for a marketplace workflow where users could download a pre-configured project with a single site template already chosen, then proceed directly through installation without redundant selection prompts.

Impact

No upgrade or configuration changes required.

Technical details

The drupal_cms_installer_choose_template() task was converted from a simple form task to a custom function. This function scans for site templates using RecipeHandler::scan('Site') and stores them in install state. If exactly one recipe is found, it temporarily sets $install_state['interactive'] to FALSE before calling install_get_form(), which causes the form to submit programmatically without user interaction.

The RecipeHandler::scan() method was refactored from returning a raw Finder object to yielding Recipe objects directly, with optional filtering by recipe type. This moves error handling and recipe validation into the service layer. The method now catches RecipeFileException and displays errors, simplifying callers.

The SiteTemplateForm receives pre-scanned recipes from install state rather than scanning itself. The administrator role recipe is now enqueued earlier in the task function rather than on form submit. The default selection is set to the first recipe in the array, which is always drupal_cms_starter due to custom sorting logic.

Contribution

Timeline

Opened: February 25, 2026
Committed: February 26, 2026 (1 day later)

Key contributors

phenaproxima (Acquia)

Collaboration

phenaproxima identified the need to support a streamlined marketplace download workflow and implemented the automatic selection behavior within a single day. The change maintains backward compatibility with Drupal CMS's default multi-template setup while enabling future single-template distributions.

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

#3573304: Create a 'Blank' template option for users who want to start from scratch

Wed, 18 Feb 2026 15:53:41 +0000

Project: Drupal CMS
Type: Normal feature request
Status: Fixed
Changes: 2 files, +8/−6 · php +5/−5 · yml +3/−1
Diff: 85790f5
Discussion: #3573304 · 4 contributors · 24 comments
Followers: 4

Summary

Drupal CMS now offers a "Blank" template option during installation for users who want to start with a minimal foundation. This template provides Drupal CMS's baseline functionality without the Mercury design system or component library, giving developers complete freedom to build their own design approach. The blank template includes an automatically generated minimal theme with just header, content, and footer regions, plus a single blank Canvas page as the home page.

Impact

No upgrade or configuration changes required.

Technical details

The blank template is implemented by making drupal_cms_site_template_base visible and usable during installation. Previously, this site template was hidden from the installer UI and only available to developers via command line.

The implementation leverages the site_template_helper Composer plugin to dynamically generate a minimal theme called "blank" when the template is installed. This theme is based on core's starterkit_theme but includes only three regions: header, content, and footer. The theme generation happens automatically at composer require time through plugin configuration in the site template's composer.json.

The drupal_cms_installer_install_tasks_alter() function was simplified by removing the SiteTemplateFormAlter class that previously hid drupal_cms_site_template_base from the installer. The template now appears alongside other options like Starter and the various prebuilt templates.

The installer UI received CSS improvements to accommodate the additional template option, switching from a fixed three-column grid to a responsive grid that adapts from two to four columns based on viewport width. The SiteExporter service was updated to remove development-only dependencies like site_template_helper when exporting site configurations.

The blank template includes a single empty Canvas page set as the front page to avoid a 404 on first visit. It also includes the utility page content type through drupal_cms_content_type_base, which provides the Canvas page functionality.

Contribution

Timeline

Opened: February 13, 2026
First commit: February 16, 2026 (3 days later)
Last commit: February 18, 2026 (2 days and 4 commits later)

Key contributors

pameeela (Technocrat)
lauriii (Acquia)
phenaproxima (Acquia)

Collaboration

phenaproxima implemented the technical approach after pameeela identified the need and lauriii provided requirements feedback. phenaproxima resurrected and integrated the site_template_helper plugin to enable dynamic theme generation, solving the challenge of scaffolding a minimal theme without maintaining another static theme in the codebase.

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

#3574009: Add a hidden Drush command to export all content

Tue, 17 Feb 2026 15:16:32 +0000

Project: Drupal CMS
Type: Normal feature request
Status: Fixed
Changes: 6 files, +138/−35 · php +138/−35
Diff: 8a6b09b
Discussion: #3574009 · 1 contributor · 6 comments
Followers: 2

Summary

Drupal CMS now includes a hidden Drush command that makes it easy for developers to export all content from a site to a directory. This is useful for creating development snapshots, migrating content between environments, or backing up site content in a portable format. The command is hidden because it's intended for developer use rather than routine site administration. The change also extracts the content loading logic into a reusable component that both the site export and content export commands can use.

Impact

No upgrade or configuration changes required.

Technical details

This change adds a new content:export:all Drush command in the drupal_cms_helper module. The command is marked as hidden (not shown in normal help listings) and exports all content entities to a specified directory using Drupal's default content export system.

The implementation extracts the content loading logic from SiteExporter::loadAllContent() into a new ContentLoader class that implements IteratorAggregate. The ContentLoader iterates through all entity types, filters out internal entities and path aliases, and yields all content entities. It excludes users 0 and 1 since those always exist with the same IDs.

The new ExportAllContentCommand class uses the Exporter service to export each entity with its dependencies to the target directory. The command accepts a single required argument for the destination directory path.

Both ContentLoader and ExportAllContentCommand are marked as @internal, but the command itself is marked as @api to signal that developers can rely on it. The change also adds @api annotations to existing commands (content:import, site:export) to clarify their stability guarantees within Drupal CMS.

Contribution

Timeline

Opened: February 17, 2026
Committed: February 17, 2026

Key contributors

phenaproxima (Acquia)

Collaboration

phenaproxima identified the use case and implemented the feature in a single day, including extracting the shared content loading logic into a reusable component and updating the existing site export functionality to use it.

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

#3569529: Add an AGENTS.md file

Wed, 04 Feb 2026 17:24:31 +0000

Project: Drupal CMS
Type: Normal feature request
Status: Fixed
Changes: 5 files, +134/−0 · md +134
Diff: aecaffb
Discussion: #3569529 · 4 contributors · 12 comments
Followers: 13

Summary

Drupal CMS now includes an AGENTS.md file to help AI coding assistants work more effectively with the codebase. This file provides structured guidance on the project's technology stack, coding standards, development commands, and prohibited actions. The documentation helps AI tools avoid common mistakes and follow project conventions when assisting developers with Drupal CMS contributions.

Impact

No upgrade or configuration changes required.

Technical details

The new AGENTS.md file documents Drupal CMS-specific conventions for AI coding assistants. It covers the monorepo structure with recipes in the recipes directory, the drupal_cms_helper module, and the project_template directory used for end-user installations.

The file provides command references for common development tasks using DDEV and Drush, including recipe application, PHPUnit testing, site installation, and content export with drush content:export. It specifies coding standards like using strict typing, the ?type nullable syntax, #[\Override] attributes, and marking new classes as final with private members.

Several README files in protected directories (cpanel_template, patches, scripts, splitter) now explicitly warn agents not to modify those areas. The prohibited actions section lists destructive operations like running ddev tag or composer update outside the project root, and prevents agents from adding patches or pinning dependencies in Composer files.

The documentation emphasizes defensive programming in drupal_cms_helper, requiring checks like \Drupal::moduleHandler()->moduleExists() before using optional module functionality. It also instructs agents to mark new non-test classes as internal with specific warning text.

Contribution

Timeline

Opened: January 25, 2026
Committed: February 4, 2026 (9 days and 2 commits later)

Key contributors

phenaproxima (Acquia)
nod_ (Très Bien Tech)
marcus_johansson (FreelyGive)
thejimbirch (Kanopi Studios)
rajab natshah (Vardot)

Collaboration

This issue demonstrates the Drupal CMS team's pragmatic approach to AI tooling. The issue author acknowledged ambivalence about AI while recognizing its practical utility and the need to accommodate developers using these tools. Multiple contributors provided feedback to improve structure and readability, with discussion about whether to manage the file through a separate package like the scaffold system. The team decided keeping AGENTS.md in the repository made more sense for documenting internal workings.

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

#3557383: Ship local video media type with Drupal CMS for better compatibility with Canvas

Wed, 19 Nov 2025 07:46:39 +0000

Project: Drupal CMS
Type: Normal task
Status: Fixed
Discussion: #3557383 · 3 contributors · 15 comments
Followers: 5

Summary

The drupal_cms_remote_video recipe now also ships the local video media type, so Canvas components that reference a video schema can use the media library picker instead of falling back to a less reliable file picker. The recipe description has been updated to reflect that it now covers both locally and remotely hosted video. Additionally, whitespace-to-underscore filename sanitization is enabled for uploaded files, and the built-in files view is disabled to avoid confusing site editors who may not understand the difference between "Files" and "Media".

Impact

No upgrade or configuration changes required.

Technical details

The root problem was that Canvas resolves a video field (via json-schema-definitions://canvas.module/video) through the local video media type. When that media type was absent, Canvas degraded to a generic file picker that was unreliable. The fix adds core/recipes/local_video_media_type to the recipes list in drupal_cms_remote_video/recipe.yml, alongside the existing core/recipes/remote_video_media_type. The recipe also installs the file and views modules explicitly. A new core.entity_form_display.media.video.* config action mirrors the existing remote video form display: it hides uid, langcode, path, and created, and enables the name field. file.settings is updated via simpleConfigUpdate to set filename_sanitization.replace_whitespace: true in both drupal_cms_remote_video and drupal_cms_media (the latter backported to the 1.2.x branch of drupal_cms_image as a bug fix). views.view.files is disabled, and authenticated users receive the delete own files permission. The composer.json description was updated from "Configures display options for remote video" to "Configures display options for locally and remotely hosted video." A follow-up is planned to explore a Composer package alias so the recipe can also be referenced as drupal/drupal_cms_local_video, since the current package name (drupal_cms_remote_video) no longer reflects its full scope.

Contribution

Timeline

Opened: November 12, 2025
Committed: November 19, 2025 (6 days and 3 commits later)

Collaboration

pameeela noted early in the thread that adding the local video media type had always been planned as optional support, but she saw no major reason to keep it optional and suggested simply depending on the core recipe. phenaproxima agreed, opened MR !685, and then flagged the awkward naming of drupal_cms_remote_video after the fact. pameeela acknowledged the naming issue but approved the change rather than holding it up, reasoning it was not worth blocking the fix.

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