Drupal Dork - Drupal Planet

Trigger a javascript event when an autocomplete field changes

Brock — Tue, 29 Jan 2013 18:49:41 +0000

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:

(function ($) {
/**
 * Puts the currently highlighted suggestion into the autocomplete field.
 * Overridden from misc/autocomplete.js to add an event trigger on autocomplete
 */
if (Drupal.jsAC) {
  Drupal.jsAC.prototype.select = function (node) {
    this.input.value = $(node).data('autocompleteValue');
    // Custom: add an event trigger
    $(this.input).trigger('autocompleteSelect', [node]);
  };
}
})(jQuery);

Note that this goes inside the (function ($) {})(jQuery); block that appears in most Drupal Javascript files. If you're pasting into an existing file that already has them, you can omit the first and last line, and paste the function in between them.

Then you just bind to that event. Here's an example for the node author field on the node add/edit form:

$('input[name=name]', context).bind('autocompleteSelect', function() {
  // Value chosen in autocomplete field.
  // Do whatever you need to do.
  var chosen_value = $(this).val();
});

NOTE: After using this code for a few days I found an error. Drupal.jsAC is not defined on all pages, so an error is thrown when trying to set values on the prototype of a non-existent object. I've updated the code above to wrap it in a condition to check for Drupal.jsAC before overriding it.

One more update, from February 19, 2013:

It turns out that the select() function only runs when you click on an item in the autocomplete dropdown. If you use the arrow keys to select and item and hit enter to select it, the hidePopup() function runs instead (by way of onkeyup()), so you need to implement that one to. This is the core version, with only the autocompleteSelect trigger added:

Drupal.jsAC.prototype.hidePopup = function (keycode) {
  // Select item if the right key or mousebutton was pressed.
  if (this.selected && ((keycode && keycode != 46 && keycode != 8 && keycode != 27) || !keycode)) {
    this.input.value = $(this.selected).data('autocompleteValue');
    // Custom: add an event trigger
    $(this.input).trigger('autocompleteSelect');
  }
  // Hide popup.
  var popup = this.popup;
  if (popup) {
    this.popup = null;
    $(popup).fadeOut('fast', function () { $(popup).remove(); });
  }
  this.selected = false;
  $(this.ariaLive).empty();
};

How to force an update of the summary on field sets (in vertical tabs)

Brock — Tue, 29 Jan 2013 18:45:22 +0000

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

The Drupal Ladder

Brock — Wed, 05 Sep 2012 00:35:39 +0000

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.

This goal is being pursued primarily through two differend kinds of events: learn sprints and issue sprints at local meetup groups. During learn sprints, attendees work through a lesson on the Drupal core contribution ladder. During issue sprints, attendees pair up and work to make some progress on a Drupal core issue. There's more to the initiative than that, but this is the important part, "where the rubber meets the road," if you will.

Over the past few weeks, a steering committee has been assembled to lead the effort and divvy up the work a bit. Before this, there really wasn't much headway being made on issues. There are a few parts that make up the DrupalLadder.org site: the Lessons module defines the lesson content type and surrounding functionality, the Lesson Ladder module organizes those lessons into sequential ladder rungs, and the Drupal Ladder install profile contains the lesson content that appears on DrupalLadder.org. The use of this install profile is two-fold: right now, it runs DrupalLadder.org, but soon it will also include sample modules and intentional bugs so that those who are working through the lessons can do so on a local dev site running the install profile. They will be able to use that site itself to make changes, create and apply patches, and so on.

With the formation of the steering committee, I am now the new issue sprint…guy? Leader? As the new Issue Sprint Whatever-I-Am, my focus will be on making it easy for people to start or continue running issue sprints with their local community. To begin with, I've freshened up our how-to for sprint leads, but I've got a lot more to do.

The core mentoring folks have graciously allowed us to make use of a new task-tracking tool that they've developed to make it easier to keep track of who is doing what during the core mentoring hours in IRC. I'm going to work with them to fix some bugs in the system, and get it ready to be rolled into an install profile. This way, we will be able to setup our own task tracking site so that I won't need to bug xjm each time a new sprint leader needs the user role that will allow them to do their thing, and things like that. All user groups who are hosting issue sprints can track their issues in one place, and ensure that sprinters don't wind up working on the same thing (thus duplicating effort).

I'm also going to try to talk to more sprint leaders and find out what is and is not working for them, and determine what I can be doing to iron out the rough patches. At this point, I don't really have any idea what this might entail. What works well in our group here in DC may not work well for a group in Oklahoma, for example, so I'm going to start from the lessons we've learned along the way but remain open to feedback from others.

I'm really excited to have more people getting involved in organizing the Ladder initative, and especially so now that we've broken the parts of the initiative into separate responsibilities. With different people focusing on different parts, I think we'll make a lot more progress than we have in taking care of the tasks in our issue queues, and the renewal of interest in the initiative will help get a few more sprints off the ground!

DrupalCon Munich

Brock — Tue, 04 Sep 2012 23:42:26 +0000

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.

Once my sleep cycle evened out and I got my legs under me, I had a great time. I wound up spending a lot of time talking with the newly-former Drupal Ladder Steering Committee about what we were doing and how, which was exactly the refresher I needed for that project. The Drupal Ladder has been my primary focus in the contrib world for a couple months, but I hadn't been very enthusiastic about it of late. Doling out responsibilities and making some decisions during DrupalCon made me feel a lot better about where we're going and how we're going to get there, so the week was worth it just for that.

I also really enjoyed the "Get Involved with Core Sprint" on Friday. This was a sprint led primarily by the core mentoring crew (meaning xjm and tim.plunkett this time around), and it went swimmingly. Cathy and I hosted a BOF on Thursday afternoon to help new sprinters get setup with a local Drupal 8 site, and it wound up being remarkably effective: a bunch of first-time sprinters arrived Friday morning all setup and ready to contribute! Fellow Lullabots Addi and Joe led a workshop in the morning to get people more completely setup: local dev site, git, how to use IRC and the issue queue, etc. Between the BOF and the workshop, the entire group was firing on all cylinders by noon.

A ton of issues were worked on, and it seemed like everyone knew what they were doing: I kept wandering the room, looking for people that needed help, but no one did! Instead, I spent most of my time looking for more issues that people could work on because the group was chugging through them so quickly.

Talking about the Ladder and helping out at the sprint were definitely the highlights of my DrupalCon. I only attended a few sessions, including the two I spoke at (Drupal Ladder and Making Meetups Work), and didn't even make it to any core conversations, but it was a very productive week. Now I need to go back and watch the videos for a bunch of sessions I missed!

It's almost time for Munich!

Brock — Mon, 06 Aug 2012 01:00:51 +0000

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.

Getting around should be…ok. I did take a year of German in college, so I know some basics, but not enough to understand the answer to any question that I might manage to ask. I know that a lot of people speak English, and I'm banking on that more than anything else. This afternoon, I finally took a close look at the (very intimidating) map of the train network, and the part I need to navigate will be pretty straightforward. The map looked way more confusing when I just gave it a once-over before, because the station names are hard to differentiate when you don't know what most of them mean.

Getting from the airport to the Westin Grand will be fine, but at the end of the week, I need to make my way closer to the middle of the city to meet my wife at the hotel whe're we'll be spending that weekend—and she needs to find her way there from the airport, without even the cursory understanding of German that I've got. Without cell phones, it will be hard to get in touch to coordinate or warn about delays. I've been trying to figure out the situation with cell phones in Germany, and I think we might be best served by a couple cheap pre-paid voice-only units, instead of trying to get an actual data plan on our iPhones.

So yes: it's all very exciting and just a little bit terrifying, but I can't wait to see everyone in Munich!

Video: Drupal is Stupid (But I Love It Anyway)

Brock — Sun, 29 Jul 2012 14:18:24 +0000

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.

Github: Creating Pull Requests for Existing Issues

Brock — Tue, 05 Jun 2012 19:39:06 +0000

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.

Let's Talk About Sex

Brock — Mon, 28 May 2012 20:59:54 +0000

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:

I have no problem with sex. Sex can be a natural, zesty enterprise, but that doesn't mean it has a place at professional events.
I believe that the mere presence of "booth babes" is actively detrimental to the gender equality of any event or the industry in which it takes place.
I do not think a dress code for booth staff or event attendees is appropriate, nor am I convinced (yet) that this is a problem that should be addressed by an official code of conduct or exhibitor agreement or anything like that.

The problem with booth babes is simple: hiring sexy ladies to stand at a booth and attract men to it results in those men assuming that beautiful women in the booths are only there to attract them.

That's it. It's not some puritanical view of sex, as was suggested to me, nor a problem with sexiness, as was suggested to others.

I don't know why this is so hard to get one's head around. Booth babes are there only to sexually arouse men³ and draw them into the booth. They cannot answer questions about the product or provide deep information about it.

Their knowledge of the company or product is not the problem, though; the problem is that everyone comes to assume that the sexy ladies in the booths are just that: sexy ladies who don't know anything about the product. Women who are actually active in the community and industry (and who already have a hard enough time being taken seriously in said) are then brushed aside by those who assume that they're just there as eye candy.

This fact was driven home for me when I was talking to a guy at DrupalCamp Maryland a few months ago. The topic came up, and he proudly announced that when he's interested in a company in an exhibit hall, he'll walk straight past any women to the nerdy-looking dude at the back of the booth, figuring that he's the guy who actually knows what he's talking about.

He could not have made my point better for me, but I still had to slowly spell it out for him: this exactly problem. The women you walk past may well be the lead developer(s) on the product, but you assume they're just there as eye candy because of the fact that booth babes are around.

This is why some of the conversation on Twitter this week infuriated me so. It's not about any puritanical view of sex. It's not about being uncomfortable with sexiness. It's entirely about further marginalizing women in an industry where gender equality is a long-standing issue that needs to be addressed. There's no way that this is hard to comprehend, nor did anyone actually answer to this point on Twitter, so I can only assume that they would rather pretend that it's not a real issue.

The closest thing I got to a real response on this was the assertion that the person I was talking to had sexy guys at his booth, and I was being sexist for assuming that "booth babes" had to mean women.

Seriously, dude?

This point—and the long conversation that followed the next day, about what constitutes appropriate behavior among people who are attracted to others at tech events—points to an incredible blind spot that plagues members of our community who refuse to see this as a problem:

There is not gender equality in our world right now.

You can argue that it's sexist to assume that "booth babes" refers to women. You can argue from the position that men and women should be treated equally, and that women can hit on men just as men can hit on women, and there's no difference between the two. I can understand why one would take this position, from a logical standpoint, but it simply has no bearing on reality. Behaving as if we have achieved gender equality—and thus, that these issues do not exist—does nothing to rectify those existing inequalities. We can't just pretend that treating everyone equally will eventually make it so; it's going to take more than that.

As I noted earlier, I don't believe that an official code of conduct is the best way to address these problems: tech events should have one in place, but it will take more than that to make a real difference, and there are issues that cannot be adequately addressed by rules and regulations. For example, I was also told I was being sexist for proposing that women at these events should be held to a dress code, to prevent the kind of outfits that booth babes might wear. To be clear, I never proposed nor inferred this, but it indicates the problem with addressing this by official means: should there be a dress code in place? Should exhibit hall staff be limited to full-time employees of each company exhibiting? How can you regulate stuff like that?

I maintain that peer pressure is going to be a much more effective solution. We need to make it clear that we will not do business with the kind of company that thinks women are only good for attracting horny geeks to their booth. We need to call out colleagues who behave inappropriately, who make sexist jokes or harass other attendees or staff at these events. We need to explain—again and again and with small words when necessary—why "booth babes" and "booth dudes" are inherently unequal.

We'd all like to believe that gender inequality is a thing of the past, but people are so willing to demonstrate, time after time, that we aren't there yet.

Intro to Github Pull Requests

Brock — Thu, 26 Apr 2012 00:43:41 +0000

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.

Module Release Announcement: Node Subpages 7.x-2.0-beta1

Brock — Sun, 22 Apr 2012 21:10:01 +0000

I've been on a bit of a CTools kick lately, and my latest experiment was Node Subpages.

Node Subpages allows site admins to configure per-content-type subpages that display the contents of a view or a field on the node. The project page has a more complete use case and example links.

I just posted the first 7.x-2.x release, which replaces the subpage content handling with CTools plugins. Previously, only Fields and Views could be used as the content of subpages, and they were the two hard-coded options. They're still the only two options, but the configuration and content for the subpages are provided by plugins. Any module can define additional plugins, though I still need to document how these plugins can be added and what they need to define. Next up, I might add Panels as subpage content, if I can figure out how to pass the node as a context.

Webform A/B Testing was the first module that I switched to use plugins, and that one actually went more smoothly. I started working on this update to Node Subpages at the airport when I was leaving Denver a month ago, but it gave me such grief that I sidelined it for a few weeks. Now, I think it's in pretty good shape but would love to get feedback from other people. I'm the only one who has tried it, so it really needs more testing before I can do a full 7.x-2.0 release. I'd also love feedback on the way I implemented the plugins: I found a few examples for building CTools plugins, and some with differing advice, so I'd be very interested to hear from others who have built modules to make use of plugins.

In any case, the next task for this project will be making the configuration exportable. If a content type is exported into a Features module, it would make sense that the subpage configuration would be included, but that's not the case right now. My plan is to use the CTools Export UI Template example module as a starting point.