Tag: module

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

Drupal Camp Sacramento Area 2011 Conference Report

This weekend, I attended the first DrupalCamp in the Sacramento, California area. It happened to be held in Davis, a location which worked for me.

Some of you might know that I was talking about taking Amtrak’s Coast Starlight up to the Bay Area. I indeed did. Here’s some pictures: (flickr link coming soon; I have to upload the pictures).

But as for the camp itself, it’s best to break it down into the sessions I attended and then give my overall impressions.

Day 1

As every attendee certainly did, I started off my day listening to Nate Haug (@quicksketch)’s keynote speech. He talked about the community, contributing, contributing productively, collaboration, and the care shown to community members. It was a good start. After that, I went to my first session.

10-11:30: VoIP for Drupal: Turning Drupal into a phone system

The title of this presentation had intrigued me, and I’m glad I checked it out. Adam Kalsey (@akalsey) of Tropo did a fantastic job of demonstrating the VoIP module and how command sets could be sent to phone systems using PHP code.

1:00-2:30 – Using Drupal as an Application Development Platform

This was a neat presentation as well. It was also presented by Adam Kalsey. His thesis was essentially that Drupal is an application development platform that ships with a great CMS as its default implementation. He defended this fairly, outlining many of the subsystems that I indeed deal with regularly.

2:30-4:00 – Building a Distribution using Features, Drush Make, Installation Profiles, and more

Ben Shell gave a fascinating presentation on the topic above. I found this very useful, as it cleared up some questions I had regarding the whole thing. I liked how he spoke a bit about how to get drupal.org to fully package your distribution or installation profile for download!

4:00-5:30 – Streamline your workflow with Fill PDF – fill your PDF templates with your site’s forms

Some dude who came from L.A. gave this one. I think his name was Kevin Kaland or something. Of course it was awesome; would I say otherwise? Fortunately, you don’t have to listen to me; Doug R. Wu has given a brief “str8up” account of the talk. That coupon code expires Monday, by the way.

Day 2

Morning-12 – Code sprint

Saturday ran late for some reason, and I got lost on the way back to campus, so I rolled in around 11 AM. I discovered that no organized code sprint was happening, so I worked more on adding Webform token support to Fill PDF on Drupal 7. This is completed now.

1:00-2:30 – Why Drupal uses hooks, and why you should too

I bumped into that Kevin Kaland guy again at this talk. Something about hooks in Drupal. People liked it or something. (If you blogged about this talk, can you link to it in the comments?)

2:30-4:00 – Know Where The Fire Is (Monitoring Drupal Sites)

I wrapped up my camp with Mike Hathaway’s Nagios talk. It was cool; Nagios is definitely a tool l will have to try some time, along with the Drupal Nagios module of course!

Conclusion

So ended my camp, and so began my transportational journey back…with a new sticker on my laptop!