Getting Started With Drush Make

12th May 2012 - 13 minutes read time

Drush is a command line tool that allows interaction with a Drupal site. The tool itself is incredibily useful and provides mechanisms to download modules, backup databases and most other things that can be done with Drupal. Drush Make was a plugin for Drush which has now become part of the Drush core and allows Drupal sites to be created via a make file. What Drush Make does is to use the make file to download the modules, themes and libraries needed for a Drupal site ready for the site to be installed. This means you can give this make file to another developer who can then build their own Drupal site.

Installing Drush Make

As of Drush version 5 Drush Make is now part of the Drush core code so getting up and running is easy. Prior to Drush version 5 you had to install Drush Make separately, but the install process wasn't that difficult really. Just create a folder in your home directory called .drush and place the drush make files in there. When finished you should end up with a file like ~/.drush/drush_make/INSTALL.txt.

If you have installed Drush via pear then you will have Drush Make built in.

Anatomy Of A Make File

A Drush Make file has a quite simple format, which is split into a number of different sections. How many sections you use depends on what you need to use in your Drupal build. The bare minimum needed for a make file is the core project version, but you can add module, theme and library information on top of this.

Core Version
The core parameter defines the major version of Drupal that this make file will create. To create a project for a Drupal 6 build you would enter 6.x, and for Drupal 7 you would enter 7.x. A make file must always contain this information.

core = 7.x

API Version
This is the API version of Drush Make, which also must be included in every file. The current version is '2'.

api = 2


This is the main part of the make file and defines the different modules and themes that will be downloaded when the make file is run. If your build file is to be used to download the Drupal core files then you must include an instruction to do that, so this is a good place to start with the projects setting. To include the latest (stable) release of Drupal in your build do the following:

projects[] = drupal

You can change this to any project name to include that project in your build. For example, to include the latest version of the Views module you would do the following:

projects[] = views

Once you have the item in the projects list then you can set certain options for it. For example, to set a specific version for the item you add the version attribute to the list, much like you would in PHP. The following sets a specific version of Drupal that wll be used in this install.

projects[drupal][version] = 7.15

You can also set just the major version here if you want to get the latest version of the project.

projects[drupal][version] = 7

The shorthand for setting the version is to simply omit the version attribute, it is assumed that this is the latest version if no other options are supplied.

projects[drupal] = 7

Sometimes it is necessary to apply patches to code, and it is best to do this automatically rather than rely on applying them manually when the site is rebuilt. Drush Make can apply a patch file to a module automatically by using the patch reference and a URL to the patch file.

projects[amodule][patch][] = ""

This directive will change the default location of the directory that the module files will be downloaded to. By default this will be set to "sites/all/modules". The following will set the directory that the CTools module will be placed in to "sites/all/modules/contrib/ctools".

projects[ctools][subdir] = "contrib"

The default behaviour of Drush Make is not to overwrite files if they already exist, in fact, it will flag an error if the directory already exists. This can be changed by setting the overwrite property to TRUE.

projects[amodule][overwrite] = TRUE

Third party code libraries can form an integral part of your Drupal site and are usually placed in a libraries folder, separate to any module and theme source code. This might be things like WYSIWYG editors, JavaScript plugins or even PHP libraries. The libraries array tells Drush Make to download the library file and extract it into the "sites/all/libraries" folder. The following will download the CKEditor, unzip it and place it into the correct folder.

  1. libraries[ckeditor][download][type] = "file"
  2. libraries[ckeditor][download][url] = ""

To add a comment to a Drush Make file you just need to add a semi-colon (;)to the start of the line. This is useful if you want to add a header to the file so that you know what it will do, or if you wish to split the file into sections for core, module, theme and library elements.

There are plenty of other options available here and I haven't touched on them all and going through them is almost unnecessary. I have mainly looked at the most commonly used or useful ones but you can change the way the above commands work, as well as do other things like include a make file from a make file. For a full list you can look at the Drush Make readme file.

Creating A Make File

Creating a large make file from scratch is a little tedious (and scary to the newcomer), but there is a short cut that will allow the generation of a make file from an existing Drupal site. When you have set up your Drupal site you can generate a make file for it by using the make-generate drush command. The following will generate a make file called mysite.make in the root of the Drupal build.

drush make-generate mysite.make

On a fresh install of Drupal the above command would create the following make file.

  1. ; This file was auto-generated by drush make
  2. core = 7.x
  4. api = 2
  5. projects[drupal][version] = "7.x"

Once you have this generated you can regenerate it as much as you need, just be warned that if you edit the file it will be overwritten if you regernate it again later. When you enable modules and regenerate the make file you will see those modules added to the make file. To demonstrate this I downloaded and enabled the Views and CTools modules and then regenerated the make file.

  1. ; This file was auto-generated by drush make
  2. core = 7.x
  4. api = 2
  5. projects[drupal][version] = "7.x"
  7. ; Modules
  8. projects[ctools][subdir] = "contrib"
  9. projects[ctools][version] = "1.0"
  11. projects[views][subdir] = "contrib"
  12. projects[views][version] = "3.3"

Using A Make File

This is where the main power of DrushMake lies, and is probably the easiest part of the whole process. To use a make file with make you just need to run the following command.

drush make mysite.make

Drush Make will then create a Drupal site using the make file as a blueprint. Every time a project is downloaded a notification is printed out on screen so you can easily see that the make file is doing everything it should be. If any problems arise (like missing files or permissions issues) they will also be reported.


Of course, knowing how to use Drush Make is only half of the process. As with any tool of this nature it is only powerful if you use it in the right ways. I have hinted at some strategies of how to get the most out of Drush Make at the start of this post, but I thought I would devote a section to detail some of the things I have learnt whilst using Drush in my day job.

Source Control
First and foremost, the main benefit of using Drush Make is a massive simplification of source control. Before I started using Drush Make I would add all Drupal source code files, module files and theme files into source control, which would lead to a large overhead in the code that I had to manage.

To simplify this you only need to add your custom files and a make file that will build the rest of the site around these files to your source control management. Taking an example, lets say I was building a site that contained a module called mymodule. My site source code would only contain that module and a make file that built the rest of the site around this module. The directory structure of the source code would look something like this.

  1. sites
  2. --all
  3. ----modules
  4. ------custom
  5. --------mymodule
  6. ----------mymodule.module
  8. mysite.make

I have put the make file in the site root, but it doesn't necessarily need to go here. You can put it in as part of a profile or even just outside of the web root. If you do put it outside the web root you can reference it like this.

drush make ../mysite.make

It is even possible to go one step beyond this and only have the make file that pulls in your custom module files from another source control location. You can currently use Bazaar, CVS, SVN or Git source control systems to include code within a make file.

Drush Make will only download the source files for a project and this does not include any form of configuration or settings. Using it in conjunction with Features allows sites to be built entirely from the ground up. This means you can get a fully working replica of a site via the command line in just three commands.

  1. $ drush make mysite.make
  2. $ drush si --account-name=admin --account-pass=admin --db-url=mysql://user:[email protected]/dbname
  3. $ drush en mymodule --yes

Here's My Make File
Giving a developer a make file means that they can pull in the needed libraries and modules before enabling a module. Many modules with complex setups now come with make files so that developers can run them and pull in everything needed rather than having to go to multiple resources one at a time and downloading them manually.

Make, Update, Test, Deploy
Once a site has been built and put live you might have the need to update it at some point. You can update your module and core code and ensure that everything works before writing the configback into the make file. With this updated file in hand you can put your site in maintenence mode and apply the code changes before running your database updates.


A few resources to help you out when getting to grips to Drush and Drush Make.


Hi, Thanks for writing this article. I am wondering where your make file is. You mention it in your post but I don't see it. Thanks, Larry

Larry Morroni (Wed, 04/10/2013 - 19:54)

The make file for this site is pretty simple really. I coud supply it and a couple of more complex examples if you want?
Thanks for this. I am not familiar with Features - is the idea that you can extract the configuration and settings from an existing database and then apply these to a new / clean database ie to copy the configuration and settings but not the data from an existing database to a new website?

Juc1 (Wed, 04/24/2013 - 00:44)

@Juc1 That is correct. You can export everything from content types to views into a feature and then package that as part of your make file. You would also include the other modules as dependencies in your features module so that they are activated when the feature is installed.
Hi Philip, Is it possible to download any custom module from any url using make file ? For ex. projects[custom_module] = "" Thanks, Bhupendra Kanojiya

Bhupendra (Mon, 02/02/2015 - 08:05)

I don't think that would work. I have a feeling that Drush would just tell you that the project 'custom_module' doesn't exist. What happened when you ran this?
You can use make files also for downloading from external sources, see also: change the download type to 'file' and set a download url. Drush can unpack tar.gz and zip Example:
  1. ; Use Pressflow instead of Drupal core:
  2. ; projects[pressflow][type] = "core"
  3. ; projects[pressflow][download][type] = "file"
  4. ; projects[pressflow][download][url] = ""

Tessa Bakker (Sat, 02/21/2015 - 15:38)

How can add other languages in my make file ? I try to use projects[] = de and i have an error.

Flow1990 (Fri, 03/04/2016 - 10:54)

Add new comment

The content of this field is kept private and will not be shown publicly.