How-To

Related to my fieldset summary problem: autocomplete fields do not trigger the change event in Javascript, for some reason. I wound up stealing part of a patch I found somewhere (I would link to it if I could find it in my browser history) in order to override the autocomplete prototype function and trigger a new autocompleteSelect event when the user chooses an item in an autocomplete field. Just drop this function into a Javascript file in your module or theme:

Please excuse the long title: it took me a while to figure this one out, so I want to make sure that other people can find this when they need it.

On my current project, I'm changing the node author field based on the value of a user reference field on the node type: when a content admin sets the node reference field, the node author field is changed to match that user reference field value. Since the author field is shown in a fieldset, I wanted the summary on that fieldset to update when this change was made. It took me a while to figure out how, but it's pretty simple:

// Update the field summary if vertical tabs are in use
var tab = $('fieldset.node-form-author', context).data('verticalTab');
if (tab) {
  tab.updateSummary();
}

Did a quick screencast with some coworkers today on the latest thing I love about Github. Last time, I covered how to create pull requests. This time, I explain how to create a pull request out of an existing issue. Since pull requests are basically just issues with commits attached, it's often undesirable to create a new pull request to address something reported in an existing issue, because you just wind up with two issues that address the same thing.

There isn't a way to do this through the Github interface, but the hub command line tool adds some special sauce for working with Github, and the thing I use it for most is opening pull requests for issues.

The quality is crummy, so turn up the quality to 480p.

If your company is hosting code in Github, I sure hope you aren't committing directly to master. This quick screencast demonstrates how to use pull requests so that teammates can review code before it gets merged into the master branch.

Make sure you turn on HD so that the text is legible.

This is probably the third time I've fixed this problem, so it seemed time to write down the solution.

On my personal sites, I make use of one my own modules, QuickPost Bookmarklet. The module geenrates a bookmarklet that allows you highlight text on a page and begin a new blog post on your own site from it.

My sites are hosted on a Dreamhost VPS, and once in a while, this bookmarklet stops working on me: if I select a longer piece of text, it won't pre-fill the body text area on the node add form. The title value still works, but not the body, suggesting that the server was ignoring (rather than truncating) that query value if it's too long.

The problem lies with Suhosin, which is enabled (I think?) by default. The offending setting is suhosin.get.max_value_length, which keeps getting set back to 512. I'm not exactly sure how it works, because I found that the values in the query string actually stopped working somewhere around 700 characters, but no matter.

There's a long-running bug in the Drupal issue queue about a bug that I had to work around this week: when using the Batch API, your site theme will only be used for the first page. As the page reloads to show the progress of the job, the ugly, default Garland theme is used (well, that's not entirely true: it's actually Minnelli, but looks like Garland).

In most cases, this isn't a big deal: during a site install or when running update.php, it doesn't really matter what theme the admins see. In one client's case, though, we're using the Batch API to show progress of a multi-part donation that may take some time to process. In that case, you don't want regular site visitors seeing Minnelli: it's a jarring transition away from the site theme, and to anyone who isn't a seasoned Drupal user, it probably looks like something broke.

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:

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:

Sometime over the past few weeks, Drush stopped working for me. I could run drush st just fine, but anything that actually touched the database (like drush cc or drush up) gave me the dreaded "Drush was not able to start (bootstrap) the Drupal database" error. And since I'm always tweaking and changing settings on my system, I had no idea what I had done to break it.

My first thought was that I had killed it with Homebrew. I recently nuked my manual install of Drush so I could use Homebrew to update it every now and then. Once you install Homebrew, you can have Drush installed and configured really easily: brew install drush The same command will update it, too. But that wasn't the problem.

(Originally posted on BrockBoland.com.)

On one of my current projects, I'm using Display Suite to layout various node displays. This is only the second time I've used DS and I haven't needed to get too deep into it, but so far, I'm finding it to be a lot quicker than coding different versions of node.tpl.php - and it allows the site admins who will maintain the site to modify things without getting into the code, something I talked about last week. Panels is another very popular option for things like this, but the one time I used it, I wasn't too impressed; for whatever reason, it just didn't click for me.