Drupal Planet

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();
}

I mentioned the Drupal Ladder initiative in my post about DrupalCon Munich, but didn't really talk about what it is. I expect that most of my non-client-work Drupal time for the forseeable future will be focused on the Ladder, so a bit of explanation is probably in order.

The Goal of the Drupal Ladder is to have 1% of the Drupal Community contributing to core by 2014. That's the short version. A very low percentage of users on drupal.org have contributed to core, and we'd like to increase that percentage so that more people are helping maintain the system that we all use on a daily basis.

DrupalCon Munich took place last week—well, last-last week, I guess—and it was pretty rad. I just got home a couple days ago, myself. My wife Erin and I figured that as long as I was in Germany already, we may as well make a trip of it, so she flew out on Friday (the sprint day of the con) and we spent the weekend in Munich, then flew up to Berlin for the following week. The whole trip was a blast, but we're talking about DrupalCon here.

If I'm being honest, the first couple days of the conference were largely lost on me. I was more jet-lagged than I thought, and I think a little bit culture-shocked by failing to understand just about everything that was being said around me. I took a year of German in college (eight years ago now), but that did remarkably little for my ability to communicate with people there.

Holy crap, can you believe that DrupalCon Munich is just two weeks away? This summer has been flying by!

I, for one, am equal parts excited and apprehensive. DrupalCons are always exciting: I get to see friends I've made over the last couple years, and always meet a ton of new people. But, at the same time, I'm a little bit worried about two things: finding my way around, and being on a panel.

I really shouldn't be nervous about the panel. I'll be speaking with Karyn Cassio, Addi Berry, and Paul Johnson about making local meetups work, in the last session slot on Wednesday. All three of them are easy to talk to, and we've got a ton of information and ideas to share.

This past weekend was the second CapitalCamp here in DC, and I wound up doing a session on Friday morning. I was one of the organizers of the event, but submitted two sessions early on (mostly to start filling up the Proposed Sessions list). When it became clear that we had a ton of great session proposals (and I was going to have my hands full all weekend), I withdrew my proposals.

But, a speaker had to cancel his session a few days before the camp, and since I had previously done this talk at the DC PHP user group back in November, I was asked if I could fill the slot by doing it again. I think it worked out well: I've been asked by a lot of people who couldn't make it back in November if there was a video available, but at the time, I didn't really know how to use Keynote and failed to record it. This open timeslot gave me a chance to record a video, and to update some of the content of the talk.

In any case, I think it went pretty well. The audio peters out near the end: the Q&A became more of a discussion, which was great at the time but didn't get picked up by the mic.

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.

As it often is, sexism in the tech industry was the topic of a lot of back-and-forth on Twitter this past week. It started with the revelation¹ that a modeling agency in Denver had been contracted to staff "booth babes" in the DrupalCon exhibit hall back in March, and continued (as it so often does) with debate over what behavior is appropriate at professional-ish industry events like DrupalCon.

The issue of "booth babes"² is the one that got under my skin the most, so let's talk about that. First, allow me outline my basic position on the issue:

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.

From Inexperienced Drupal Developer:

I've recently noticed there are a ton of local Drupal jobs looking for experienced developers, and also a ton of awesome, but inexperienced developers looking for jobs. This seems like a problem. If people can't get experience in jobs, they can't get jobs that need experience. I'm hoping to help solve this problem by posting the job I've never seen. I'm seeking an inexperienced Drupal developer.

This is a FANTASTIC idea. We all know that the Drupal world needs more developers: every shop in every town is hiring. Scott's approach is a great way to get someone started off, and I'll bet that he's received a torrent of email already.

Last night, a handful of us in DC got together to discuss bringing the Boston Initiative to DC. My notes are on the DC group, with links to lots of additional info for those unfamiliar with the project.

I expected a pretty quick planning meeting: how often can we do sprints, where can we hold them, who wants to help organize them, etc. Instead, we quickly got off on a tangent about the merits of LearnDrupal.org and concerns about the content, how it's structured, and whether it's just duplicating existing training materials.

I was a bit frustrated by the way it went, but after sleeping on it, I'm really happy it did.

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.

I don't even know where to begin. This is the best I've come up with:

DrupalCon Denver was a roaring success.

This was my second DrupalCon, and I had even spent a week in the Colorado Convention Center a few years ago. I had a pretty good idea what to expect, and it did not disappoint.

I'm still in Denver and still deeply in recovery mode, so I can't muster much of a recap beyond bullet points, but I think that'll do. The links to sessions even include videos.

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 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:

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:

This week, I've learning a thing or two about Drupal search indexing. On the search settings page (admin/settings/search) for a client's site, the percentage of the site that had been indexed remained really low, even after running cron a few times. The search functionality still seemed to be working though, so I knew something weird was going on.

What I found was that the search_dataset table had well over a million records in it, so indexing was definitely happening. After checking the code used to calculate the percentage shown in the admin, I found that it only checks published nodes when determining how much content has been indexed - but, the node module chooses from all nodes when choosig a batch to index during a cron run. Since this site had about a thousand published nodes and over 100,000 unpublished nodes (the reason for that is a different story altogether), thousands of the unpublished nodes had been indexed, but not many of the published nodes had.