Skip to content

What is a Composer project template?

Adds new abilities to composer create-project for Drupal distributions to leverage in order to replace parts of the install profile functionality. Composer project templates are envisaged to be used by:

  • Drupal agencies to maintain to a common starting point for their builds
  • Distributions to provide the same functionality they can now with install profiles

What can a composer project template do

  • Provide a composer.json that list projects for composer install (Existing composer functionality)
  • Can provide a composer.lock file to ensure that a version gets exactly the right dependencies and is not open-ended. (Existing composer functionality)
  • Provide a list of Drupal recipes to download and apply during a Drupal installation
  • Provide a list of Drupal extensions to install during a Drupal installation.
    • Provide lists of modules and theme.
    • This functionality crosses-over with Drupal recipes so, potentially, if we don't build this then we'll get more Drupal recipes.
  • Determine which theme is used during the installer
  • Determine whether the english language is to be kept after a multilingual install
  • Provide a finish URL

Things to discuss

  • What to do about hook_install_tasks() and hook_install_tasks_alter(). These have been used to add additional forms to the installer to collect information from the user or to select optional functionality. These are special hooks that can only be invoked for an install profile - if there is no install profile then we don;t have a place for this logic. Potential solutions include:
    • replacing the select optional functionality with Drupal recipe suggestions.
    • Having some sort of sort for forms described in YAML or something like that (very long term goal)
    • Allowing the composer project template to continue to load a .profile file somehow.

Updates

If the provider of the project template wants to provide updates then they need to require a module to take care of the updates. This is the same as Drupal recipes. For example, for Thunder the module would depend on the Update Helper module and provide the updates currently provided by the distribution in its config/update directory and the thunder.install file.

Configuration overrides

Install profiles are able to override existing configuration during an installation. It is proposed that this functionality is deprecated in favour of Drupal recipes and their ability to modify existing configuration on application.

Optional modules

Install profiles use hook_install_tasks() to add a form to allow users to select additional modules. This should be deprecated and instead this should leverage the ability of Drupal recipes to suggest further Drupal recipes.

Profile modules

Install profiles can provide modules. For example, Thunder has a modules directory that provides modules like thunder_article and thunder_demo. Composer templates can not do this and this functionality should be deprecated.

What happens to install profiles/distributions/starter kits?

Once we have Drupal recipes and install profiles can use the root composer.json to access the same functionality as they can in their info.yml file we should be able to deprecate install profiles.

If an install profile wants to provide an upgrade path they will need to create a module to provide the updates. A separate part of this initiative hopes to add Update Helper functionality to core to make these updates easier to maintain.

Implementation tasks & roadmap

  • #1170362 Provide a way to uninstall an install profile
  • #3264926 Move functionality from install profile to composer template
  • #1497268 Add config revert functionality to core
  • #3278976 Remove unnecessary use of config reverter class from update_helper
  • #3278978 Add update_helper module to core
  • Provide documentation how to convert a distribution to a composer project template and Drupal recipe(s)
  • Deprecate install profiles. They can be removed in the next major version of Drupal core