A modern way to build and develop Drupal 8 sites, using Composer

The Drupal community has been on an interesting journey since the launch of Drupal 8 in 2015. In the past three years, as the community has started to get its sea legs 'off the island' (using tools, libraries, and techniques used widely in the general PHP community), there have been growing pains.

One area where the pains have been (and sometimes still are) highly visible is in how Drupal and Composer work together. I've written posts like Composer and Drupal are still strange bedfellows in the past, and while in some ways that's still the case, we as a community are getting closer and closer to a nirvana with modern Drupal site building and project management.

For example, in preparing a hands-on portion of my and Matthew Grasmick's upcoming DrupalCon Nashville lab session on Composer and Drupal, I found that we're already to the point where you can go from literally zero to a fully functional and complete Drupal site codebase—along with a functional local development environment—in about 10 or 15 minutes:

  1. Make sure you have PHP, Composer, and Docker CE installed (Windows users, look here).
  2. Create a Drupal codebase using the Drupal Composer Project: composer create-project drupal-composer/drupal-project:8.x-dev drupal8 --stability dev --no-interaction
  3. Open the project directory: cd drupal8
  4. Add a plugin to build a quick and simple local dev environment using Drupal VM Docker Composer Plugin: composer require --dev geerlingguy/drupal-vm-docker
  5. Start the local dev environment: docker-compose up -d
  6. Open a browser and visit http://localhost/

I'm not arguing that Drupal VM for Docker is the ideal local development environment—but accounting for about one hour's work last night, I think this shows the direction our community can start moving once we iron out a few more bumps in our Composer-y/Drupal-y road. Local development environments as Composer plugins. Development tools that automatically configure themselves. Cloud deployments to any hosting provider made easy.

Right now a few of these things are possible. And a few are kind of pipe dreams of mine. But I think this year's DrupalCon (and the follow-up discussions and issues that will result) will be a catalyst for making Drupal and Composer start to go from being often-frustrating to being extremely slick!

If you want to follow along at home, follow this core proposal: Proposal: Composer Support in Core initiative. Basically, we might be able to make it so Drupal core's own Composer usage is good enough to not need a shim like drupal-composer/drupal-project, or a bunch of custom tweaks to a core Composer configuration to build new Drupal projects!

Also, I will be working this DrupalCon to help figure out new and easier ways to make local development easier and faster, across Mac, Linux and Windows (I even brought my clunky old Windows 10/Fedora 26 laptop with me!). There are a number of related BoFs and sessions if you're here (or to watch post-conference), for example:

Further reading

drupal
drupal planet
composer
drupal vm
docker
local development

Comments

Hi --

Can you get any useful ideas or inspiration from this old thread I found in the BLT issues ... https://github.com/acquia/blt/issues/1216#issue-215449615

I like BLT but not some of it's opinionated configuration defaults, like the nested composer files requiring Lightning distro -- but would like to use the BLT she'll/tooling for projects.

The above project looks the a very generalized, yet flexible, docker usage for Drupal + composer -- which BLT is also using and uses similar patterns in how it uses composer to compose the project pieces from core and contrib.

Thanks for DrupalVM and all your efforts.

Great stuff, and I could not agree more.

Upfront warning: Shameless plug!

Another great benefit from managing your dependencies with composer is that you can use a tool to automate the monitoring and executing the actual updates for you. I maintain such a tool called https://violinist.io

Shoot me a line if you want a free premium account. I am sure you could find it useful :)

Thanks again. I will be sure to watch the recordings when they are available.

Anyone else getting this error? I just installed latest stable docker on my mac - Version 18.03.0-ce-mac60 (23751)

ERROR: for drupal_vm_docker Cannot start service drupalvm: driver failed programming external connectivity on endpoint drupal_vm_docker

Docker + Composer + Drupal + Git works like a dream for local development since Docker and Git are both running as my local user account. But updating shared staging and production environments is a nightmare for file ownerships and permissions. The user account and Git account are usually the same, but we have a separate user for Docker and the Apache is serving the site as the www-data user.

In the old non-composer non-docker workflow we could just pull changes from git and use drush to apply any database updates and clear the caches and we'd generally be good to go. Now we have to change ownerships and permissions to the current user before we can even pull changes from git, then change them back again before running composer install to finish updating. Ownerships and permissions combinations are different for the composer, config and web subfolders which makes things difficult, due to the web server, docker and developer all being separate user accounts.

We are fairly new to this process, but it is painful, time consuming and prone to human error. Fortunately we only have one site using this method in production so far, and that site is in development, so the long update process is not affecting users of the site yet. But we would like to move all future development to using this method if we can sort out these issues with file ownerships and permissions.

Is there some generally accepted method for using Drupal/Composer/Docker/Git in production that gets around these issues? I could probably do it by making shell scripts to change the permissions pre- and post-update, but just wondering if there is a better way?

Hi Scott, I've also build a docker'd version of my D8 installations (here https://hub.docker.com/r/feikede/drupal8-docker/). The idea is, to have the like "moving data" (ie /sites/default/files) on a mounted volume and the contributed modules/themes inside the container. The hope is, that it will be enough to pull a new version of the image for updates. Stop the container, remove the container, pull the new version, start the container, run update.php - pray.
It worked for me yesterday for the 8.5 to 8.6 upgrade.