How I upgraded Budts.be to Drupal7. Part1

This is the first part of a series I plan to write on how I upgraded this site to Drupal 7. I have made all the sources available on my github account, as it can serve as an example on how to do Drupal development without database dumps. These are the parts I plan to write:

• Introduction: the site and what I wanted with the upgrade
• Automation with scripts, drush and drush make
• Installing from scratch: the installation profile
• Upgrading from Drupal 6: upgrader module and update method

Introduction

Nearly 1,5 years ago I decided that I wanted to migrate my Wordpress blog and two other custom sites into a single Drupal based website. At that time Drupal 7 was not yet final (or just a few days, can't remember exactly) and was not yet really in a usable state for a regular site without too much difficulties. So I went with Drupal 6 and I decided to use the 'classic' method of Drupal development: database dumps. I figured that, since it was just for my personal site, it didn't really matter. For deployment I used rsync.

For the past year I checked the contrib-modules I had used for my site to see if they already had Drupal 7-versions. Most of them had, except the project issues module and the image gallery-module. Since it looks like those modules won't get a Drupal 7 version anytime soon and I didn't use the functionalities offered by the modules often, I finally decided to remove these parts from the site. With that out of the way, the road was open to finally upgrade to the Drupal 7 world.

Ever since I built my original Drupal 6 site, I have learned a lot more about Drupal while doing projects for customers. At Inuits we always use installation profiles and features and I have come to really like this. Just being able to drop your database and completely reinstall your site from scratch is awesome! Also, not having to do work twice, but simply (most of the time ;)) writing an update method which you can run on multiple site-instances is really cool.

So I decided that I wanted an installation profile for my site, and that I wanted it to upgrade from Drupal 6 to 7 in just a few easy, automated steps. Also, since I love Open Source, I planned to make all the sources available. I hope that it can be a good example for some people about how to do code-based Drupal development.

In short (I'll explain all the steps in more detail in the following articles), I first upgraded my Drupal 6 site using the regular Drupal update methods. After doing that the site looked horrible, because not all the views were upgraded correctly and I use a custom theme which required porting. So I ported my theme to the new 'trex7'-theme and started fixing views etc. Then I added as much as possible to features and created an installation profile.

When that was ready, I could already reinstall my site from scratch. Then I started writing a Drupal 6 module, which would do a clean up of the old site (including the deletion of over 3500 image nodes!) and prepare it to be upgraded. After that, I added update methods to the installation profile to completely upgrade the site so it ended up looking as it should.

As you could already read, all the source code for the site is now also available on my github account: https://github.com/teranex/budts.be. If you clone this repository, you will currently notice 3 branches:

• master: This is the 'stable' branch. This branch only contains 'deployable' code. Whenever I want to deploy code to the webserver, I merge from my development branch to the master branch and create a tag (release-yyyymmdd).
• drupal7: This is my current development branch. When I will port the site to Drupal 8, development for that will be on the drupal8 branch.
• drupal6: This branch is a completely unrelated branch and only contains the Drupal 6 module to prepare the old site before being upgraded, and a dummy installation profile.

Should you install the site locally (it should be as easy as drush si budts_be, or using my development scripts: drupal-install budts_be), you will notice that, compared to most typical Drupal installations, a lot more modules are disabled. This is on purpose. It is my opinion that each module which is not really necessary for production should be disabled (in production). That also means all the *_ui modules, such as field_ui, views_ui and feeds_ui. Since all development should happen locally and be exported with features, those modules only need to be enabled on development installs. To do this I use the drupal-install command, which is part of my aforementioned development scripts.