Start You Own Drupal Distribution with Drush Make. Part 1.

As a rule, we get used to enjoy some limited set of trusted modules, especially if we often have to work on typical projects.

I remember when I started working with Drupal, every time for each new project I collected fresh new versions of my favorite modules on It was monotonic mannual work and I wast a lot of time before starting new Drupal installation.

But after meeting with Drush Make I was really happy!

I will not tell about the installing this extension of Drupal Shell, yet immediately move on to writing .make file.

First of all we should start with two service lines:
; Core version
; ------------
; Each makefile should begin by declaring the core version of Drupal that all
; projects should be compatible with.
core = 7.x

; API version
; ------------
; Every makefile needs to declare it's Drush Make API version. This version of
; drush make uses API version "2".
api = 2

After that we need to indicate core version that we are going to use. To use the latest Drupal version we should write only following:
projects[drupal][type] = core

We can also type the version of the core that we need. In this case our .make file will be following:
core = 7.x
api = 2
projects[drupal][type] = core
projects[drupal][version] = 7.8

But we can use also PressFlow as core for our distribution. There is no any other way to obtaine PressFlow only to get it from GitHub.
For this porpouse pressflow.make was created:
core = 7.x
api = 2
projects[pressflow][type] = core
projects[pressflow][download][type] = git
projects[pressflow][download][url] = git://

If you have this file you can type:
$ drush make --prepare-install --tar pressflow.make pressflow

And in several minutes have pressflow.tar.gz

Ok, I describe below what each argument of drush make command means.

--prepare-install mean that Drush Make prepare "files" folder and "settings.php" file future installation, I remember I had often had to do it manually :-)

--tar will do archive .tar.gz with your distro.

The following parameters are the name of the our make file and the name of the target archive or folder if we miss --tar parameter.

Let's talk about how to add modules and themes in our distribution. Fairly complete documentation you can be find on But I'm going to provide several examples to cover main part of content of the document.

Lets start with modules. There is a good practice to put all contributed modules in the folder "sites/all/modules/contrib", and put your custom modules into "sites/all/modules/custom". I like Backup&Migrate module so I put it into each my distribution:

projects[backup_migrate][subdir] = "contrib"

In this case Drush Make get recommended version of the module and put it into "sites/all/modules/contrib".
But in some cases there is no recommended version, or if you want to use some selected version, you should input it in the instructions to Drush Make:

For example, if you want to use Defaul Content module, you should indicate the version of the module, because this modul have no recommended version yet:

projects[defaultcontent][subdir] = "contrib"
projects[defaultcontent][version] = "1.0-alpha4"

Also you can get latest version of module directly from GIT:

projects[addthis][subdir] = "contrib"
projects[addthis][download][type] = "git"
projects[addthis][download][url] = ""
projects[addthis][download][branch] = "7.x-2.x"

How to add themes?

projects[omega][type] = "theme"

We should touch at list one parameter to include project into distro, so we indicate that Omega is theme, but it is obvious for us.

And finnaly we can include in our distributions third party libraries, for example lets add colorbox to our distribution:

libraries[colorbox][download][type] = "get"
libraries[colorbox][download][url] = ""
libraries[colorbox][directory_name] = "colorbox"

The code will be putted into "sites/all/libraries/colorbox" folder.

I think this information will be enough to start you own experiments. I'm going to create the second part of the tutorial. Waiting the updates in my Blog.


How to transfer the content type settings by Features?

In the post How to Create Content Type in Drupal 7 Programmatically I told about creating content type with using .install file.

But more often during development, we are dealing with a situation where some type of content is created in the admin to set up a specific field. These settings are made on staging while production site lived his own life, filled with new content and users. Obviously, it would be inexcusable mistake to overwrite production DB by staging ones.

On the other hand, we can transfer all the settings manually, but it takes a long time, moreover, there is no guarantee that we do not forget anything.

A simple solution to this issue is to use Features module.

Lets we have the type of content portfolio (admin/structure/types/manage/portfolio/fields):

We should be sure that module Features exitsts and enabled.

Lets go Administration » Structure » Features
and click "Create Feature" tab.

We should input "Name" and "Description" of our new feature. Also you can see "Version" and "URL of update XML", do not pay attention on them. Just now we are not going to provide our feature to somebody and make some new versions.

Lets go ahead! Take a look on the second fieldset. We should select content type that we would like to export. On the right we can see dependencies.

After we press download the feature will be ready for downloading.
In the current case got portfolio_content_type.tar

If you will take a look on content of this archive you can find module.
Pay attention to the .info file. Module has dependencies:

dependencies[] = "colorbox"
dependencies[] = "features"
dependencies[] = "image"
dependencies[] = "strongarm"

So on the site, where you would like to copy content type, these modules should be enabled.

Copy this module to the other site and you can see it in the list of modules:

But you should not turn on it here. Please, go to Administration » Structure » Features:

You can see the list of all features available. On this cas there is only one Feature.
You can turn on it to click on "Disabled". And new content type with corresponding field settings will appear!

Good! It is more simple way to create content on the site by one click that I told in the topic How to Create Content Type in Drupal 7 Programmatically. But it is feature based method, in the post that I mention content type was created without Features module, it is more native way, more preferable for the Code Driven Development approach.