So rocktreesky is finally running on Drupal 7. I upgraded the site a few weeks ago and thought I’d share my experience. This is a very simple blog site so my upgrade process was fairly simple and easier than it would be for almost any other site out there, although the overall approach is going to be the same with most sites. I got the site upgraded in a weekend, but even as stripped down as this site is, I had to drop features to complete the upgrade. On the flip side, Drupal 7 provided a bunch of little niceties that meant I could remove some custom code from my theme (and overall I really like theming with Drupal 7). Overall, the upgrade was pretty painless for me, but I wouldn’t recommend firing up an upgrade for most sites right now, unless you have the time and resources to put some muscle into it. I’ll walk through my process and some decisions I made to see why I come to this conclusion.
The site was running a relatively recent version of Drupal 6 (6.17) and had the following contributed modules:
- Codefilter
- Comment mail
- Feedburner
- Mollom
- Pathauto
- Read More Link
- Tagadelic
- Token
- Views
You’ll notice that I’m not using CCK, so that whole process of upgrading my fields was skipped. That’s the beauty of a simple site, though chances are that almost all sites will need that step. I wasn’t joking when I said very simple. I also have one small custom tweaks module and my custom theme, which obviously required some manual upgrading from me. One other feature to note is that I was also using the Drupal 6 core Blog API module. This was removed in Drupal 7.
Evaluating the situation
I started out by reviewing my list and making notes on what was ready for upgrade, what might need coaxing, and what was just not going to work. I ended up with a list of notes like this:
- Codefilter
- A stable Drupal 7 release (7.x-1.0) is available. Yay!
- Comment Mail
- No Drupal 7 release, but I also don’t really need this module. I decided to drop it and just use core Actions and Triggers to send email when someone comments on the site.
- Feedburner
- No Drupal 7 version. Someone has a straight-port patch in the issue queue, but the maintainer wants to do a rewrite, so nothing really happening there yet. I don’t care enough about Feedburner to deal with running on a patched version, so I decided to drop it from my features.
- Mollom
- Not surprisingly, this has a stable Drupal 7 release (7.x-1.0). Woohoo!
- Pathauto
- There is a Drupal 7 beta (7.x-1.0-beta1) for this one. I’m comfortable with betas so I went ahead and added it to the list. This would be an upgrade deal-breaker, so I’m glad this one was ready.
- Read More Link
- The version I was using in Drupal 6 (ed_readmore) has been deprecated in Drupal 7 for a new Read More Link module (read_more). The new version has a Drupal 7 dev release. I played with it and it didn’t blow up, so I added it to the upgrade list.
- Tagadelic
- So this one was a little funky. There is a Drupal 7 dev version listed on the project page, but if you look at the code for it, that is still Drupal 6. The maintainer put the newer code on Github a while back, before the Drupal.org Git migration, and hasn’t gotten the code moved back in to D.o apparently. I don’t need the tag cloud, but I do really like it. I ended up deciding to just grab a tarball of the code that is on Github for now, since it works for my needs. I’ll keep an eye on the official D.o code whenever I’m doing other module updates and hopefully I’ll be able to switch to a D.o version of the module for Drupal 7.
- Token
- There is a beta (7.x-1.0-beta2) out for this. I need token for Pathauto, so this would have been another one of those deal-breaker modules for me.
- There is no Drupal 7 release for Twitter. There is an issue in the queue where someone is working in a sandbox, but I really didn’t want to start messing around with this. I use Twitter for displaying my list of recent tweets. I used to use it to auto-tweet my posts, but I’ve taken to manually doing that anyway since I didn’t have the time or interest to figure out how to get bit.ly URL shortener integrated. So, I dropped this feature from the site and just inserted a Twitter widget in a custom block to display tweets.
- Views
- There is a beta (7.x-3.0-beta3) out for Views and it is definitely stable enough to build with. I could get by on my site without it for a little while, but I like my homepage view so happy to see the new Views (and its new UI, which fricking rocks!).
- Blog API
- This was in core on Drupal 6, but got removed in Drupal 7. There is a new contributed project for it, but it has a big fat warning on the project page saying that it doesn’t work and the maintainer doesn’t have time to mess with it. Discouraging to say the least, since I use this functionality every time I write a post. I really like writing a post in my desktop app (I use Ecto), often over a period of time, and then publishing it from the app. The contributed module is not in a usable state though and I really don’t want to try to fix it myself. Sadly, my upgrade to Drupal 7 means I have to drop Blog API. This is my most missed feature from upgrading to Drupal 7 and I feel like it is a real shame that it got kicked out of core.
Local testing
So at the end of the day, I ended up dropping Comment Mail, Feedburner, Twitter and Blog API as features on the site. For my small site I had to drop over one third of my features! 😛 I’m also running some dev code on the site, but I tested it out and feel comfortable enough with the current state that I was willing to use them for the features I wanted. The betas don’t scare me at all, and I often run beta code without batting an eye, so I’m as happy with a beta as a stable release. I tested everything on a vanilla Drupal 7 site to assess that they were basically working, so I feel good about the list I’m working with now.
Once all of the evaluation was done, it was time to begin the upgrade itself. I got a copy of my live database, tucked away a copy of my entire sites folder, created a new branch in my git repo for the D7 code, and got started. I set everything up on my localhost with the Drupal 6 code and database so I could test everything thoroughly. I uninstalled the modules I was getting rid of, disabled all the contributed modules and set my theme back to Garland. I switched my code to the D7 branch, deleted all of the files in my Drupal root and put a fresh copy of Drupal 7 in its place. I then needed to create my settings.php file since I already have an existing database (this isn’t a fresh installation). The syntax for the database connection is different in Drupal 7 so I copied the example in the documentation and put my db info in the right way. Finally I also copied in my site files folder.
With the new Drupal 7 core code in place and wired to my database (still on Drupal 6), I went to the site in my browser. It gave me a lovely white screen, but I just went ahead to the update script (http://example.com/update.php) and ran my updates. My core upgrade went very smoothly and I had a local copy of my site running Drupal 7. I then added each contributed module one by one, running update.php for each and enabling it. I’d click around the site and make notes about what manual configuration steps I needed to take to get the site back to how it used to be (I also needed to apply a patch for Views to upgrade properly so I made sure to add that patch to my git repo and add the link to the D.o issue in my notes). I also made notes of new things I wanted to do in Drupal 7, like enabling some new core modules (Dashboard and Toolbar) and setting the admin theme to Seven.
Updating custom code
I now had my site running on Drupal 7 with all of the contributed modules I was going for and using Garland for the theme. Now I needed to look at my custom code. Almost all of my custom code is in my theme but I also have my small tweaks module. I copied the module and theme into my site directory and got to work.
The tweaks module only had two little bits in it. One part was a tweak using the Twitter module, which I wasn’t using anymore so I just ripped all of that out. The other part was a simple hook_form_alter() to remove the website field on the comment form. I needed to tweak that code a bit to get the proper form ID and field in D7 since things changed a bit. That and changing the version in the .info file to 7 and I was done.
The theme required a bit more work and I didn’t take notes on everything I did to be able to give a blow by blow account, but the two main tasks were reviewing all of the template files (tpl.php) and updating my code in template.php. On Drupalize.me we have a great video from Joe going over all of the changes in Drupal 7 theming (behind a paywall). I immediately went the Upgrading themes chapter where he reviews the big gotchas. It was a big help to run through that first. Upgrading the theme was a lot less painful than I thought it would be and I actually got to remove a bunch of code from my template.php file since some of the things I was doing were just built in to core now (e.g. adding a class to comments that indicates if the comment is by the node author). I trimmed my template.php file from 146 lines in Drupal 6 to only 63 lines in Drupal 7. I also had to carefully review my template files since there are quite a lot of changes in Drupal 7 and I wanted to make sure I got them all in there. I basically opened up my custom template and the equivalent core default template side by side and copy/pasted new things I wanted, like all the new, spiffy RDF stuff around titles. I also needed to create my HTML template file, which is new in Drupal 7. Getting the theme upgraded took a bit of time and testing but after a few hours of tinkering off and on, I had a fully functional custom Drupal 7 theme. With that done and all of my new code committed to git, I was finally ready to upgrade for realz.
Upgrade time
I tidied up my notes and ran through the entire upgrade process on my local test site to make sure I had all the pieces and it would work in one fell swoop. Once I was comfortable with the process and that things were working properly, I went to the live site. Here are my notes that I’d prepared:
- Backup DB
- Log in as User 1
- Take site offline
- Disable all contrib/custom modules
- Change default theme to Garland
- Switch to the new code (git co d7)
- Run update.php
- Read the update messages (I needed to move some blocks into correct regions)
- Enable new core modules I want (Contextual links, Dashboard, Toolbar – don’t use the Overlay)
- Set seven theme for admin
- Make rts theme default theme
- Create new block for Twitter widget
- Set blocks properly
- Tweak content types (manage field order, manage display – tags in particular are now fields so need some tweaking)
- Enable contrib/custom modules one at a time, and take care of the settings:
- Change frontpage to the frontpage view
- Set up comment email notification
- Update cron to use new cron URL
- Put site back online
Conclusion
After taking the time to do the prep, the live site upgrade went smoothly and took less than an hour, including lots of clicking around. I’m really glad I upgraded, although losing Blog API did hurt a bit. Drupal 7 is a real joy to work with. It is obvious though that it will still take a while for everything to catch up and be ready for upgrades. That’s typical and I think Drupal 7 is in amazing shape for upgrades, especially compared to the Drupal 6 release and when you consider how long this release cycle was, and the breadth of changes that’ve gone in. Even so, for any kind of real site with any complexity, you’re going to need lot of time, not just for doing the usual upgrade prep work, but to figure out workarounds for the modules that aren’t ready to upgrade. For now, you’ll need to make decisions about dropping features, replacing them with something else, or doing the work yourself to upgrade the modules you need. Kudos to everyone who worked (and continues to work) on Drupal 7, and to the contrib maintainers that have worked hard to get things up to speed. If you’re frustrated with the lack of modules available for upgrade, keep in mind that these people are volunteers, so as in my case, “put up or shut up.” I chose to not spend the time to work on features I wanted because the features I lost were not critical and this is a simple personal site, and I’m fine with that. If I had a business need or felt strongly enough, then it would be up to me to contribute code, help review, and/or spend money to help move things along. Or just quietly wait until someone else does. I’m happy to quietly enjoy my new Drupal 7 site. 🙂
RockTreeSky 