Introducing Devit

Devit Admin
You have a live website and you need to copy a fresh version of the (live) database onto your local machine for development. Next, you need to run through one or more of these rote tasks:

  • Disable Drupal core caches (page cache, block cache, CSS & JS optimization, etc.)
  • Sanitize user data
  • Update Drupal's file system paths (public, private, tmp directories)
  • Enable email rerouting
  • Update logging and error level settings
  • Re-configure a contrib module. E.g., Secure Site (enable, set permissions, guest accounts).

Does this sound familiar? If so, I have good news! I've created a module that will help you automate that process.

Devit allows you to select or create tasks that should be run when your database needs to be deved. You can initiate these tasks via an administrative page, or via Drush.

Devit comes with a submodule that will provide you with the basic tasks, but it also provides an API that allows you to create your own tasks! Ideally, various contrib modules will be packaged with their own Devit tasks. For example:

  • Secure Site could have a Devit task that enables secure_site and sets default permissions, passwords, etc.
  • Advagg could have a task that disables all of its fancy features.
  • Features could have a task that performs a features revert and enables the Features UI module.

Choosing & executing Devit tasks

There are a few ways to choose and execute the selection devit tasks that you'd like to run.

  1. The devit_ui sub-module provides a user interface that allows administrators to choose and execute Devit tasks (image above).
  2. Your own, custom devit tasks can be defined with a default status of TRUE—these will run when your site is deved via Drush.
  3. A selection of Devit tasks can be defined in a devit.settings.php file. This option allows you to easily define a set of Devit tasks that are unique to your development environment. These settings will supersede the default status of your tasks, and the Devit configuration stored in your database. Must be executed via Drush.

This file must be placed in your site directory, e.g., /sites/default. It contains a simple, flat array keyed by task names:
// Set whether a task should be executed when Devit is run.
$tasks = array(
// Key rows by task name.
'clear-caches' => TRUE,
'update-file-paths' => FALSE,

Here's a quick example of deving your site via Drush!

$ drush devit
Please enter the new password for all users [password]: new_pass
Set files directory path [sites/files]: new_files_dir
Files directory path changed to new_files_dir.                                                                         [success]
Site ready for development! 

Defining your own tasks

Devit provides an API that works much like the Menu API. The hook_devit_tasks() function allows you to define your own Devit tasks, and gives you the familiar framework to specify details like title, description, task callback, user access callback, file includes, etc.
Here's a quick example:

 * Implements hook_devit_tasks().
function yourmodule_devit_tasks() {
  $tasks = array();

  $tasks['disable-caching'] = array(
    'title' => t('Disable core caching features'),
    'description' => t('Disables page cache, page compression, block cache, and CSS & JS optimization.'),
    'task callback' => 'yourmodule_disable_caching',
    'access arguments' => 'administer site configuration',

  return $tasks;

 * Disables core caching.
function yourmodule_disable_caching() {
  variable_set('cache', "0");
  variable_set('block_cache', "0");
  variable_set('preprocess_js', "0");
  variable_set('preprocess_css', "0");
  variable_set('page_compression', "0");

Wrap Up

This module is still very much in development, but I'd like to gauge the level of interest in this tool. Would you use it? Do you have any ideas to contribute?

You could say things like:

  • "I want to help you!"
  • "Great idea, but you should consider..."
  • "Matt, this is a terrible idea because...".
  • "This module is like a beautiful snowflake."


Seems like a pretty good idea and I for one already have some custom stuff like this I reuse for my own projects so this is definitely something I'd appreciate :)

I've been considering a module to do similar, but with an eye to anonymising data for export to dev environments. Modules could implement hook_anonymise (-ze?) to replace identifiable data with sample content.

Using $conf in settings.php to override eg payment gateway settings for dev setups is handy too, and some of the tasks you mention above might be done there (eg secure site?). Need to look at this in context of Commerce gateways, where I suspect $conf won't do.

Have you seen the example Drush post-sql-sync hook in the Drush examples folder? It does a subset of these operations after an sql-sync command. You could put a post-sql-sync hook into devit to do the same thing.

Of course, in the case of devit, you have a bit of a chicken-and-egg problem, since (a) devit probably isn't enabled on your live site (ideally), and (b) your post-hook function won't fire if your module isn't enabled. If you enabled devit with sync-enable, then you could potentially use a Drush post-enable hook to run your devit commands (probably only if a specific option appears on the commandline). Then you could set this option as a command-specific option in your dev site alias, and your devit commands would then fire automatically whenever you sql-sync from live to dev.

I like to use options defined in my site alias files to control more than just dev site set up; for example, my backup script consults the target sites alias files to determine what should be done during backup and update operations. I prefer to keep the backup site more or less unchanged, but I enable to environment indicator module for anonymous users. I sometimes like to sanitize the update site, and when I do, I put these options into the alias record for the update site. (For reference, my update script is at: So, I have not only 'dev' targets, but also 'backup' and 'update' targets, and the operations that happens on each can vary.

I think that devit could be an interesting way to extend this concept even further, by providing a collection of more useful things to do when a site is migrated. Some example documentation on how to control devit options from a Drush site alias, avoiding the need to keep devit config in the database of the live site, would be a useful addition.

Love this idea! I'm about to revise our workflow when it comes to development copies and syncing, and devit will definitely be a part of it! :)

I think it can be quite usefull. I would use it for some of my projects.

Maybe a stupid question, but why isn't it implemented fully as a drush plugin? :)

In reply to by Dieter Blomme

I'd certainly love integrate devit with drush to a greater degree. Making it into a module offers a few advantages, the main one being that it is more easily extended and integrated with other contrib modules via the hook system.

Great work! We've developed a similar module, called Tadaa (, where you can set up any number of environments, and switch module states and variables depending on the environment. It's all in the UI so users won't have to write code to add their own stuff.

Add new comment

Plain text

  • No HTML tags allowed.
  • Lines and paragraphs break automatically.