Tag: 6

Drush Make: Avoid the Unexpected

There are two things that are no secret and which form the basis for this post:

  1. Using the development versions of Drupal modules is sometimes the best choice.
  2. Using development versions as the project[module_name][version] parameter in a Drush Make file is always a bad choice.

How can we reconcile these two seemingly irreconcilable truths? The answer is actually very straightforward, and it’s even documented in Drush Make’s README.txt file itself1!

I tweeted a link to this pastebin snippet the other day. Keep that open, and let’s take a closer look.

This example comes directly from a Drush Make file I actually use:

; Download the module with Git
projects[webform_userpoints][download][type] = "git"

; Find this revision by clicking View Commits on the project page
; in the lower right-hand column. Click on the most recent commit
; in the branch you were going to use. Copy and paste the full revision
; identifier.
projects[webform_userpoints][download][revision] = "25bfe11d2c6dc6480d0aabc79b1edb54dec06236"

; Tell Drush Make it's a module. This might not be necessary.
projects[webform_userpoints][type] = "module"

; You can erase or change the subdirectory. I like to separate
; my Git-downloaded modules.
projects[webform_userpoints][subdir] = "_custom"

The comments are there for explanatory purposes, of course. They explain the basics, so let’s look at the finer points. First of all, what was my thinking behind doing it this way? To answer that, take a quick look at the Webform Userpoints module and the available releases. I’ll wait.

OK, as you can see, this module only has a development release. However, I’ve also used this technique for modules where the development version had a feature (or even a bug fix) that I needed. The benefit of doing it this way instead of simply specifying the version as “1.x-dev” is that your site will never suddenly stop working after a Drush Make (or Aegir)-based deployment because of the latest development version having different code than you expect (i.e., new code). Git repository revisions are fixed points in time and code. You can rely on them not changing. This is a very good thing.

Finally, I thought I should include a screenshot of where to find the commit identifier. There are a couple places; let’s start with the one I used the first time:

Click the "View commits" link on a project to get here

That’s the View Commits page for Webform Userpoints. It’s accessible through the right sidebar. You usually want the latest one for the development version you need. Click on it, and then click here to skip ahead.

Sometimes, though, especially in actively-developed projects, you’ll find that there are so many commits that it’s impractical to find the revision that way.  In these cases, the Repository Viewer is the answer. To get there, click Repository Viewer on the Drupal.org project page of the module or theme with which you’re dealing, and then under the heads section, find the one that looks like the development version you wanted. This will typically be something like 6.x-1.x. Next to that, you’ll see a few links such as shortlog, log, and tree. Click log, and then click on the title of the latest commit.

With either approach, this type of page is your final destination:

Once you click a specific commit, you wind up on a page like this

The highlighted text is what you want. This will be different for you unless you’re doing this for the same revision of the same module.

Bonus developer method: Clone the repository with Git and check out the branch corresponding to the development version. Run git log and copy the full commit identifier. Stick it in the right place in the Drush Make file. You probably didn’t even need me to write all this if you’re using this method.

1 http://drupalcode.org/project/drush_make.git/blob/086793e8887008a7841a5ef6081f8cf2766347db:/README.txt#l268

How-to: Create Drupal development sites in Quickstart

Yesterday, I felt like reviewing some patches, so I fired up my Quickstart-based virtual machine and set about creating some Drupal development sites. I realized I first had to create Drush Make files to get the proper development versions installed. So I did that. However, I also realized that, despite cloning the code via Git and checking out a particular branch, the Git clone was not actually a Git repository. This is because Drush Make requires the –working-copy switch in order to do this. I’ve posted a workaround on the Quickstart issue queues. This post mostly serves as pointers to a couple things:

Feeds CSV Importer Sources: Caveat Amplificator

I had an interesting experience with Feeds and Feeds Tamper today. I wasn’t able to get a comma-separated set of words to turn into multiple tags no matter what I tried. I was using the Explode plugin that comes with Feeds Tamper and set the delimiter as a comma and the limit to 1. My research indicated this should work, but it didn’t.

There were two problems that were so counterintuitive, the urge to blog about them came over me. Disclaimer: I admit I’ve never properly read the Feeds documentation; I figured setting up a node importer based off a CSV parser would be pretty easy.

The solution is extremely simple:

When setting up your CSV importer and specifying Source column names, do not use spaces or uppercase letters. This means you need to avoid it in your CSV file as well.

That’s all! Instead of Body Text, call it body_text. What happens is that by the time Feeds Tamper receives your Feeds field, the data structure it uses to store them contains lowercase (and probably space-free) versions of whatever you had as the Source column names back in your updater. Using my tip ensures that these will be the same, and Feeds Tamper will be happy.

Have fun tampering.

P.S. The Latin in the title hopefully means, “Developer beware.”

Presentation on hooks goes primetime!

Just chiming in to express excitement about my presentation on hooks in Drupal (Why Drupal uses hooks, and why you should too) got scheduled for the largest room in the venue! Looks like I’d better be doubly prepared.

Thanks again goes to Oliver Seldman for inviting me to co-present this with him originally and for all the help with the slides and content, especially the simplicity of the presentation. Please give him your money.