CiviCRM and Drush Integration

2010-03-08 02:33
Written by

Following some issues to integrate drush and making civicrm upgrade process accessible from script, I started looking at drush on how we can take advantage of it for civicrm, and was surprised with the ease I was able to reuse drush code to add few utilities for civicrm. Some of the utilities currently implemented are:
All civicrm-sql-* utilities reuse the drush code, making most of drupal sql-* utilities also available for civicrm. Update-cfg and upgrade-* methods use civicrm BAOs to do their job. A detailed help can be seen just as any other "drush help $command" -
For a quick view of how upgrade works with the script -
As you would have noticed currently it requires --tarfile option, an improved version could be, automatically downloading the latest tarfile when no option is provided. Another related improvment i can think of is adding civicrm-restore utility which would restore the codebase and database to the specified restore point. So a command to restore would look like: drush civicrm-restore --restore-point=/var/www/drupal-6.16/../backup/modules/20100308134039 Another set of commands like civicrm-cache-clear and civicrm-api will soon make there way in. Check for more details (thanks to Kasper Souren). Since the initialization process is already in, it would now be easier to experiment and add new utilities to the list (and submit patches). If you have already done any work on civicrm-drush, and would like to share / contribute, let me know. file for now is part of the Drupal repository. To avoid any problems with the script during civicrm-upgrade keep the latest copy of out of codebase since process involves removing (after backup) and adding codebase. I always keep it in my .drush folder. Check for other options.

How to start

For those who are not familiar with drush or don't know where to start - 1. Install and read about drush from 2. Screencasts on above link should make you even more comfortable. 3. Download / checkout file from svn - 4. Place file inside your ~/.drush directory. And you are ready to play.

Filed under
Click thumbs up if you thought this blog post was useful (login to vote or to comment)


was hoping someone would get this figured out. nice work!

Re: drush_civicrm project - might not, since we license using AGPL 3 and is not valid under drupal's cvs plus we like to keep one copy in our own svn.

Will experiment with civicrm-download if time permits.

Not sure what you mean by civicrm-provision. But do consider submitting any work you would do.


This is wonderful! So much time will be saved working with and setting up new sites! Thank You!!

As to the licensing issues - the rules should safeguard your work but not get in the way. As a CiviCRM Team member, are you required to contribute everything back to CiviCRM? Could you and or others maintain/co-maintain something in Drupal Contrib that depends on Civi but is licensed compatibly with Drupal/drush?

we are working with the FSF in cleaning up various licensing aspects of CiviCRM. I dont think i'm in favor of dual licensing parts of the code base. We ship a lot of drupal integration code within CiviCRM (which is not dual licenses) and our drush integration can potentially follow the same model


If I understand correctly, this should fix one of the annoyances in Aegir: migrating a CiviCRM site between platforms (ex: to upgrade Drupal) would break the $civicrm_root in civicrm.settings.php.

However, by the looks of it, it will not change the directory paths which are stored in the domain information in the database. Any suggestions on how to tackle that issue? (I wish they would just be relative)

(To avoid deleting the domain entry, I usually symlink the old path to the new one, login to CiviCRM, change config, then remove the symlink.)

I look forward to testing this :)


Until this is packaged as a module, could you describe how to install ? Do we have to move to another location ?

For those leaving in the trunk side of things, would it handle incremental updates of the db ?


Anonymous (not verified)
2010-03-20 - 04:05

Thanks, this is a super-helpful feature for drush, unfortuately it's not working for me.

I'm trying to update from CiviCRM 3.0 to 3.1.3 with this. Here's what I'm getting:

1. Code backed up.
WD php: parse_url(mysql://drupal:xxxxxx@ Unable to parse URL in /home/myuser/bin/drush-HEAD/includes/ on line 981. [error]

Fatal error: Unsupported operand types in /home/mindfulp/bin/drush-HEAD/includes/ on line 990 [error]
Drush command could not be completed.

This is with latest drush HEAD, but I get the same errors (with different line numbers) in the current supported drush release: All-versions-3.0-beta1.

I checked out from svn as instructed and put it in ~/.drush . Also, I was getting MySQL socket errors from drush until I changed 'localhost' to '' in settings.php and civicrm.settings.php as indicated here: – that fixed the socket errors.

Any idea what's wrong? What version of drush did you do your tests with?

Sounds like a mysql connectivity issue. You should check if drush's sql utilities are working for your drupal install and narrow it down from there, since civicrm uses same code/api. There are various reasons why a mysql connection would fail. You might want to google on it (socket errors).

* Use forums for support questions please.

I checked out from svn as instructed and put it in ~/.drush .

since then i get this error message:

Fatal error: Cannot redeclare civicrm_install() (previously declared in /home/torstenzenk/.drush/ in /var/www/xxx/sites/all/modules/civicrm/drupal/civicrm.install on line 38
Drush command could not be completed.

what could that be?

I tried the civicrm-update-cfg command with CiviCRM 3.0.3 and got:

RECORD-dev3% drush -l civicrm-update-cfg
PHP Fatal error: Call to undefined method CRM_Core_BAO_Setting::doSiteMove() in /usr/home/stg/.drush/ on line 251

Fatal error: Call to undefined method CRM_Core_BAO_Setting::doSiteMove() in /usr/home/stg/.drush/ on line 251
Drush command could not be completed. [error]

I copy/pasted over on top of our existing file and this time it seemed to work great!

Only problem is it didn't seem to affect the customPHPPathDir and customTemplateDir variables; those are still pointed at the dev site.

I second (or third) the request to get this great code on d.o, or else make it part of CiviCRM core, so it's available to all. :)