drupal

I've been thinking a lot about how we use keyboards, especially as coders, so I ran some frequency analysis on a Drupal installation to see how often certain characters are used, with a view to optimise my keyboard. Specifically, I was looking at non-letter characters (specials and numbers). The code that does this is available as a simple drush command here.

Here are the results:

You want to test your Drupal code? We’ve learned how to do it, the hard way, through 3 years of experience with continuous integration at The Economist. And I can distill our current approach into a few short paragraphs:

We have a fun concept here that we call a “human test instance”. Anyone can create an entire copy of Economist.com, running in the cloud, on a subdomain of their choice, on a branch of their choice, with just a few clicks in Hudson. “Human testing” implies that the instance is used by a human to do manual testing, however we use a human test instance to run automated Selenium tests, and each one also effectively tests the process of running the update functions every day.

Economist developers are a big, distributed lot. At one point we had 4 teams doing development in 4 different timezones from San Francisco to London. As you might imagine, this presents some extremely interesting challenges, like source code control and maintaining communication channels between teams to reduce the amount of toe stepping and work duplication going on.

The single tool that has had the largest positive impact on code quality and general sanity has been Launchpad. We switched from Subversion to Bazaar / Launchpad in March 2010 and although we didn’t do any official metrics, I would guess we have slashed the defect rate by at least half since doing that.

Running an out-of-the-box stack like MAMP may be fine for part-time tinkerers, but if you’re writing code for a serious site you’ll quickly realise that it’s important to develop against the same version of the stack that’s running in the production environment. You’d be amazed at how many subtle bugs emerge between two minor point releases of PHP, APC, MySQL or any other of the myriad components. Catching them early is crucial, and the easiest way to do that is to use a virtualised developer environment. A good choice for Apple OSX is VMWare Fusion:

Yesterday we debugged a problem of a cookie inexplicably disappearing. It turned out that an invalid favicon.ico link was causing the issue (!). The CDN module rewrites the favicon link in the to be served from media.economist.com:

The CDN, however, wasn't configured to serve .ico files, so it was issuing a redirect to http://www.economist.com (the homepage). That caused weirdness with the favicon in general, although sometimes it would appear, presumably by magic.

When going to a channel page, the cookie would be initially set by the first set of response headers, then the favicon would load a redirect to the homepage, which immediately clears the cookie (correct behaviour). However, there are no visible side effects that anything is going wrong except an occasionally wonky favicon.

Let's just say that debugging this was... non-trivial.

So what does everyone think of my new surfboard? It's a custom 6'3" made by Clayton (site under construction) in Durban, South Africa, my home break. I took it for a test drive last week and it is a sweet board indeed! Very reasonably priced too, especially after converting British pounds into South African rand.

I'm currently based in London, but I'm planning a few surf trips to Indonesia and Western Europe in the near future. Look out for photos of Druplicon inside some sick barrels. I hope.

Use the coder module to save embarrassment!

On my last blog post, I threw out a one-line patch for a usability enhancement to the Bio module. Here's the line in question:

How many errors are there in that line? Many more than I expected, as dww very patiently pointed out to me:

Here's a small one-line usability fix for all module developers that I think will be a huge help to users.

In the early stages of a project, I'm often playing around with quite a few new modules: testing them, seeing if they meet my requirements, installing and uninstalling. After downloading a module, the sequence of steps is always the same:

1. copy to /sites/all/modules
2. enable at /admin/build/modules
3. configure all exposed settings
4. use!

However, sometimes just finding the settings page takes the longest time out of all those steps. Is it in User Management? Content Management? Logs? Who knows!

I'm going to use the example of the Bio module; not picking on the Lullabot team or Bio module maintainers, this one just happened to be the first example I thought of. :)

Bio's settings page is difficult to find, as it's not in "Site configuration" but rather in "User management". It also hides itself quite nicely using the title "User biographies" instead of "Bio settings", as one would expect. The readme.txt file doesn't mention how to find the settings page at all.

So what I had to do in this case, after becoming frustrated with searching for the settings in the menu, was pull up the source code and check out hook_menu() to see exactly where I should go.

And here's my suggestion: we're all used to seeing the "installation successful" messages (and looking out for php errors on install of course). For example, the Bio module has these:

What if this message held the link for the settings page? Then it's just one click away, instead of a potential 2 minute search to find it.

This is just one line of code in the bio_install() function:

drupal_set_message(t('You can edit Bio settings at ') . l('admin/user/bio','admin/user/bio'));

Seems like a small change, but if every module did this, it would collectively save me hours in the module evaluation stages of a project, because I find that plenty of modules seem to hide their settings and not explicitly detail them in readme.txt, requiring me to either hunt them down or open the source.

Since I talked about the Bio module, I've provided a patch in the issue queue. Hate to be a complainer that does nothing about it... :)

http://drupal.org/node/236187

If you're using the Devel module while developing with Drupal, you may have enabled the "Switch users" block which is great for troubleshooting and configuring permissions.

However, if you accidentally use it while your site is in maintenance mode (offline), then you may notice a problem: it won't let you back to the path "/user" to log in again!

The solution is to use phpMyAdmin or your database manager of choice to empty the sessions table. Then you'll be able to access /user without being redirected.