Upcoming Events
San Francisco CiviCRM Meetup - February 8th, 2012
February 8th, 2012
Come meet others from the Bay Area who are interested in, using or developing (more...)
UK usergroup - London meetup
February 8th, 2012
Come and meet others from the UK that are using CiviCRM or are interested in (more...)
London user and administrator training
February 23rd, 2012
A comprehensive two day hands on training course covering the configuration, (more...)
CiviCRM London sprint Feb 2012
February 27th, 2012
Following the CiviCRM training here in London, we will have a CiviCRM code (more...)
Philadelphia - CiviCRM Meetup for Q1 2012
March 13th, 2012
UK South West - CiviCRM Meetup
March 20th, 2012
Come meet others from the Area who are interested in, using or developing for (more...)
[Bristol, UK] user and administrator training
March 21st, 2012
A comprehensive hands on training course covering the configuration, (more...)
San Francisco user and administrator training
March 29th, 2012
A comprehensive two day hands on training course covering the configuration, (more...)
CiviCRM Usability, Test and Code Sprint - San Francisco (March 2012)
March 29th, 2012
This usability, code and test sprint is targeted at CiviCRM users and (more...)
CiviCon 2012 San Francisco Bay Area - April 2nd 2012
April 2nd, 2012
CiviCon is THE annual event bringing together the people who use, develop, (more...)
CiviCRM Documentation, Test and Code Sprint - after CiviCon San Francisco (April 2012)
April 4th, 2012
This sprint is targeted at CiviCRM users and developers who want to work on (more...)
CiviCRM Components
Tools for engaging your supporters...
CiviCRM and Drush Integration
- Not Just a Contact Database
-
These optional components give you more power to connect and engage your supporters.
civiCASE
Case management for clients and constituents.
civiCONTRIBUTE
Online fundraising and donor management.
civiEVENT
Online event registration and participant tracking.
civiMEMBER
Online signup and membership management.
civiMAIL
Personalized email blasts and newsletters.
civiREPORT
Report generation and template management.
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 http://wiki.civicrm.org/confluence/display/CRMDOC/Drush+CiviCRM+proof+of+concept 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. civicrm.drush.inc file for now is part of external tools repository. To avoid any problems with the script during civicrm-upgrade keep the latest copy of civicrm.drush.inc out of codebase since process involves removing (after backup) and adding codebase. I always keep it in my .drush folder. Check example.drush.inc 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 http://drupal.org/project/drush. Readme should help you start - http://drupalcode.org/viewvc/drupal/contributions/modules/drush/README.txt?view=markup. 2. Screencasts on above link should make you even more comfortable. 3. Download / checkout civicrm.drush.inc file from svn - http://svn.civicrm.org/tools/branches/v3.1/drupal/drush/civicrm.drush.inc 4. Place civicrm.drush.inc file inside your ~/.drush directory. And you are ready to play.
Comments
How to use with CiviCRM 3.0.3, and a bug report
I tried the civicrm-update-cfg command with CiviCRM 3.0.3 and got:
RECORD-dev3% drush -l http://stg.EXAMPLE.com/civicrm civicrm-update-cfg
PHP Fatal error: Call to undefined method CRM_Core_BAO_Setting::doSiteMove() in /usr/home/stg/.drush/civicrm.drush.inc on line 251
Fatal error: Call to undefined method CRM_Core_BAO_Setting::doSiteMove() in /usr/home/stg/.drush/civicrm.drush.inc on line 251
Drush command could not be completed. [error]
I copy/pasted http://svn.civicrm.org/civicrm/branches/v3.1/CRM/Core/BAO/Setting.php 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. :)
Patch submitted upstream
I managed to debug this and found that the reason it wasn't working is the $dir variable in doSiteMove() is a bit too low-level. Patch uploaded upstream to add a $siteRoot directory, which fixes it for me: http://issues.civicrm.org/jira/browse/CRM-5862
Failing with db-related error
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@127.0.0.1/civicrmtest?new_link=true): Unable to parse URL in /home/myuser/bin/drush-HEAD/includes/sitealias.inc on line 981. [error]
Fatal error: Unsupported operand types in /home/mindfulp/bin/drush-HEAD/includes/sitealias.inc 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 civicrm.drush.inc from svn as instructed and put it in ~/.drush . Also, I was getting MySQL socket errors from drush until I changed 'localhost' to '127.0.0.1' in settings.php and civicrm.settings.php as indicated here: http://drupal.org/node/222611#comment-1987148 – that fixed the socket errors.
Any idea what's wrong? What version of drush did you do your tests with?
Cannot redeclare civicrm_install
I checked out civicrm.drush.inc 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/civicrm.drush.inc:172) in /var/www/xxx/sites/all/modules/civicrm/drupal/civicrm.install on line 38
Drush command could not be completed.
what could that be?
mysql connectivity issue
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.
code was developed on v3.1
hey andy:
I dont think we've tested this on 3.0 beta as yet.
lobo
Woohoo!
Thanks, folks, this is great!
Great Stuff!
Thanks, this is great news! Can't wait to play with it.
Backups should not be stored in the webroot
Backups should not be stored in the webroot. Too easy for prying eyes to access.
default path used by drush
That's the default path used by drush too (for code backups). There is also a "--backup-dir" option which could be used.
But i also agree since it also includes sql backup. I'll make the default location to above drupal root directory.
Thanks.
This is great news.
Until this is packaged as a module, could you describe how to install ? Do we have to move civicrm.drush.inc to another location ?
For those leaving in the trunk side of things, would it handle incremental updates of the db ?
X+
Added a "How to start"
Added a "How to start" section to make it more clear. And yes it would also handle incremental updates of the db. thanks
awesome!!
was hoping someone would get this figured out. nice work!
drupal.org/project/drush_civicrm?
Excellent work! Now I think, creating a drush_civicrm project at drupal.org could be nice. As you mentioned, it's important to keep drush-civicrm separate from the CiviCRM code base, avoiding problems with upgrades, but as an extra it will also allow for a way to fetch CiviCRM merely through drush. E.g. drush dl drush_civicrm; drush -y en drush_civicrm; drush civicrm-download; drush -y en civicrm.
drush civicrm-download is still missing but shouldn't be too hard. The next step, slightly harder, would be to create drush civicrm-provision - and before we realize it will be part of aegir ;)
If I understand correctly,
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 :)
matt/bgm
currently it expects a valid
currently it expects a valid $civicrm_root in settings file. update-cfg takes care of correcting / fixing path settings in db.
Re: drush_civicrm project -
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.
thanks
dual licensing, provision
Dual licensing all Drush parts under GPL+AGPL would be a solution here I think. As long as all contributors are around and okay with this it's fine. It'll make it much easier for people to work with CiviCRM, or even just to try it out. Definitely worth it IMHO.
I'm not an expert in drush provision. "Provision is a component of the Hostmaster system. It provides a command line based back end that manages all the system level configuration required to provision sites and services. It provides a command line interface that the Hosting framework communicates with." * I think civicrm-provision should make it possible to set up CiviCRM automatically - set up the database and database user, create configuration files.
directly into drush project?
Maybe drush people could be happy to put drush civicrm stuff directly into the main code base? That way drush civicrm becomes completely independent from any installation, just like drush itself.
I just created an issue at drupal.org in order to involve experienced drushers: add drush civicrm to drush?
Cleaning up licensing within CiviCRM ...
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
lobo
Thank You!
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?