Grayside.Org - drush

Drush Snippets: Menu Trace

Grayside — Sat, 11 Aug 2012 19:08:54 +0000

Random snippet of the day, find out what modules are involved in building out a given menu route definition. When you type a URI into your browser, Drupal’s menu routing system connects that to your page content by processing the path into instructions for how to build the page.

To use this script, copy the text or clone from github as a file, make it executable. It will automatically run with drush php-script. You can use --verbose for “full array notation” of each module’s change to the menu route. Or you can just use --pipe to get a list of modules and go look at the code directly.

In theory this should work with Drupal 7, but I haven’t gotten around to testing it yet.

Terms:

Extending Drush Commands

Grayside — Sat, 21 Apr 2012 07:21:54 +0000

The other day around the office, I was surprised to discover not everyone realizes that you can do some crazy stuff around extending drush commands.

First step: Read the documentation. Drush is intentionally written to be a command-line foil for Drupal, and if you’ve built a module, a few minutes digging into the well-done docs will go a long way. Check out the Drush API if you are of a mind, or for a more focused burst of hook goodness, get out your terminal and type:

$> drush topic docs-api

Once you have a grasp of the fine hooks you can use to piggy-back on and around any Drush command, you can take it to the next level.

Adding Options

Adding options to a Drush command allows you to create more sophisticated, controllable extensions to core command behaviors.

There are several ways of doing this.

The command allows this already

Let’s not make this too complicated. Commands are sometimes intended as passthru mechanisms, such as drush rsync. How does it accept any rsynch command? It has a command definition that includes allow-additional-options => TRUE.

The user operates in non-strict mode

If the developer can set a flag, so can the user! You might have already seen this warning:

Unknown option: --simple.  See `drush help help` for available options. To suppress this error, add the option --strict=0.

This means that any time the user adds --strict=0 to a drush command invocation (or to their drushrc file for that specific command), your drush code can use drush_get_option() to access the submitted value.

But for the clever command extension…

You’ll want to implement hook_drush_help_alter(). Using this hook, you can add new options to a drush command that will be be qualified as “strict”, and will even show up in the help entry for the command in the user’s system.

Why didn’t you show source code?

Well, I had this small idea in mind, but it evolved rather quickly into a legitimate project. Go check out Drush Notify. It’s pretty Ubuntu-specific out the gate, but it serves as a great example of a powerful drush “extension” that defines no commands.

Terms:

drupal

drush

Configure Drush in Your Git Repository

Grayside — Sat, 20 Aug 2011 06:53:18 +0000

One of the neat features of Drush is it’s configurability. Setting the defaults for various behaviors and command options allows you to build really simplified, specialized workflows. You can create personal settings defaults by dropping a `drushrc.php` file in one of the places Drush will look, such as inside a .drush folder of your home directory.

It turns out this little capability has provided some very simple wins for developers at GoingOn. We pass around our projects and sites as a subdirectory of a Git repository that contains various things, such as documentation, deployment tools, and drush commands. Unfortunately, this slightly irregular practice disconnects Drush from the Drupal site and excludes those drush commands from the standard directories drush scans.

We fix this by making Drush aware of the Git Repo. There is a command-line script you can use to check if you are anywhere in a Git repository. By configuring Drush to check for a Git Repo on every drush bootstrapping, we give Drush a chance to pick up a bonus, repository-specific Drush config file.

Add this snippet to your drushrc.php file:

$output = array();
exec('git rev-parse --show-toplevel 2> /dev/null', $output);
 
if (!empty($output)) {
  $repo = $output[0];
 
  $options['config'] = $repo . '/drush/drushrc.php';
  $options['include'] = $repo . '/drush/commands';
  $options['alias-path'] = $repo . '/drush/aliases';
}

This script checks the current directory for participation in a git repository. If there is one, it looks at the root of the git repository for a ‘.drushrc.php’ file to provide repo-specific instructions to Drush. We use this to configure paths to external resources that can vary by code version, as well as setting the Drupal site root for the Drupal site sihpped with that particular repository.

The last line also seeks out a `scripts/` directory in the repository root, which it will scan recursively for any files ending in `.drush.inc`. This allows us to ship versioned drush commands with each repo instead of documenting a complex individual installation process.

There are many other things you can do with a little poking about in the options for a drushrc file, to learn more start with the drushrc.php example.

Update 7/16/2012: Updated code example to the same provided in Drush docs. You can now leverage this trick outside the root directory of your code repository. Also removed not applicable git context resulting in invalid configuration paths.

Terms:

drupal

drush

git

Drush with Bash Aliases

Grayside — Thu, 10 Jun 2010 06:18:40 +0000

I’ve been looking for some decent ways of managing the use of modules hosted in random Features Servers. Particularly, how do I use Drush as seamlessly with a Features Server as it works with Drupal.Org?

It turns out that Drush has a lot of special options buried in the pm-download (dl) command, the very Drush maneuver most helpful for my goal. Naturally, these options can be included in a Bash Alias for Drush.

alias dds='drush --source=http://code.developmentseed.org/fserver dl'

This alias specifically searches DevSeed’s features server for projects. Slide it into your .bashrc file. Now a quick $> dds fserver works like a charm.

I still think project repositories like Ubuntu’s package repos (or really, Arch repositories like Core, Extra, and Aur) have a lesson for us. But that can wait on the smoothing out of functionality like –destination, which allows you to say where a project will be saved, but not with the same grace as Drupal.Org projects and the modules/contrib/ directory.

Terms:

drush

features-servers

Drush and Features Servers

Grayside — Sat, 01 May 2010 07:14:15 +0000

Feature Servers have great potential to help structure the use of code sourced outside the formal ecosphere around Drupal.Org this has it’s pro’s and con’s, but I already see their usefulness in providing a little more structure to issue-queue code exchanges and organization-internal modules. So let’s bring Drush into this and boost the ease of use of that usefulness another step up.

For those who need more catching up:
Features are a special kind of Drupal module built on the features project. They allow you to easily export configuration from your site into a module usable on any site. Modules downloaded from a Features Server are the next best thing to one posted to Drupal.org. DrupalConSF has a great video.

Current State

The rise of Feature Servers, and perhaps other types of code release repositories would benefit from a little Drush magic. The little-documented option of –source is a starting place:

drush --source=http://code.developmentseed.org/fserver/ dl fserver

This code will grab the latest, most recommended release of the Feature Server code from DevSeed’s feature server.

Future Directions

I’ve started an issue in the Drush queue to talk about some kind of repository scheme to help manage the download and file placement of code from individually preferred repositories.

Terms: