Drupal Development: some tools and utilities

I finally took the time to make my 'drupaldev'-repository available.

First a short introduction: It is my strong opinion that Drupal modules which are only used during development, such as devel, diff, etc, should never be deployed to production. They shouldn't even be in the repository. Instead, I keep a personal collection of development-modules in a separate repo. Thanks to the fact that Drupal recursively searches for modules inside the modules folder, I can simply create a symlink to my collection of development modules. This allows me to use my preferred modules, even though they are not in the repository for the project.

For Drupal7, I usually just create a symlink, named devmodules7, in sites/all/modules. Like this:

1
2
# from the drupal root of the project
ln -s ~/drupaldev/devmodules7 sites/all/modules/

The repository itself contains a collection of modules, for both Drupal 6 and Drupal 7, and some utility-scripts. After experimenting with copies of the modules and git submodules, I finally settled on drush make to manage the modules. Instead of copying all the modules in my repo, I only keep a make-file for each Drupal version (currently 6 & 7). This makes it really easy to update all the modules, as I can simply run the makefile again. To make this even easier I have added a build script which will run all the drush make-files with the correct arguments:

1
./build

The utility-scripts currently only exist for Drupal7. First there is the install_dev script. This script can install a Drupal from scratch using a provided installation profile and then completely sets up my preferred Drupal development environment. This means that it enables all my preferred development modules, disables some and configures some settings. The script can also be instructed to skip the fresh installation, so it can be run when you are forced to use a database-dump. To make it a little easier to start the script I use an alias in my .bashrc file, which let's me start the script from somewhere in the drupal-tree:

1
2
# in my .bashrc
alias drupal-install="\`drush dd\`/sites/all/modules/devmodules7/install_dev"

Now I can simply run the script inside my Drupal installation:

1
2
3
4
56
7
# install the default site from scratch with the 'foobar' installation profile
cd /path/to/drupal
drupal-install foobar
 
# setup in the budts.be configuration without installationcd sites/budts.be
drupal-install --skip-siteinstall

Another included script is phpsh-bootstrap.inc. This script can be used to bootstrap your Drupal inside phpsh. phpsh is an interactive php shell, created by Facebook. That's already really cool, as it is a lot better than the default interactive PHP. But what makes this completely awesome, is that it allows you to provide a bootstrap script to start your preferred framework. With the included script you can start phpsh, bootstrap your Drupal and *boom*, you have an interactive shell which is running inside your live Drupal. You have access to your full Drupal environment and it allows you to do everything a regular page request can do. Similar as to the install_dev script, I also have an alias for this in my .bashrc:

1
alias drupal-phpsh="REMOTE_ADDR='localhost' phpsh sites/all/modules/devmodules7/phpsh-bootstrap.inc"

With that alias I can start phpsh by running `drupal-phpsh` from the root of my Drupal project.

Comments

Anonymous's picture

Rightfully so, nice write up! However, scenario's exist where "development modules" are actually used as real production tools, think of masquerade for instance. That's an exception atop of your statement I'd say.

Regards,
Niels

jeroen's picture

Niels, you are right, sometimes those 'development modules' are useful on production. Environment_indicator is a good example. However, Thanks to the fact that Drupal has no real problems with duplicate modules (that I know of), I have had no real problems with this. When a development module is also in the main project repository, Drupal just chooses one of the two modules on installation. And when working with a database dump, Drupal will probably also just use the version from the main repository as it already knows about that.

vicky's picture

I think the drupal has no problems with the duplicate modules. It is with the API modules that all the problem of nodding arises with. Sincere thanks for sharing us with such a wonderful thought in this site.

Add new comment