AKA, How to upgrade a complex Drupal site to D7
So Drupal 6 reaches end of life on Februrary 24. If you're like many of my clients, only now are you getting around to making that upgrade happen. Accordingly, I've done a bunch of D6 to D7 upgrades recently, and wanted to share the recipe I now follow to make things go as smoothly as possible.
This process has worked out extremely well even for moderately complex sites, for instance e-commerce sites using Ubercart.
Views is a very powerful query builder, but it can be challenging to make it solve specific problems that it wasn't intended to address.
Recently I've had some clients come to me because their previous developer just kind of dropped out of sight. This happens every now and then when you rely on one-person shops. It's also also familiar to me on a personal level: a vanishing dev is largely why I got into this line of work again in the early 2000s, after a few years' hiatus. The problem in these recent cases was complicated because not only did this dev build the sites, but also hosted them. This meant that, for one (live) site, no much-needed code or template changes were possible, and another (dev) site couldn't launch.
I’ve been a Thinkpad user for many years now. I love my mid-2000s T60 with an irrational passion. So much so that, when I cracked the case a couple of years ago, I hit up eBay for an identical replacement rather than try something new. (I’m pretty confident that at least some Thinkpad owners will be nodding in understanding right now.)
Getting web site errors fixed means telling your programmer or IT people what needs fixing, and it can be challenging to communicate effectively with them. Technical folks really want to fix things, and non-technical users really want them fixed. But the language each group uses to understand and describe the world is not quite the same. The resulting confusion is frustrating for both.
It has long been good practice to use email-validation tools such as Sender Protection Framework (SPF) and Domainkeys / DKIM to provide confidence that a given server or domain has the authority to send emails on behalf of its own or other domains. We use Postfix and Amavisd-new on Debian to perform DKIM signing of messages on a central mail server that relays mail for many other servers. There were a couple of catches to getting it all working that I wanted to record for posterity, should anyone else run into similar problems.
First. amavisd-new can now (since version 2.6.0) handle DKIM signing itself, meaning you can do away with additional milters or the use of dkimproxy. To tell amavis that you want it to sign mail, you need only add this line to an appropriate config file (say, conf.d/50-user):
$enable_dkim_signing = 1;
Keys and selectors are assigned to domains by adding lines like so:
dkim_key('example.com', 'selector', '/var/db/dkim/example.com.key.pem');
(I am omitting the details of generating keys and creating the DNS records necessary to make DKIM work. There are lots of tutorials on the net that cover that material.)