fromMarch 2013
Article:

Creating a Drupal 7 Distribution

Capturing Your Own Installation Profile and Settings
0

Prior to version 7, most Drupal users — and even administrators — had little need to be familiar with the inner workings of distributions and installation profiles. For versions 6 and earlier, when installing a fresh copy of Drupal core, one naturally would specify the minimum required information: database connection, website name, and superuser account. Yet one had no opportunity to affect the list of modules and themes initially enabled, the default content types, or any other configuration details. However, anyone installing Drupal 7 is presented with a choice of installation profiles: "Standard" (the default) and "Minimal".

An installation profile comprises a set of files that completely describe how to configure a new installation of Drupal core, and can be made part of a distribution.

Default installation profile

The Drupal 7 installation screen mentions that the Standard profile offers “commonly used features pre-configured.” These include longstanding modules such as Color, Comment, and Search, as well as new ones such as Dashboard, Overlay, and Shortcut. The Standard profile includes the pre-built content types Article and Basic page, an administrator role, and even a taxonomy vocabulary (Tags).

DIY Distro

But what if you don't want most, or even any, of these preliminary settings chosen for you? You could instead opt for the Minimal profile, and add all your customizations on top of it each time you build a website. This could entail a lot of effort and time, clicking your way through GUI screens, downloading and enabling modules, and making numerous configuration changes. Instead, it would be convenient to be able to capture all of these actions and settings in your own distribution. In this article, we will learn how to do that.

This topic is best explored through example, and so we will build a distribution containing settings I have found to be valuable as a starting point for most new client websites. Aside from a Drupal core and its usual technical requirements, the only other web technology you need installed on the server is Drush.

A Solid Foundation

The first step is to create and configure the Drupal website to be exactly the way you want it in your distribution. In our example, we download and install the latest Drupal version, and use the Minimal installation profile in order to minimize the amount of subsequent changes that need to be made. For performance reasons, I typically use database logging only when appropriate for the project; so I disable the core module "Database logging". I enable nine must-have core modules: Contextual links, Field UI, File, Image, List, Menu, Number, Options, and Path.

Every designer and developer has his or her list of favorite contrib modules with which to begin every new project. Mine currently are: Add another; Administration menu, Administration menu Toolbar style; Chaos Tool Suite; Date, Date All Day, Date API, Date Popup, Date Repeat API, Date Tools, Date Views; Devel; Email Field; Entity API, Entity tokens; Fast Permissions Administration; Global Redirect; Login Destination; Module Filter; Page Title; Pathauto; Redirect 403 to User Login; Remove Generator META tag; Token; Transliteration; Views, Views UI; XML sitemap, XML sitemap engines, XML sitemap menu, XML sitemap node. All of these can be downloaded and easily enabled using just two Drush commands:

$ drush dl addanother admin_menu ctools date devel email entity fpa globalredirect login_destination module_filter page_title pathauto r4032login remove_generator token transliteration views xmlsitemap
$ drush en --yes addanother admin_menu* ctools date date_all_day date_popup date_repeat date_repeat_field date_tools date_views devel email entity entity_token fpa globalredirect login_destination module_filter page_title pathauto r4032login remove_generator token transliteration views views_ui xmlsitemap xmlsitemap_engines xmlsitemap_menu xmlsitemap_node

Make a Makefile

The next step in the process is to create a makefile, which is a manifest file formatted in the standard Drupal ".info" syntax. The makefile starts with a Drupal core version number, which can optionally start with a specific release number; otherwise, the most recent stable release is automatically chosen. It then specifies the Drush Make API version (in our case, 2). The bulk of the makefile specifies all of the contrib and custom modules used in the installation, as well as contrib libraries. Each contrib module entry can have a version number, if desired. (We will exclude all version numbers.) It can also have a path to a Git repository, local or remote; otherwise, Drupal.org is used as the source for downloading. Similarly, each custom module must have a Git path (e.g., on GitHub). Our distribution is intended to serve as a foundation upon which to build new websites, so let's call it "Base".

In the root directory, perform this Drush command:

drush generate-makefile base.make --exclude-versions

(The undocumented alias "make-generate" will also work.)

The generated makefile, when stripped of the (unnecessary) comments, comprises:

core = 7.x
api = 2
projects[] = "drupal"
projects[] = "addanother"
projects[] = "admin_menu"
projects[] = "ctools"
projects[] = "date"
projects[] = "devel"
projects[] = "email"
projects[] = "entity"
projects[] = "fpa"
projects[] = "globalredirect"
projects[] = "login_destination"
projects[] = "module_filter"
projects[] = "page_title"
projects[] = "pathauto"
projects[] = "r4032login"
projects[] = "remove_generator"
projects[] = "token"
projects[] = "transliteration"
projects[] = "views"
projects[] = "xmlsitemap"

If any needed information is missing — typically an unresolved Git path — then Drush will replace the item with a placeholder, which will need to be updated with the correct value prior to finalizing the distribution.

Saving Choices

You will also want to include any configuration changes. Drush does not include them in the generated makefile; rather, they must be captured in an installation profile file. There are over a dozen such changes that I have found to be quite helpful, but due to the limited space for this article, we cannot detail all of them. Here is an example of one setting, which we would put in base.install, since it is modifying the database and not the options in the profile's installation process (in which case it would be put in the hook function base_form_install_configure_form_alter(), in base.profile). Without the usual comments, our base.install consists of:

<?php
function base_install() {
  // Set the administration theme to Seven, instead of the default theme.
  variable_set('admin_theme', 'seven');
}

Wrapping It Up

Be sure to include the required files base.info and base.profile (which can be empty). In our case, base.info could be:

name = Base
description = Essential core and contrib modules, with configuration settings, and none of the annoying core modules.
core = 7.x

Test the installation profile to verify that it is now an option when re-installing the website.

New installation profile

The final step in creating the distribution is as follows:

drush make --prepare-install --tar base.make base

This command generates a tarball, base.tar.gz, in the root directory. It also creates a settings.php file with secure permissions, and a files/ directory.

This overview illustrates that it is not difficult to craft your own distribution, which you might decide to share with the rest of the Drupal community, on Drupal.org or GitHub.

Advertisement

From our blog

Entity Storage, the Drupal 8 Way

In Drupal 7 the Field API introduced the concept of swappable field storage.

The Drupal 6 to 8 Upgrade Challenge - Part 2

Having concluded the readiness assessment, we turn next to migrating the content and configuration. In reality, there’s little chance that we would migrate anything but the blogs from our old site. For the sake of giving Migrate in Core a workout with real conditions, however, we’re going to upgrade with core’s Migrate Drupal module rather than rebuilding.

The Drupal 6 to 8 Upgrade Challenge - Part 1

Nathaniel Catchpole , the Drupal 8 release maintainer and Tag1 Senior Performance Engineer, suggested that Drupal shops everywhere could support the

DrupalCon Austin

The entertainment industry is not for the faint of heart.

Drupal Watchdog Joins the Linux New Media Family
Drupal Watchdog 6.01 is the first issue published by Linux New Media.

Drupal Watchdog 6.01 is the first issue published by Linux New Media. Come see the Drupal Watchdog team at DrupalCon 2016!

Drupal Watchdog was founded in 2011 by Tag1 Consulting as a resource for the Drupal community to share news and information. Now in its sixth year, Drupal Watchdog is ready to expand to meet the needs of this growing community.

Drupal Watchdog will now be published by Linux New Media, aptly described as the Pulse of Open Source.

Welcome to DrupalCon Barcelona - The Director's Cut

For all you schedule-challenged CEOs – and ADHD coders – this Abbreviated Official Director’s Cut is just what the doctor ordered.

Welcome to DrupalCon - The Barcelona Edition

Did we have fun in Barcelona?
OMG, yes!

Did we eat all the tapas on the menu and wash them down with pitchers of sangria?
Yes indeed!

Recursive Closures and How to Get Rid of Them

This came up while manipulating taxonomy children and their children recursively, so it’s as not far from Drupal as you’d think.