Drupal Dork

During the BarCamp-style afternoon session at DrupalCamp MD last weekend, some people got talking about the tools they use on a daily basis, including one of my favorites: Alfred, a launcher app that's comparable to Quicksilver or LaunchBar. I have several Drupal-specific custom searches setup in Alfred, and I've been meaning to write about them for the benefit of other Drupal devs on Macs.

To add custom searches, open the Alfred preferences and go to the Features tab, then select Custom Searches in the list at left. Click the plus icon at the bottom of the window to add a new one. You'll be asked to provide some info for the search, including the keyword to use—the command you'll type into the Alfred window—and the URL that the search should go to. You'll put {query} in the URL where the search string should go.

Benjamin Keen has created a fantastic, customizable bookmarklet that, when clicked, will show the page you're viewing in multiple screen sizes. This makes it easy to check a responsive design in multiple screen sizes as a glance. Very handy, and very simple execution.

Quick follow-up on my post about local settings file template: colleague Ben Clark forked my gist and added all sorts of good stuff that I hadn't considered. Thanks Ben!

A couple months ago, I wrote about our strategy of using local settings files here at Jackson River.

I was setting up a new development site on my machine the other day, and realized that I've been consulting that blog post a couple times a week to copy over bits of code that were missing from various dev sites. It seemed like a good idea to move it into a gist:

Today was my second Day of Personal Enrichment at Jackson River. DOPE days are sort of like Google's 20% time, where employees are encouraged to work on projects that interest them. We don't have the luxury of doing it one day a week, but we do spend a solid day on these projects when we can fit it in the schedule. I wrote about the first one back in May, when I did some work on the Simplenews Threaded Send module.

Today I'd like to share a technique that we use on every site at Jackson River.

For most projects, we have multiple developers working on different aspects of the site, and each of us has our own local development setup and checkout of the git repository. The problem we ran into, as any Drupal shop will, is the site configuration details included in settings.php, and the way that those need to differ on our various development, staging, and production sites.

On some early sites, we used a switch statement in settings.php that would check the requested URL, and set variables like $db_url depending on that. When a new developer joined the project, they would add a new condition to the settings for whatever URL they were using (we each had our own local naming scheme, whether it was jacksonriver.com, jacksonriver.local, jr.dev, jrdev.local, and so on).

This was a terrible solution, and we stopped using it a long time ago. Instead, on every site we build, the settings file ends with an include:

Updated January 6, 2012: Since writing this post, I have wrapped this functionality up into the QuickPost Bookmarklet module for Drupal 7.

There was only one thing I missed after switching from WordPress to Drupal: the "Press This" bookmarklet that's available on every WordPress site. I find that I post a lot less without it, just because it made it so simple to make a quick blog post about someting I had seen online: highlight some text, click the bookmarklet, add some comments, and post.

I've finally got around to replicating this in Drupal 7, using the Prepopulate module, and I'm posting this so that others can make use of it. I'll start with the most basic version, then show you how I customized mine, and explain some gotchas to watch out for.

On my machine, I have two local sites I use for developing and testing modules and patches: http://d6.local and http://d7.local. After manually wiping and re-creating these sites several times in between some tests, I realized I was doing it wrong and wrote bash scripts to do it for me.

Now, I have templates for each of these sites. Whenever I want to start with a fresh dev site with some basic modules installed (like Admin Menu, Admin Role, and Devel), I run a quick bash script that drops and re-creates the database, imports a SQL file, and replaces the entire webroot directory with the contents of a tarball. I did have to manually setup the site, create my admin user, and enable the modules when I first set all this up. Now, I can easily update that template when I need to - for example, when there's a new versions of the Drupal core released.

Here's my setup:

tl;dr: Page Not Found Reports module released.

A couple weeks ago, I launched a client site that was dealing with a lot of 404 errors. This put unnecessary load on the server: Boost will serve up cached versions of most pages, but for paths that haven't been cached yet, Drupal needs to process it and determine if there's a page available to serve up. In this case, the client overlooked a couple directories of images and other static files that should have been migrated from their old site, so they were getting a lot of 404s from off-site uses of those images. Some were other sites that were hot-linking to the client's images (impolite, but not verboten), but others were being used in their own mailing lists and other sites that they maintained.

To make it easier to identify what files and pages may have missed out on the migration, I built Page Not Found Reports. This adds three new reports:

I've been meaning to write something up about these for a while, because they have made my development flow so much better.

Tab completion

Arguably, the best thing about git is lightweight branches. But, I had been resisting using them, because it was a pain in the neck to keep track of them and re-type or copy-pasta the name for every checkout or merge. I rely heavily on tab completion in the command line, because I know I'll mistype things otherwise, and spend way too much time trying to figure out why something is broke later on - for example, after mistyping the target of a symlink.

As it turns out, git ships with a script to handle tab completion: you just need to find and enable it.

Since I use Homebrew to install and update packages (Mac users: you should too), my git executable is in /usr/local/Cellar/git/1.7.3.4/bin. You need to find git-completion.bash. In my case, it's in a sibling directory: /usr/local/Cellar/git/1.7.3.4/etc/bash_completion.d/git-completion.bash.