I'm about to go on vacation without my computer, so this is a bit of a catch-up kind of post. In the last 2 weeks, I helped launch four sites. You might think this would be the culmination of a lot of work for me, but in fact none of these sites were a lot of work for me - my role was more of the fixer, but not the prime mover. They were:
1. Toronto Workforce Innovation Group
This was a project of Blackfly, the collaborative whole-site web development shop I've been working on since last fall. Most of the work of this site was done by my colleague Reema. It's a great showcase of how you can assemble some pretty standard parts, and with a minimum of coding, create a great looking, functional site that still reflects the complexity and specificity of an organization. She made good use of a theme from TopNotchThemes, and the interesting relationships between the "Challenges" section and the "Solutions" section was a nice text-book use of views/cck.
2. Rosenberg Foundation for Children
This is a small non-profit based in Western Massachusetts, started by the younger son of the Rosenbergs who were executed in the US in the 50s for treason. They're celebrating their 20th anniversary this year of supporting children of activists. I don't usually work with organizations in the US, just because of the complications of distance and sometimes culture, but I really liked the mission of this organization, and my contact there is super nice, and they came looking for me (because of my CiviCRM expertise), so I didn't want to say no. They had been suffering from the inadequate service of a previous provider, so it was a kind of a rescue project - extracting them from the previous server and all it's out-of-date modules and badly implemented features. They're now happily settled into a local (for them) service provider called Florence IT, who I've been pleased to get to know and work with.
3. Anne Mitchell
Anne Mitchell was the Executive Director of CIELAP for many years, now retired and doing independent freelancing. She's also a neighbour that I've known for a long time through Quaker connections, and last year I kept running into her on the street and chatting and thought I'd offer her a website to help her with her freelancing. I don't usually do small little sites like this, but Anne is not only extremely generous and nice, I like what she has to say. I hope you do too. As far as the Drupal goes, it's an example of what Drupal can do simply, and mostly out of the box.
4. La Leche League of Canada
This site was another refugee from a previous service provider. In this case, the provider had done a nice job of the design, but didn't know much about Drupal and even less about CiviCRM (and their CiviCRM-knowledgeable staff had then left ...). But La Leche did have a committee member who knew a lot about websites (she runs her own web consulting business), and was happy to learn about Drupal and CiviCRM, so in this case, all I did was an easy migration to my web server, and a bit of advice from time to time, and she finished off all the hard bits to get the site ready. I'm going to presume that you know about the la leche league, and if you don't, well, go visit their nice new site. I hadn't had any direct experience with them before, but I know three La Leche leaders and they're all excellent people.
I don't usually launch quite so many sites together, so it was a great opportunity to reflect on that process. I still don't like calling it a 'launch', which I presume is an attempt to make a technical switch sound more exciting that it is. I guess for some sites, there can be a little celebration, but here's what actually went into these Drupal site launches.
1. DNS
The domain name system is what maps domain names to IPs (which are then assigned to computers with a complementary system). So technically, a launch is typically just a change in a dns entry, which redirects browsers from the old machine (or placeholder site) to the new one. The tricky bit here is often that the dns can be hosted with the old provider, so you may need to create a new dns service, which then requires instead a change in the domain registration, which has it's own complications. In addition, you'll also want to consider what happens to mail and other uses of that domain and any subdomains, and decide on the behaviour of the domain with and without www. This is a classic example of how what should be a simple technical job can easily ambush you into a disaster, and it's a good idea to give this process ample advance thought and time.
2. Domain name change
If you've set up the site with a temporary domain, then switching it usually has implications for Drupal and CiviCRM. If you've built it well, then it can be relatively seamless, but inevitably there are a few places where you have to change a configuration or two or three, and then you'll want to clear some caches, and make sure that anyone who visits the old/temporary domain is processed nicely. All this is made more complicated by the fact that the dns system is distributed and changes are propagated in a somewhat unpredictable way, so you have to think through a variety of scenarios of how people will be experiencing your site over the following 12 hours or so.
The only useful little trick here I use is: after I've swtiched the DNS, i edit my own hosts file to force my DNS over ahead of most people, and then I can test how it will look before most people see it using the new domain. This is especially useful when you're inheriting a site from someone else who may not have been quite as thoughtful about the launch process (to be generous), and hacked in all sorts of hard-coded links to the temporary domain. Usually you can fix most of those using grep and replace within the theme, but there are some cases where you have to dig into the module settings to fix stuff (particularly with any links that go into generated mail messages, where they have to be absolute ..). If you've got time on your hands or if links to the old domain is going to really break your site, you can also run a spider through the site (say, using wget --mirror), and then check the output there.
3. Google, etc.
It turns out that the machine view of the internet is as important or more than the human view. I say that not because I love machines, but because many human views are filtered through the machine (I don't just mean your computer, but other computers). The prime example of this is how your site will appear when someone searches for it with google: not only does the ranking matter - the title and snippet will also affect how people experience your site, and you don't want to mess that up.
In other words, stuff like SEO and analytics are important to the long term health of your site. So after I've cleared all the caches and made sure the site looks good to humans, then I go into analytics and set up the account and tell google to start paying attention to it on its new domain, and then i go into google webmaster and do the same. When google recognizes the site, then I use the drupal module xmlsite map to generate a site map and submit it. This serves two functions: I get a nice listing of all the nodes so that i can check that they've got reasonable addresses (using pathauto of course), and when I submit it to google, it means a faster and more efficient spidering of the site.
After those three pieces are done (the third sometimes has to wait a day), and any little remaining bugs are identified and squashed, then the site is truly 'launched'. After a day or two, I'll also revisit the site at the temporary domain and make sure that any visits to that domain are suitably redirected (i.e. a permanent redirect).
So, I'm now off for a couple of weeks, and when I get back I'll try and finish off all the big projects that have actually been my bread and butter for the past 4 months.
1. Toronto Workforce Innovation Group
This was a project of Blackfly, the collaborative whole-site web development shop I've been working on since last fall. Most of the work of this site was done by my colleague Reema. It's a great showcase of how you can assemble some pretty standard parts, and with a minimum of coding, create a great looking, functional site that still reflects the complexity and specificity of an organization. She made good use of a theme from TopNotchThemes, and the interesting relationships between the "Challenges" section and the "Solutions" section was a nice text-book use of views/cck.
2. Rosenberg Foundation for Children
This is a small non-profit based in Western Massachusetts, started by the younger son of the Rosenbergs who were executed in the US in the 50s for treason. They're celebrating their 20th anniversary this year of supporting children of activists. I don't usually work with organizations in the US, just because of the complications of distance and sometimes culture, but I really liked the mission of this organization, and my contact there is super nice, and they came looking for me (because of my CiviCRM expertise), so I didn't want to say no. They had been suffering from the inadequate service of a previous provider, so it was a kind of a rescue project - extracting them from the previous server and all it's out-of-date modules and badly implemented features. They're now happily settled into a local (for them) service provider called Florence IT, who I've been pleased to get to know and work with.
3. Anne Mitchell
Anne Mitchell was the Executive Director of CIELAP for many years, now retired and doing independent freelancing. She's also a neighbour that I've known for a long time through Quaker connections, and last year I kept running into her on the street and chatting and thought I'd offer her a website to help her with her freelancing. I don't usually do small little sites like this, but Anne is not only extremely generous and nice, I like what she has to say. I hope you do too. As far as the Drupal goes, it's an example of what Drupal can do simply, and mostly out of the box.
4. La Leche League of Canada
This site was another refugee from a previous service provider. In this case, the provider had done a nice job of the design, but didn't know much about Drupal and even less about CiviCRM (and their CiviCRM-knowledgeable staff had then left ...). But La Leche did have a committee member who knew a lot about websites (she runs her own web consulting business), and was happy to learn about Drupal and CiviCRM, so in this case, all I did was an easy migration to my web server, and a bit of advice from time to time, and she finished off all the hard bits to get the site ready. I'm going to presume that you know about the la leche league, and if you don't, well, go visit their nice new site. I hadn't had any direct experience with them before, but I know three La Leche leaders and they're all excellent people.
Lowdown on Launching a Drupal Website
I don't usually launch quite so many sites together, so it was a great opportunity to reflect on that process. I still don't like calling it a 'launch', which I presume is an attempt to make a technical switch sound more exciting that it is. I guess for some sites, there can be a little celebration, but here's what actually went into these Drupal site launches.
1. DNS
The domain name system is what maps domain names to IPs (which are then assigned to computers with a complementary system). So technically, a launch is typically just a change in a dns entry, which redirects browsers from the old machine (or placeholder site) to the new one. The tricky bit here is often that the dns can be hosted with the old provider, so you may need to create a new dns service, which then requires instead a change in the domain registration, which has it's own complications. In addition, you'll also want to consider what happens to mail and other uses of that domain and any subdomains, and decide on the behaviour of the domain with and without www. This is a classic example of how what should be a simple technical job can easily ambush you into a disaster, and it's a good idea to give this process ample advance thought and time.
2. Domain name change
If you've set up the site with a temporary domain, then switching it usually has implications for Drupal and CiviCRM. If you've built it well, then it can be relatively seamless, but inevitably there are a few places where you have to change a configuration or two or three, and then you'll want to clear some caches, and make sure that anyone who visits the old/temporary domain is processed nicely. All this is made more complicated by the fact that the dns system is distributed and changes are propagated in a somewhat unpredictable way, so you have to think through a variety of scenarios of how people will be experiencing your site over the following 12 hours or so.
The only useful little trick here I use is: after I've swtiched the DNS, i edit my own hosts file to force my DNS over ahead of most people, and then I can test how it will look before most people see it using the new domain. This is especially useful when you're inheriting a site from someone else who may not have been quite as thoughtful about the launch process (to be generous), and hacked in all sorts of hard-coded links to the temporary domain. Usually you can fix most of those using grep and replace within the theme, but there are some cases where you have to dig into the module settings to fix stuff (particularly with any links that go into generated mail messages, where they have to be absolute ..). If you've got time on your hands or if links to the old domain is going to really break your site, you can also run a spider through the site (say, using wget --mirror), and then check the output there.
3. Google, etc.
It turns out that the machine view of the internet is as important or more than the human view. I say that not because I love machines, but because many human views are filtered through the machine (I don't just mean your computer, but other computers). The prime example of this is how your site will appear when someone searches for it with google: not only does the ranking matter - the title and snippet will also affect how people experience your site, and you don't want to mess that up.
In other words, stuff like SEO and analytics are important to the long term health of your site. So after I've cleared all the caches and made sure the site looks good to humans, then I go into analytics and set up the account and tell google to start paying attention to it on its new domain, and then i go into google webmaster and do the same. When google recognizes the site, then I use the drupal module xmlsite map to generate a site map and submit it. This serves two functions: I get a nice listing of all the nodes so that i can check that they've got reasonable addresses (using pathauto of course), and when I submit it to google, it means a faster and more efficient spidering of the site.
After those three pieces are done (the third sometimes has to wait a day), and any little remaining bugs are identified and squashed, then the site is truly 'launched'. After a day or two, I'll also revisit the site at the temporary domain and make sure that any visits to that domain are suitably redirected (i.e. a permanent redirect).
So, I'm now off for a couple of weeks, and when I get back I'll try and finish off all the big projects that have actually been my bread and butter for the past 4 months.