Use the full power of Drush

Drush is probably one of the most useful tools a Drupal Developer has in his/her arsenal. Drush is a command line shell for Drupal and it can save you a lot of time when installing or updating Drupal instances with many modules. I was surprised to find out that there are lots of developers who don't yet use Drush full power and I can tell them one thing - you are missing big time, guys. In my post I will try to cover a few basic topics and, hopefully, will help you get started with Drush.

Table of contents

 

  1. Drush out-of-box commands
  2. Drush contrib commands
  3. Drush Aliases
  4. Improve your workflow with drush

 

Now, let's dig in...

Drush out-of-box commands

You can find all these commands here. But I will cover only a part of them, which I’ve used at least once and which can be useful to you as well.

Commands which you MUST know about:

  • cc - clear cache. Drupal core provides a round of cache types: default, bootstrap, field, menu, token etc. I hope you understand the purpose :) Because on large site calling drush cc all - is not a good way to achieve flushing agregated css or make new menu item appear. Use drush cc css+js.
  • dl - downloads given contrib module and put it into sites/all/modules/contrib by default. You can specify release version by adding -7.x-1.x ( drush dl entity-7.x-2.12 If you start to contribute (I hope so) you will need module repo instead of just module’s file, so you can change download handler with “--package-handler=git_drupalorg”. Then drush dl --package-handler=git_drupalorg draggableviews will make git clone of this project to your contrib directory (You can create own short command for it drush dlgit PROJECT for example, see here).
  • uli - Get onetime login link for given user name or uid or uid=1 by default. Example drush uli m1r1k will try to find user with username 'm1r1k' and build url with onetime link - http://default/user/reset/1/1385380689/tqunn-cZ4YcSTke9kUWRCin3eiqiQNv12...
  • upwd - Update given user's password
  • sql-sync - lots of ways to make and restores mysql dump (details below). I think it is the fastest way to import production DB into your local one. Example: drush sql-sync @PROJECT.prod --create-db will make a dump on production server side, then rsync it to you machine, then drop you current db (--create-db key does it, because db merging usually brings lots of problems...) and run sql import. With second param you can even specify target drupal installation - drush sql-sync @PROJECT.prod @PROJECT.stage --create-db
  • rsync - shortcut of default linux rsync command (details below). Example drush rsync @PROJECT.prod:%files sites/default/files will rsync whole sites/default/files directory from production server to your local.
  • en, dis, pml, pm-uninstall - I guess everyone knows these commands, they don’t have interesting options.
  • make - build sites from make file without bash coding.
  • updb - invoke update.php from command line. This method doesn’t required authentication and has less steps.
  • vget, vset - work with variables also through the drush, becase you don’t need to serialize or unserialize it, like with database.
  • image-flush [image-style-name] - Flushes all generated presets.
  • eval - Invokes string with php code after drupal’s fully bootsraped, like from you .module file, but without creating new function and poluting your code. Have you ever tried to get dump of core function from core? To full field definition foe example? Or get phpinfo's grepped value? Now you can run drush eval "var_dump(user_load(1));" on production site and got user object without devel enabled and even from your local machine (using drush aliases).

 

I strongly believe that we MUST replace every same UI operation with these Drush commands in our workflow!

Drush contrib comands

Every big contrib module has its own Drush commands, which help invoke all the common tasks that are using Drush. All these commands you can find in the PROJECT.drush.inc file. Modules implement hook_drush_command(). Here are some examples of useful drush commands:

 

  • Devel
    • devel-reinstall (dre) - Disables, Uninstalls, and Installs a list of projects in one command.
    • fn-hook - gets the list of implementation of given hook - drush fn-hook menu_alter.
  • Apache Solr
    • solr-index, solr-mark-all, sorl-delete-index - much more faster and easier than the UI alternative.
  • Migrate
    • migrate-import - performs the import task ( I will prepare a presentation about Migrate later).
  • Registry Rebuild
    • rr - Rebuild Registry of drupal bootstrap process.
  • Metatag
    • metatag-import-mtq - migrates from Metatags Quick module to Metatag.

 

Drush aliases

Every development process includes multiple Drupal environments, small list of them: local, stage and production server. Remember your working flow (except coding).

Here's an example of my workflow before I met Drush aliases:

  1. Get recent dump of DB and restore it to your local db (I had some bash aliases per project, sometimes I was using MySQL Client App and ssh connection);
  2. Sometimes you want to grab recent files from prod/stage (pure rsync with all ssh credentials);
  3. Code (unfortunately Drush can’t help here..) and push to origin repo;
  4. Connect to stage server;
  5. Make git pull;
  6. Then lots of different drush actions: clear cache, features, enable/disable/reinstall modules, reindex, whatever;
  7. Run tests
  8. If everything went fine on stage we repeat 4-7 steps for Prod deployment;

 

I think we’re making too much extra steps and lost too much time to routine tasks. Drush can help you here via Drush aliases. Here is an example:

<?php// Site propeople, environment local$aliases['local'] = array(  'uri' => 'local.site.com',  'root' => '/path/to/drupal/root',  'databases' => array (    'default' => array (      'default' => array (        'driver' => 'mysql',        'database' => 'database',        'username' => 'root',        'password' => 'password',        'host' => 'localhost',        'prefix' => '',      ),    ),  ),);// Site propeople, environment prod$aliases['prod'] = array(  'uri' => 'prod.site.com',  'root' => '/prod-path/to/drupal/root',  'databases' => array (    'default' => array (      'default' => array (        'driver' => 'mysql',        'database' => 'database',        'username' => 'root',        'password' => 'password',        'host' => 'localhost',        'prefix' => '',      ),    ),  ),  'remote-host' => '123.123.123.123',  'remote-user' => 'root',  'ssh-options' => ' -i /path/to/key/file',  'path-aliases' => array(    '%files' => 'sites/default/files',    '%dump-dir' => '/tmp',  ),);$aliases['stage'] = array(  'uri' => 'stage.site.com',  'root' => '/stage-path/to/drupal/root',  'databases' => array (    'default' => array (      'default' => array (        'driver' => 'mysql',        'database' => database,        'username' => 'root',        'password' => password,        'host' => 'host',        'prefix' => '',      ),    ),  ),  'remote-host' => '321.321.321.321',  'remote-user' => 'root',  'ssh-options' => ' -i /path/to/key/file',  'path-aliases' => array(    '%files' => 'sites/default/files',    '%dump-dir' => '/tmp',  ),);

Then put this code inside PROJECT/sites/all/drush/PROJECT.aliases.drushrc.php or inside ~/.drush/PROJECT.aliases.drushrc.php (second way makes this aliases accessible globaly, so you can run cc all on you production server even from another project directory).

'PROJECT' is a aliases file name and prefix (@PROJECT.aliase) is just name of drush aliases file, accessible from current drush context, but I think it is a good practise to name these files with project name.

Now my local drush knows everything about stage and prod environments and allows me use it localy in context of any other server. For example:

  • drush @PROJECT.prod cc all - Clear cache on production server from my local
  • drush @PROJECT.stage uli - gives me link to login as admin on stage server
  • drush sql-sync @PROJECT.prod @PROJECT.stage --create-db - Truncate my local db, make dump of prod db, download it and restore it to my local db
  • drush rsync @PROJECT.prod:sites/default/files @PROJECT.stage:sites/default/files - rsync al files from prod to stage server
  • drush @PROJECT.prod ssh - connect to Prod server via ssh

 

The fastest way to get aliase definition is run such command in drupal directory context - drush site-alias @self --with-db --show-passwords and add remote host information for external environments

Improve your workflow with Drush

Try using Drush wherever it’s possible and you will save your time!

Also don’t forget that Drush is command line tool, it doesn’t need any UI, it doesn’t need any page on your site, it isn’t afraid of php memory or time limits but it still uses Drupal bootstrap initialization. It brings lots of benefits for you! Have you ever made kind of scrub script for mysql to replace something in every node? Have you ever wanted to delete ALL node of particular tabs? Have you ever wated to create for example child nodes for particucal nodes with some conditions? Or whatever? drush brings power of linux biult-in batch to you and your PHP scripts!

Try it out!

Tags: DrupalCheck this option to include this post in Planet Drupal aggregator: planetTopics: Tech & Development

Original Article: