Jan 29 2017
Jan 29
Drush stands for "Drupal shell" which means a powerful tool for managing Drupal installation from command line interface. Drush provides a lot of useful commands for dealing with a cache, modules, cron, database etc. But some of contrib modules also provide some extra drush commands for specific functionality (like features module comes with commands for managing features). Here's a bunch of a useful drush commands which I use every day.


# Clear all caches.
drush cc all

# Clear menu cache.
drush cc menu

# Select cache bin for clearing.
drush cc


# Download module by name. You can grab module
# name from module's page on drupal.org.
drush dl module_name

# Download module by name.
# into sites/default/modules/custom
# directory.
drush dl module_name --destination=sites/default/modules/custom

# Enable module by name.
drush en module_name

# Disable module by name.
drush dis module_name

# Uninstall module by name.
# This commands will call hook_name_uninstall().
drush pmu module_name

# Get list of available modules
# in your Drupal installation.
drush pml

# Check if module module_name
# is available in your Drupal
# installation.
drush pml | grep module_name


# Get an one-time login link
# for user by his/her uid.
drush uli uid

# Get an one-time login link
# for user by his/her email.
drush uli [email protected]

# Block user by his/her username.
drush ublk test_user

# Unblock user by his/her username.
drush uublk test_user

# Change password for user by his/her name.
drush upwd --password="password" user_name

Pending database updates

# Run all available database updates
# implemented in hook_update_N() in
# *.install files. 
drush updb


# Run cron.php. It will call all hook_cron()
# defined in modules and process cron queues.
drush cron


# Get variable value by name.
drush vget variable_name

# Set variable value by name.
drush vset variable_name "Test value"

# Delete variable by name.
drush vdel variable_name


# Install registry_rebuild drush extension.
drush dl registry_rebuild

# Rebuild Drupal registry. Usefull when some of
# modules was moved into another folder.
drush rr


# Get list of available features.
drush fl

# Get list of overridden features. Please
# note if you have multilingual site and
# site active language is not english then
# you have to replace word "Overridden" by
# it's translation.
drush fl | grep Overridden

# Show diff of overridden feature by name.
drush fd feature_name

# Update feature by name. Put changes from
# database into a code.
drush fu feature_name

# Revert feature by name. Restore database
# state from a code.
drush fr feature_name

Sql interface

# Show information about current database connection
# that defined in settings.php file.
drush sql-connect

# Login into sql console interface.
drush sqlc

# Execute a query.
drush sqlq "SELECT * from node;"

# Restore database dump from dump_name.sql file.
drush sqlc < dump_name.sql

# Save database dump into dump_name.sql.gz file.
drush sql-dump --gzip --result-file=dump_name.sql.gz


# Run custom php code.
drush eval "variable_set('site_name', 'Test site name');"

# Get all dblog messages in realtime (tail style).
# Useful when you want to debug a remote Drupal
# installation where you have ssh access.
drush ws --tail

Key notes:

Jan 07 2017
Jan 07
If you have redirect functionality implemented with drupal_goto() function on hook_init() probably you aren't able to run drush commands because they crashe with a message:
Drush command terminated abnormally due to an unrecoverable error.  [error]
It happens because drush bootstraps Drupal application but can't perform redirect. To avoid this you need to check whether script runs from cli or not:

 * Implements hook_init().
function module_init() {
  if (!drupal_is_cli()) {

Key notes:

Jan 31 2016
Jan 31

Here is a complete guide to get your drush working OS X El Capitan.

1) Download latest stable release using the code below or browse to github.com/drush-ops/drush/releases.

wget http://files.drush.org/drush.phar

(Or use our upcoming release: wget http://files.drush.org/drush-unstable.phar)

2) Test your install.

php drush.phar core-status

3) Rename to `drush` instead of `php drush.phar`. Destination can be anywhere on $PATH.

chmod +x drush.phar
sudo mv drush.phar /usr/local/bin/drush

4) Enrich the bash startup file with completion and aliases.

drush init

5) Add the following lines to .bashrc. (Check which PHP version you are using!)

export MAMP_PHP=/Applications/MAMP/bin/php/php5.6.10/bin
export PATH=$PATH:/Applications/MAMP/Library/bin
export PHP_OPTIONS='-d memory_limit="512M"'

6) Add the following line to .bash_profie

if [ -f ~/.bashrc ]; then . ~/.bashrc; fi

That’s it, you will have a fully functional drush on your Macintosh.

Nov 11 2010
Nov 11

Setting up Simpletest and Drush on Drupal 6.x:

  1. Download and enable Simpletest with drush dl simpletest; drush en -y simpletest
  2. Download simpletest.drush.inc to your ~/.drush/drush_extras directory. This version allows you to run a single test from the command-line.
  3. Create a custom module with a tests/ subdirectory, and write your tests in it. (See this Lullabot Simpletest tutorial.)

We’re starting another Drupal project. While the IT architect is working on clarifying the requirements, I volunteered to implement the risky parts so that we could get a better sense of what we needed to do.

The first major chunk of risk was fine-grained access control. Some users needed to be able to edit the nodes associated with other users, and some users needed to have partial access to nodes depending on how they were referenced by the node. Because there were many cases, I decided to start by writing unit tests.

SimpleTest was not as straightforward in Drupal 6.x as it was in Drupal 5.x. There were a few things that confused me before I figured things out.

I wondered why my queries were running off different table prefixes. I didn’t have some of the data I expected to have. It turns out that Simpletest now works on a separate Drupal instance by default, using a unique table prefix so that it doesn’t mess around with your regular database. I’m doing this on a test server and I want to be able to easily look up details using SQL, so I needed to add this to my test case:

class ExampleTestCase extends DrupalWebTestCase {
  function setUp() {
    global $base_url;
    $this->originalPrefix = $GLOBALS['db_prefix'];
  function tearDown() { }

I also didn’t like how the built-in $this->drupalCreateUser took permissions instead of roles, and how it created custom roles each time. I created a function that looked up the role IDs using the {role} table, then added the role IDs and roles to the $edit['roles'] array before creating the user.

Lastly, I needed to add the Content Profile operations to my custom user creation function. I based this code on content_profile.test.

// create a content_profile node
$edit = array(
  'title' => $account->name,
  'body'  => $this->randomName(),
$this->drupalPost('node/add/' . str_replace(' ', '-', $role), $edit, t('Save'));

It would’ve been even better to do this without going through the web interface, but it was fine for a quick hack.

I had the setup I wanted for writing test cases that checked user permissions. I wrote functions for checking if the user could accept an invitation (must be invited, must not already have accepted, and must be able to fit). SimpleTest made it easy to test each of the functions, allowing me to build and test blocks that I could then put together.

The code in content_permission.module turned out to be a good starting point for my field-level permissions, while the Drupal node access API made it easy to handle the user-association-related permissions even though I used node references instead of user references.

It was a good day of hacking. I wrote tests, then I wrote code, then I argued with the computer until my tests passed. ;) It was fun seeing my progress and knowing I wasn’t screwing up things I’d already solved.

If you’re writing Drupal code, I strongly recommend giving SimpleTest a try. Implementing hook_node_access_records and hook_node_grants is much easier when you can write a test to make sure the right records are showing up. (With the occasional use of node_access_acquire_grants to recalculate…) Otherwise-invisible Drupal code becomes easy to verify. The time you invest into writing tests will pay off throughout the project, and during future work as well. Have fun!

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web