I wish I had a million dollars for every hour I've spent trying to track down little nagging problems I encounter in the process of developing custom modules for my Drupal clients. Truth is I'd settle for less. Truth is, just getting past some of them is reward enough. Today's was one of those.

I keep all my error logs for each of my development sites in a folder just off my dev server's document root. On my machine that's ~/mark/Sites/_logs. I keep it there so it's easy to find and check:

1. periodically just to make sure nothing's awry
2. when I'm having some kind of problem with the way a site is behaving
3. just before deployment to production

This morning I checked it and found that the error.log for one of the sites I'm working on had grown fairly huge in too little time. I had only begun working on this site - really just laying out the framework for a new module - a few days before. Prior to that there was nothing in the error.log.

I just finished another big site update from Drupal 6 to Drupal 7. No question this one was easily the most complicated one I've done so far. The site is full of node references, theme overrides, and custom fields. These Drupal 7 migrations upgrades have so-far been fairly straightforward - just follow the step-by-step and all has worked out fairly well. Not so this one.

I'll spare you most of the gory details. Maybe when the battle fatigue wears off and the wounds scar over I'll put up a post or two about it. For now I just want to leave you with a couple of, OK looks like it's 3, things to think about (and for me to remember) when someone comes to you asking for this kind of help.

This may be entirely obvious to those of you who work with forms all the time and create tableselect form elements in Drupal, but for some reason I had a hard time with it. So if you ever get tripped up setting default selections in Drupal's tableselect form element this might help. (Or at least it will help me the next time I need it!)

The code I was working on was a simple tableselect field that shows a product, size, price, and the remaining inventory of each product's size. This last bit was key because the client for whom I was developing this module absolutley required that remaining inventory be shown to prospective buyers. He had only so many to sell; and his promise to buyers was the limited number of originals - a pretty compelling proposition.

Here's something you don't run into every day. In fact, in all your Drupal development career you might not need a function like this even once. But if your development expertise grows to the point where you're developing suites of modules you may need it often.

In my case I have a site that uses a number of custom Drupal modules to do event registrations. The module structure is such that a central module provides a framework for most of the heavy lifting that's common to all things registration: It keeps a record of who has registered for which events, how much they've paid to participate, etc. The satellite modules take care of the event-specific things like what portions of an event the participant is paying for, or what size t-shirt he/she needs. The satellite modules are entirely specific to the event.

As the number of projects I'm working on has grown so has my number of code repositories. And with each new repository comes a series of steps to initialize Git, my source code version manager of choice.

Until recently the process to set up a new repository started with creating a new folder in Finder, copying the location of that folder to my clipboard, navigating to that location in Terminal, and finally initializing the repository. That's not a lot of navigating, copy/pasting, and typing; but I figured some of that could be automated.

The solution? I used Automator to create an Applescript service to initialize a new Git repository from Finder. I fired up Automator and hacked out a few lines of Applescript: