Skip to content Contact us

Contact form

Drupal, Exove, Technology by Perttu Ehn,

Security in Code Deployment – part 5: Patch with Composer and Deploy

Code examples for this article: https://github.com/rpsu/dwd-security-in-code-deployment

This is part of “Security in Code Deployment” -series. 

Composer is able to apply patches if you are using drupal-composer/drupal-project or some other patching plugin for Composer (Listing 14).

LISTING 14: Composer Patching
"extra": {
"patches": {
"drupal/field_group": {
"A patch with URL": "https://www.drupal.org/files/issues/ field_group-empty_group_nonnumeric_index-2761159-2-D8.patch",
"A local patch file, path relative to the composer.json file": "patches/field_group-fix_it.patch"
}
}
}

After you have added the patch files to the composer. json file, apply the changes and update the composer.lock file:
$ composer install
$ composer update --lock

Currently with Drupal 8, all contrib modules and other resources must be added manually one by one. If you are creating a composer.json file from a Drupal 7 site, you might benefit by using the Composer Generate module.

If you are interested in building your Drupal 8 projects with Composer, two good resources are Wolfgang Ziegler’s presentation from Drupal Iron Camp 2016 and the Composer documentation at Drupal.org.

Deployment

For codebase deployment, it is best to rely on a builder tool. Ideally, you commit only your custom code (e.g., modules and themes and a Drush make file or the composer.json and composer.lock files) to the project repository, with specific versions and, optionally, patching information. With proper versioning (think Git tags), you can test your next release’s code in development and staging environments and reduce the probability of reintroducing old or introducing new issues.

Web server configuration is very much related to deployment security, too. However, because it is too broad a topic to be covered here, just remember to make sure your server does not allow end users access to any files other than those they absolutely need. Patch files, Drupal core, and a module’s text files – especially CHANGELOG.txt and build time PATCHES.txt – are good examples of files that have no business being visible to the world. Even when most of the attacks against websites are automated, there is no reason to leave information about website internals in the open.

Special thanks to Rami Järvinen for contributions to this blog post and to Anastasios Daskalopoulos and James Narraway for their help correcting my words to grammatically much better English.

See all posts

Read next

See all posts in this series

More in this series

See all posts

More from the blog

See all careers

Related open positions

Current selection of careers

Our offices

Contacts

  • Perttu Ehn

    Competence Manager, Developer

    • perttu.ehn@exove.com