Information for: DEVELOPERS   PARTNERS   SUPPORT

Looking for something?

Using Composer with Drupal sites

Composer is a tool for managing PHP dependencies for your website or application. Composer gives you the flexibility to declare the libraries your project depends on, and it will install and update them for you.

For full instructions about downloading and installing Composer for your operating system, see the Composer’s Getting Started guide.

Using Composer with Cloud Platform

Due to Composer not being installed on Cloud Platform, Acquia recommends you install Composer locally and use it with your local copy to perform updates and manage dependencies. You can then deploy your build artifact to your Cloud Platform environments using Pipelines.

To follow best practices with Composer, you must maintain a source code (source) repository for your project separate from your Cloud Platform (build) repository. Your source repository must contain the least amount of code required to build your project, such as a composer.json file, composer.lock file, and any custom modules or settings. The source repository must not contain copies of your Composer dependencies. Your build repository (hosted on Cloud Platform) must contain static snapshots, called build artifacts, of your entire codebase (including Composer dependencies) ready for deployment to Cloud Platform.

To move code between your source and build repositories, you can use one of the following methods:

  • Copy the necessary files locally
  • Use a continuous integration service, such as the Pipelines
  • Use a tool automating the process, such as BLT

You can use a Composer-based workflow with a single repository (not recommended). Using a single repository creates a brittle development workflow, which can make it difficult to maintain code consistency. For example, with a single repository, you must keep the versions of dependencies in composer.json and the versions of dependencies you commit to the repository in sync, which introduces a high risk of human error.

If you cannot use Pipelines, you can use Composer based on the following methods:

  • Using BLT deploy commands, as described in the BLT Deployment workflow.
  • Installing Composer through Live Development (not recommended)
    You can install Composer in Cloud Platform by enabling Live Development and following the normal Git workflow for checking out code (including adding changed flags, committing changes, and pushing to origin). After you install Composer, you must enable Live Development mode to begin using Composer on Cloud Platform. By default the .gitignore file ignores the Vendor directory, which makes sense if you use Composer on Cloud Platform directly.

Encrypting Composer variables

To encrypt Composer variables in Cloud Platform Pipelines, see Encrypting keys and variables.

When encrypting the COMPOSER_AUTH variable using the Encrypt Credentials field in the Cloud Platform interface, ensure you use single quotes at the beginning and end of the json, and use double quotes inside the curly brackets, as in the following example:

'{"http-basic": {"mysite.com": {"username": "myuser", "password": "mypassword"}}}'

Failing to follow the preceding code format can generate the following UnexpectedValueException error:

COMPOSER_AUTH environment variable is malformed, should be a valid JSON object

Using Composer with Drupal

Drupal core uses Composer to manage dependencies, which can include Drupal modules. For more information, see the following Drupal.org resources:

Migrating into a Composer-managed build

If you migrate an existing Drupal 8 website into a Composer-managed build, you must build a composer.json file including all the packages your existing website requires. For more information about the migration process, see the Composer: Migrate an existing D8 site into a Composer-managed build documentation page.

Patching with Composer

To enable patching through Composer:

  1. Install the composer-patches project with Composer:

    composer require cweagans/composer-patches

  2. Add the following to the extra section of the composer.json file located above the docroot directory:

    "enable-patching": true,
   "patches": {
      "drupal/[module_name]": {
        "Note regarding the nature of the patch being applied":
        "https://www.drupal.org/files/issues/[patch_name].patch"
      }
   }

  3. Update the [module_name] and [patch_name] according to your patch file from Drupal.org or add your patches in the patches directory above the docroot directory and record the full path in your patches.make file. However, Acquia recommends that you patch from remote, such as Drupal.org or Github. Local patches are difficult to maintain as the underlying dependencies require to be updated over time. Acquia recommends that you use patching to fix bugs or address outstanding issues in Drupal core and contrib modules and packages. Patches should not be used to develop or add functionality.

    Alternately, take out the patches from the root composer.json file and include in a separate file. This is a cleaner way of tracking them when you are dealing with various patches.

    The following code block would be added to your composer.json:

    {
    // [...]
    "extra": {
      // [...]
      "patches-file": "composer.patches.json"
    }
  }

    Patches are added to a composer.patches.json text file as follows:

    {
   "patches": {
     "vendor/project": {
       "Message describing the patch": "https://www.drupal.org/url/to/patch/file.patch"
     }
   }
 }

  4. To ensure that the updates take effect, run the following command:

    composer update patched/package --with-all-dependencies

53 State Street, 10th Floor
Boston, MA 02109
United States
Phone: 888-922-7842