Mark's blog

I had a recent inquiry about the event registration system I wrote for a client in Drupal. The inquirer wanted the code, but unfortunately I'm not able to release the code because of the license covering it.

What I was able to do however, was to outline the workflow process for the system. It's really very simple, and I think shouldn't be really difficult for anyone to replicate.

First and foremost the event registration workflow does not register anyone to the Drupal site. The client insisted that users do not need to register as users for the Drupal site. In truth, we are already collecting enough information during the sign-up process that we could create accounts. But that wasn't an objective. Maybe in a future enhancement? Time will tell.

So at a very high level the event registration process is as simple as this:

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.