Skip to main content


Restrict nodequeue by field values

File under

A couple of times now I’ve wanted to restrict what can go into a nodequeue by more than just the node type. A good example of when you might want to do this (though not my use case) is if you want to restrict the blog posts that can go into a carousel to only those posts that have an image. In any case, there are three steps to putting your restriction in place:

  1. Apply greggadson’s nodequeue patch:

Short-circuit Evaluation in JavaScript (or, the Ternary Operator, in Binary)

Here’s a peculiar-looking JavaScript construction that I’ve repeatedly come across in the wild:

var data = data || {};

I first came across this syntax in Drupal. For example, here’s the the first line of ajax.js:

Drupal.ajax = Drupal.ajax || {};

Setting the Default Value for Views Exposed Filters

File under

Sometimes the help you’re looking for is in the unlikeliest of places, which, in this case, is – ironically – the likeliest of places. And yes, that is all proper punctuation and grammar.

Needing to know how to set the default value for an exposed filter in Views (there’s no way to do this via the UI that I can find), a Google search turned up the Views API docs. MIND = BLOWN.

Hacking the Google Doodle for Fun and Profit, Minus the Profit

File under

Like many of my friends (especially my running friends), I’ve gotten a little caught up in Olympic fever this week. Also like many of my friends, I have zero chance of ever making it into the Olympics. But a few days ago, Google released a game that gave all us pathetic slobs a chance to feel what it’s like to take home the gold: The Google Doodle Hurdle Game.

Creating a Rules event for unblocking a user

File under

Oddly enough, the extremely useful Rules module doesn’t come with an event for unblocking a user. Thankfully, implementing a custom event for this occurrence is really easy. There’s two basic steps:

Creating Custom Formatters with Display Suite (and Why You Should Bother)

File under

I’ve been making heavy use of the [Display Suite][ds] module lately. It obliterates a lot of the more tedious theming issues I typically run into when building out a Drupal site, and for the most part, I love it. But as with any solution that takes logic out of code and puts it into the UI, if you want to do anything that isn’t already provided by DS, you’re going to have a write a bunch of code.

So far, the biggest drawback to using DS that I’ve experienced so far is the lack of formatters. For example, suppose you have something like an Action content type with the following fields:

Video Thumbnails with Media and YouTube or Vimeo in Drupal 7

File under

Today, one of the designers I work with asked me a pretty simple question about a Views-based list of videos. The listing displays thumbnails of videos being pulled from YouTube and Viemo. The question was: how do I change the size of the thumbnails?

It’s easy enough to change the size of images, but the process gets fairly confusing when it comes to other content types. Here’s a quick breakdown of the steps I took to enable video thumbnail resizing:

  1. Create an image style.
  2. Set the effect you want on the image style.
  3. Create a file style.

Targeting Firefox while using LESS.css

File under

The most common CSS hack to target Firefox is to put something like this in your stylesheet:

@-moz-document url-prefix() { h1 { color: red; } }

But if you’re using LESS.css, this is a problem, because LESS uses the ‘at’ symbol (@) for variables. When LESS parses the above declaration, since @-moz-document isn’t a variable, you get an error.

Thankfully there are other easy ways to target Firefox in CSS that allow us to continue using LESS. For instance:

body:not(:-moz-handler-blocked) #your-target-element { 
  color: red;

Restore Deleted Fields in Drupal 7

File under

In D7, if you delete a field from a content type, the field data stays in the database. And yet if you later add that same field back to that same content type, the data does not reappear. Zuh?

It’s the new deleted field in each field_data_<field_name> table that governs this behavior. So if you accidentally delete a field and want that data back, just change the deleted field from 1 to 0.

Kinda cool I guess, though it sort of reminds me of the trash can in WordPress. As far as I can tell, though, there’s no UI for adding back deleted fields.

Mixing Context and Drupal's Native Block Ordering System

File under

I work on a lot of legacy sites that were built without the Context module, and I would say that at least once on each of these legacy sites, I turn to Context when I have a very specific problem: the visibility settings for a particular block are so complex that (in Drupal 6 at least) they can only be expressed by writing code. For instance: suppose you’re using Organic Groups, and you want to show or hide a block based on whether the user is a member of that group.

Syndicate content