Here's a little function I wrote today because I needed to be able to turn a list of between one and three items into a string like 'apples, oranges, and pears', 'apples and pears', or just 'stairs'.

I figured I might as well handle everything in one place, and throw in the option to have an 'or' instead of an 'and'. There may be occasions you don't want the Oxford comma, but I can't think of any.


/**

I keep seeing this sort of thing in so many modules:

Am I missing something, or is this utterly pointless?

This article is a tweaked version of several tutorials around. Many of the original links courtesy of Adrian Simmons. Thanks to all the others who gave me loads of help in IRC and thanks to Jerad at Lullabot for inspiring me to dive in to Git with this article.

This post was going to be longer, but I just lost the entire completed document because the worst (and probably most expensive at $15/day, yes DAY) mobile Internet provider in the world, EVER, just dropped my connection mid-submission and for the zillionth time today. So you'll have to make do with an angry and hurried synopsis of what I would've written.

I'm not a fan of repeating myself, or of doing the same work twice. So when I first got a look at FieldAPI back at DrupalCon Paris, my thought after 'Wow this is going to change everything,' was 'Every module that converts its custom data storage to this is going to be doing the same work, over and over'.

This is a quick post while it's fresh in my head, regarding porting your contributed modules to the Drupal 7 API. This post specifically focusses on database manipulation and provides the like-for-like changes. If anything here is wrong, or could be done better, please let me know!

First up, individual results:

I'm an experienced Drupal developer. I've been embedding stuff in code for ages now. Views, Panel pages, ImageCache presets, even putting CCK content type exports in to hook_install() implementations just to try to keep stuff in code. Many of you are probably in the same boat. Keeping stuff in the database brings all sorts of ugly deployment and performance issues, so we avoid like the proverbial plague.

Today I found an article about password usability, which suggested that showing users what they type for their passwords is an improvement to usability.

You can try a working demo, which adds a 'show password' checkbox.

This had me wondering whether this is a feature we should consider having in Drupal.

We have just finished a migration job for a client of ours from an old .Net system in to Drupal, the last task of which was to write some Apache mod_rewrite conditions and rules to deal with the URLs of their old website. This proved to be more trouble than I thought, mainly because I struggled to find examples of how this might work.

Firstly, the ground work. The URL pattern to be redirected looked like this:

Basically, an initial patch went in, we opened followup issues for cleanup, the followup issues never got followed up, so what's in HEAD is a bit of a mess. — catch, in a recent issue comment

This happens far too often. I'm not linking to the specific issue in the Drupal 7 queue because I don't want to point fingers; this suffices to exemplify my point.