Here at EchoDitto, we've been making heavy use of the Display Suite module. It obliterates a lot of the more tedious theming issues we typically run into when building out a Drupal site, and for the most part, we 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 we've experienced so far is the lack of formatters.

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.

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.

I'm building some maps for a client using the GMap module and came across the following simple problem: using a GMap macro, how do you remove a default attribute?

The GMap module lets you set a number of default attributes for your maps: width, height, center position, initial zoom, and so on. If you want to change any of the default settings for a given map, you need to specify your overrides in a GMap macro, which looks something like this:

[gmap zoom=3| width=500px |height=350px]

It's all simple enough until you get to the behaviors.

Today I learned that if you have a Views-powered block that uses CCK fields; and the CCK fields are empty for all the returned rows; then Views doesn't realize you've got an empty set and it still prints all the scaffolding for your block – the admin links, the container divs, and so on. The content of the block is empty, but the HTML still takes up space and throws off your layout.

Fixing this is easy. To prevent an empty CCK field-based Views-powered block from being output, add a filter on the CCK field and set the filter to Is not empty (NOT NULL).

While Dries' keynote touched on a number of topics -- from the scalability of Drupal to individual shout-outs to the top 30 core contributors -- the bulk of the talk focused on the roadmap for Drupal 8. Here's a quick rundown of what we can look forward to in the next release of Drupal:

• Drupal to any device, particularly mobile ones. If you look at the prevalence of net-connected computing devices in 2011, desktops are a minor, stagnant sector, whereas mobile devices -- anything from a smartphone, to a laptop, to a TV -- are more numerous, and their numbers are increasing.

While working on a recent project involving an embeddable JavaScript widget, I discovered a lot of useful techniques for creating widgets and for working with JavaScript in general. One of the latter is to use Douglas Crockford's JSLint to syntax- and quality-check your code.

Without a tool like JSLint, the only way to really check your code for syntax errors is to run it in every browser you plan to support.

Today I discovered that the 6.x version of drupal_write_record() returns '2' (or SAVED_UPDATED) even if no record was updated.

In order to update a record via drupal_write_record(), you have to provide both:

a) the primary key value for the record you're updating
b) the field name of the primary key or keys (e.g., 'nid')

I'm not really sure why b) is necessary, since Drupal should be able to get that information from Schema, and a prerequisite for using drupal_write_record() in the first place is that the table you're writing to was defined with Schema.

Anyway, an example:

This weekend I discovered (quite by accident) a very simple way to enable shared sign-on across multiple Drupal sites running in a multisite configuration.

Suppose you have the following sites:

• phones.com
• htc.phones.com
• iphone.phones.com
• motorola.phones.com

The first requirement is that all the sites be running on the same domain. The examples above work — they're all subdomains of phones.com.

The second requirement is that all the sites share the same user tables.

Turns out that if you're using Context with a Zen 2.x-based subtheme, any block visibility rules you set up with Context get blown away by Zen. The reason is that both Context and Zen implement the `theme_blocks()` function, but Zen, being unaware of Context, clobbers all the work done by Context.

The solution is pretty simple: apply this patch to Zen. Note that you must be using at least Context 3.x for the patch to work; otherwise, you'll get a WSOD.

And for those who are interested, here's some background on the issue.

As of this posting, ftp.drupal.org has been down for about five hours. This is kind of a bummer, because as long as FTP is down, you can't download new modules.

Or so I thought. If you use Drush, you can easily check out the code for the latest stable release of a module from Git using the --package-handler argument:

drush dl betterselect --package-handler=git_drupalorg

As always, Drush figures out which version of the module (or theme) is the latest and grabs that for you.