If you have to go for a Drupal core update from a previous install based on composer_manager or drush (both deprecated), consider installing something robust, Composer friendly, that excludes vendor and core for a lightweight repository and enables CI and automation tools like Phing, Behat, PHPUnit, CodeSniffer, ...
If you don't have Drupal VM installed, head to the documentation.
This post will focus on the steps to move from one install type to another and will not cover Git, CI and production deployment.
Also, by using Drush for other purposes, it will still show the differences between Composer and Drush and why they can live together.
Let's consider that you have a standard scenario where your current environment is into production or staging and you want to perform the update on your local (dev) environment.
Well, this is probably not for the cool kids that have comfortable hosting platforms, but, if you are on a custom VPS instance, chances are that you could have some steps to follow.
Install pfrenssen Drupal Composer template
- Go to https://github.com/pfrenssen/drupal-project then download or fork it into a directory reachable by your Drupal VM (covered by vagrant_synced_folders).
- Rename it into the project name (myproject in the examples below), that will be defined in your shared vagrant_synced_folders
cd
into it.composer install
will create the "web" docroot + download the core and dependencies ;
vendor and config will be placed outside of the docroot for a safer setup. Composer can be executed on your guest or Drupal VM but for better performances, prefer the one that does not have XDebug installed (most probably the guest: Mac OSX, ...).- Create the entries in Drupal VM config.yml: vagrant_synced_folders, apache_vhost but not the db, that will be created by Phing later. If your db is already defined in the mysql_databases section, remove the db entry and drop the db on your Drupal VM. Note that your apache_vhost will use "web" instead of "public_html" or "docroot" or anything else. See this issue and below for examples.
- Go to your Drupal VM install directory (the one where you cloned the Drupal VM repo) then
vagrant provision
andvagrant reload
(if you have several sites to update, repeat what's above first, for all the sites). - Create the build.properties.local at the vhost root (myproject). See example below.
- Go to your Drupal VM vhost:
vagrant ssh
then in the VMcd
into your vhost root (not web, example: /var/www/myproject) - Install your project with Phing
./vendor/bin/phing install
Example values of vagrant_synced_folders and apache_vhosts
vagrant_synced_folders:
- local_path: ~/vagrant/myproject
destination: /var/www/myproject
type: nfs
apache_vhosts
- servername: "myproject.dev"
serveralias: "www.myproject.dev"
documentroot: "/var/www/myproject/web/"
extra_parameters: |
ProxyPassMatch ^/(.*\.php(/.*)?)$ "fcgi://127.0.0.1:9000{{ "/var/www/myproject/web" }}"
build.properties.local template
This file will override the values from build.properties.dist
The minimal config should be covered by the following values. Here, the db name will inherit the project.name (see the .dist file for more info).
# The project name, also used for dbname
project.name = myproject
# Database settings.
drupal.db.password = root
# The base URL. This is used for doing functional tests in Behat and PHPUnit.
drupal.base_url = http://myproject.dev
Replicate your previous environment
- From your production or staging environment, get a lightweight db backup, without the cache tables, by using drush (
cd
into sites/default/files thendrush sql-dump > dump.sql
) or faster with backup_migrate. Also, you could consider using drush alias for that. - Remove the sql dump after downloading it, if it was done with drush in the files directory.
- Replace your Phing created db by your db dump.
- Based on your production / staging environment or your git master, get a list of the contributed modules and themes that are installed. You can also use drush for that
drush pm-list --status=enabled --pipe --no-core
. The real benefit with drush is that you will only have a list of enabled modules, so it is the perfect moment for cleaning up.
Then go back to your local environment on your project root (so, on the parent of web) and install your contributed dependencies that will now live by default in modules/contrib and themes/contrib, based on the Composer template.
Remember to exclude composer_manager if you were using it.
Simply run for eachcomposer require drupal/[module_or_theme]
. Remember to use preferably the environment that have XDebug disabled. - Copy what was in your previous install into modules/custom and themes/custom
- On your Drupal VM, rebuild the caches in the web directory with
drush cr
Update
Now that you also have a fresh release of Drupal, update everything via your Drupal VM.
drush updb
drush entup
- You will now have a local environment to test the updates.
- If you still have your config into sites/default/files/config_xxx, consider that on the next
drush cex
it will live at the same level as vendor (so outside of the "web" docroot"). It should not be visible if you use a public repo. Also, while deploying into production, remove the sites/default/files/config_xxx directory because it will be useless now.
What's next?
You can now enjoy what's inside this Composer template, report to the Readme.
Resources
Drupal Composer resources
- Jeff Geerling (May 2017) Composer and Drupal are still strange bedfellows
- Drupal.org Using Composer to manage Drupal site dependencies
Add new comment