This is a SiteFarm Composer-based Drupal distribution template.
You will need the following installed:
- Composer, obviously
When you have that, run this command:
$ composer install
Composer will download and install the SiteFarm install profile. You can then install it like you would any other Drupal site.
This project will attempt to keep all of your Drupal Core files up-to-date; the project drupal-composer/drupal-scaffold is used to ensure that your scaffold files are updated every time drupal/core is updated. If you customize any of the "scaffolding" files (commonly .htaccess), you may need to merge conflicts if any of your modfied files are updated in a new release of Drupal core.
Follow the steps below to update your core files.
- Run
composer update drupal/core --with-dependencies
to update Drupal Core and its dependencies. - Run
git diff
to determine if any of the scaffolding files have changed. Review the files for any changes and restore any customizations to.htaccess
orrobots.txt
. - Commit everything all together in a single commit, so
docroot
will remain in sync with thecore
when checking out branches or runninggit bisect
. - In the event that there are non-trivial conflicts in step 2, you may wish
to perform these steps on a branch, and use
git merge
to combine the updated core files with your customized files. This facilitates the use of a three-way merge tool such as kdiff3. This setup is not necessary if your changes are simple; keeping all of your modifications at the beginning or end of the file is a good strategy to keep merges easy.
Let this handy table be your guide to updating with Compser:
Task | Composer |
---|---|
Installing a contrib project (latest version) | composer require drupal/PROJECT:8.* |
Installing a contrib project (specific version) | composer require drupal/PROJECT:8.1.0-beta3 |
Updating all contrib projects and Drupal core | composer update |
Updating a single contrib project | composer update drupal/PROJECT |
Updating Drupal core | composer update drupal/core |
The magic is that Composer, unlike Drush, is a dependency manager. If module foo-8.x-1.0
depends on baz-8.x-3.2
, Composer will not let you update baz to 8.x-3.3
(or downgrade it to 8.x-3.1
, for that matter). Drush has no concept of dependency management. If you've ever accidentally hosed a site because of dependency issues like this, you've probably already realized how valuable Composer can be.
you still need Drush or Drupal Console. Tasks such as database updates (drush updatedb
) are still firmly in Drush's province.
Composer is only responsible for maintaining the code base.
If you peek at the .gitignore
we provide, you'll see that certain directories, including all directories containing contributed projects, are excluded from source control. This might be a bit disconcerting if you're newly arrived from Planet Drush, but in a Composer-based project like this one, you SHOULD NOT commit your installed dependencies to source control.
Composer creates a file called composer.lock
, which is a list of which dependencies were installed, and in which versions. Commit composer.lock
to source control! Then, when your colleagues want to spin up their own copies of the project, all they'll have to do is run composer install
, which will install the correct versions of everything in composer.lock
.