Why You Should Spend the Extra Time to Write Drupal Update Scripts

Drupal update scripts are a great way of automating database updates. They are extremely important to contributed modules when changing the database schema and updating existing data to the new schema. Specifically I will be discussing using update scripts in your custom modules as part of deploying new features. I'm not saying update scripts should replace using the Features module, in fact I use them together, update scripts are great for things that might not be managed in features. This will be the first in a two-part series that will cover using Drupal update scripts.

  1. Why you should write them
  2. Real examples of how to write them

Arguments Against Update Scripts

First off, the top complaints I've seen about having to write update scripts are:

  • It takes longer to write the script then it does to do it manually in the browser
  • There isn't an easy way to do X
  • Learn to do it later, just want to get this done

Why You Should Write Update Scripts

Writing Update Scripts Improves Quality

It takes longer to write the script then it does to do it manually in the browser
This argument is actually true, but I'll tell you why it doesn't matter.

  • By doing it manually in the browser, you risk missing a critical step. This leads to you having to spend more time debugging the issue later.
  • Hopefully you have a deployment process for staging changes for approval before deploying them to the live site; without an update script now you have to perform those changes manually twice, doubling (or tripling if you have more then 2 stages) your time.
  • Spending the extra time to write an update script allows you to automate those changes, which allows you to test the update script in development and perform quality assurance, which makes everybody more confident and stress-free when deploying those changes to production.

Writing Update Scripts is a Learning Tool

There isn't an easy way to do X
There are some things that aren't as simple as calling a function or two, and sometimes require you to call some internal functions or writing a helper function. This shouldn't be an excuse not to write update scripts. While I've been developing website for a lot longer, I'm still fairly new to Drupal. I attribute my fast growth in Drupal to 1) my amazing co-workers and 2) writing update scripts. Writing update scripts forces you to learn some of the Drupal internals, which helps you learn and retain that knowledge. Between Google and the Drupal API site you can learn of better and easier ways of doing things.

Learn to do it later, just want to get this done
I heard the "do it quick-and-dirty now and go back and do it right later" excuse a lot at my previous job. Not only does "later" never happen, but it was a real drain to my motivation and job satisfaction. Most people like to take pride in their work and in doing a good job, and I don't think anybody can describe 'quick-and-dirty' as doing a good job. Metal Toad holds high standards for quality, and so it is much easier to get the time to do things the right way. Obviously there are some times when you need to get something done to meet a deadline or fix a critical issue, but the bottom line is don't push it off. In fact, I would say that if you have to do something that is less then ideal to meet a deadline, you should do that and immediately schedule time to look into a more ideal solution.

For Next Time

In my next post I will give real examples of update scripts I've used in projects. Is there something you needed to do, but didn't know how to do in an update script? Let me know and I will try and include it in my next post of examples.


Can you detail how you manage to deploy modifications to cck/fields ?
What about modifications to the content or taxonomy ?
Thanks a lot for these insightful posts.

I'd love to give examples of these. What kinds of modifications are you thinking? For cck/fields, would this be if you aren't using Features?

I can think of one scenario when you are using Features and if you were to change a cck/field's type or allowed values you won't be allowed to if there is already data for that field. In that case I would do one of two things;
1) create a new field with the new allowed values, remove the old field and create an update script to move and convert data from the old field to the new field.
2) do two deploys, the first would convert the data with the disallowed values to the new value, the second would deploy the change to the Feature.

I'll try to write and test some examples of both before my next post.

Nice write up. Being freelance (and most of my clients sole traders) I often ask myself whether to tell a client 'you have a choice between quick and dirty (but works), and a high professional standard.' Probably at Metal Toad you have clients who can afford quality. Not to disagree with anything in your post, only to add that there is a commercial dimension for a small player, as well as values like the job satisfaction and personal learning, and the safety net of some redundancy in working methods.

It is like the question, "how much testing should I ask the client to pay for?"

BTW your "Metal Toad holds high standards for quality" link is broken. Easy enough to find the page though, and it is an admirable document.

I definitely agree that there is a market that is less likely to be willing to pay for this extra time. I'd still advocate writing update scripts even for your own benefit and peace-of-mind. Eventually you will be able to write 90% of your update scripts almost as fast as it would take to do it in the browser 1-2 times (which if you have a local dev, remote staging and production environments you effectively cut 1/3 off your time). That being said, there are still certain circumstances that may require manual updates.

Also, thanks for letting me know about the broken link, should be fixed now.

I wanted to add, the more complex the updates you're performing, the more reward comes out of using update scripts. For incredibly complicated sites, completely testing the updates is absolutely mandatory. Then, deploying the updates to production becomes a fun, and stress-free operation. ;-) You know you've run through practice deployments against your testing environment (using a clone of the production database), and are certain the right steps are going to happen, in the right order.

Also, it's just way cooler to run "drush updatedb" on the command line than to use the old janky UI. :-D

Add new comment

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • You can enable syntax highlighting of source code with the following tags: <code>, <blockcode>, <cpp>, <java>, <php>. The supported tag styles are: <foo>, [foo].
  • Web page addresses and email addresses turn into links automatically.
  • Lines and paragraphs break automatically.

Ready for transformation?