Simple Drupal Upgrade == Lots of Pain

I’m not one to jump every time there is a new update to Drupal core. Since all of my sites are locked down to a certain extent, I like to see the history list to see if the update will provide benefit to the website. Working production sites can easily be taken down with a single, seemingly innocuous update to core or even key modules. My motto is always “buyer beware”.

Here are a few simple rules I enforce on those websites I manage for busines:

1. If you don’t need to have website users create their own accounts (i.e. for shopping carts, comments, etc.), then don’t let them. One of the first permissions I change in Drupal is to allow only administrators to create accounts.  http://yoursite/admin/config/people/accounts
   
2. If you don’t need or want comments, turn commenting off for all content types. http://yoursite/admin/modules

With these 2 simple rules you remove many of the security issues & required updates that make managing a website an involved job.

Upgrading to Drupal 7.28

I felt that it was time to get to the latest version of Drupal (latest as of this blog post). The websites I manage weren’t that far behind but there had been enough changes that it was time to upgrade. At the same time, several of the modules I’d been using either had security updates or major releases. I decided to update the websites, one at a time during late night when traffic is slowest, so that all modules & core were current. While I am methodical about updating, I still got hit with the dreaded White Screen of Death and then later with the “only works when logged in” style of pain. I love open source but with it comes a requirement to be able to do some serious debugging / sleuthing.

I started with one of my smaller sites and first upgraded core to 7.28. That seemed to go ok and so I chose to start upgrading modules & themes. The first couple went fine and so I did the ultimate No-No — I clicked for all modules to be upgraded. The result? White Screen of Death. The problem with taking shortcuts is that backing out becomes extremely difficult. Here are the steps I took to resolve the WSoD:

1. Clear all caches including browser cache. This seems to solve a myriad of problems but not in this case.
2. See if I could access any of the administration pages. I like to make sure that my Admin theme is different from the site itself in case there are conflicts. In this case, yes I could see the administration pages but for some odd reason, Drupal didn’t think I had permissions for some sections of the site.  http://yoursite//admin/appearance
3. Look at my webserver logs. Aha! This is where I found that the issue — there was now a conflict in function declaration across 2 different files. Hadn’t existed before but now with the upgrade in theme, it’s clear that something changed. The issue though is that I had an extra theme active (subclassed from the default) but not set as the default which was an oversight. *hint* make sure that ONLY those themes you will be actively using for your drupal website are active. All others can be deactivated without deleting (should you change your mind later).
4. With this conflict, I could not deactivate the rogue theme using the Drupal web interface.  Command line to the rescue and I moved the theme out of the way which gave me the access I now needed to properly cleanup themes in Drupal and remove any potential areas of conflict.

So this was just one website. I’ll go into gory details on the next round of upgrades in a few days.