There sometimes comes a time in a blog’s online life when it needs to find a new home.
Whether it be changing to or from a personal blog to a professional blog, outgrowing a domain’s original purpose, or simply a face-lift – there are a number of common obstacles that you can encounter when attempting to lift and shift a blog and other common software packages.
Recently I had been asked by Neil to lend a hand helping him ensure that his new domain was receiving all the traffic from his old one. An easy task I initially thought, as a simple mod_rewrite HTTP 301 redirection from the old domain to the new would suffice however things became slightly more complicated as he outlined his desire to keep the old site and its data. He wanted the new domain simultaneously building upon what already was there. The following tips are just some of the gotchas I encountered, and some learned wisdom I gained along the way.
- Backups.
This is a part of the process that should never be forgotten. Once it became clear that database changes needed to be made, a separate database was created for the new domain and all the existing data copied into it via a MySQL dump. Most hosting sites have abilities to create databases, and allow phpMyAdmin access, but few have the function to replicate a database.
Assuming you have shell access, an easy way to achieve this:
# mysqldump -h hostname -u username -p database name > mysql.wordpress.dump; mysql -u username -p database name < mysql.wordpress.dumpNote: Yes, I know you can pipe this, but this was serving as both a backup to be transferred elsewhere, and an import source for the new database that we could do anytime.
- Read, read, read. Documentation is there for a reason!
Many blog packages (Wordpress and gallery2 just to name two off the top of my head..) have thorough documentation covering just about anything you’ll want to do with them, and when they don’t, they’re open source and you can get technical specifications of whatever you’ll need.In this case, Wordpress has a detailed codex page describing the process of changing things over.
- Configuration Management.
For many changes of configuration settings, particularly ones that can be captured per change – flat files are a good example, Wordpress has wp-config.php and Gallery2 has config.php in their respective top-level directories. Ensure that you have a backup, and record what you’re changing. There’s nothing worse than getting halfway through a change and forgetting what you’re up to, and what setting you’ve changed to what value. For some, a runsheet of all the changes needed and where might just be the ticket to manage tasks.
- Order of change.
For some configuration settings, the order in which things change may impact both domains you’re managing. For Wordpress, wp_options.siteurl is a big one. Change the setting before the site data is in place; worst case scenario – you risk being unable to access your site and control panel, at best you can just expect links to act a little funny. In Neil’s case, thankfully both sites were mirrors of each other, running on the same database so no harm was done – for sites that may no longer be live or available this may cause issues.
- Hidden configuration parameters/options
For some packages, some configuration is done only at setup/installation. These make reasonable assumptions for data that should be static. Gallery2 is a prime example: $gallery(‘data.gallery.base’) points to the path in the filesystem that the gallery2 data is going to be stored. Given that filesystems are unlikely to move, it’s a reasonable assumption that this can be considered as a static variable. Running through setup or install scripts (you DID just change the access, and not remove them, right?) may catch those little options that may not occur to you: You’re moving the domain, not setting it up from scratch – so why would you need to install it again? Things like these are why.
- Forgotten changes.
Everyone loves customizing the look and feel of their blog. Whether or not its a minor reordering of widgets or major theme changes, something long since forgotten is the most likely to come back and bite you. A good example of this is static links within an >a< tags. If you’re switching domains, you certainly don’t want to link back to the old site, that you’re more than likely to retire. Finding all these changes will be a chore, but may give you some inspiration to freshen up that theme and make those changes you’ve been putting off.
- Testing, testing, testing!
- Make sure people can still reference old URL’s.
You can’t control where people link to you on your site. For those who have the ability to keep the old domain hanging around till all the traffic migrates to the new domain, it’s a wise move to put in place redirection for old posts to the new domain. Apache’s mod_rewrite is your friend here, and handles all of the signpointing to your new home.
If your host has mod_rewrite installed (and most do.) then something like this should be able to point visitors to the new domain, while still maintaining rankings and referrer stats:
RewriteEngine On
RewriteBase /RewriteCond %{HTTP_HOST} .RewriteRule (.*) http://www.neilcreek.com/$1 [R=301,L]
Once you’re satisfied that your change of domains has been completed, you’ve copied all the data to the right places, double checked the configuration parameters and settings, ensured that nothing is left pointing at the old domain then it’s time to start testing. Pick a handful of common tasks you do, and another handful that you don’t. Whilst your day-to-day actions may look to be fine, it’s the ones you rarely use that may indicate some kind of deeper problem. Best to try and fix things before they crop up when you least expect, or need them.
Hopefully, by this point, a number of thoughts should be buzzing around your head if you’re contemplating a domain switch and are unsure at how to proceed. This is by no means an exhaustive list on what can and may go wrong during your change. I hope it does give you at least a framework on how to manage your change.
Leif is a UNIX Systems Administrator for a Tier 1 Australian Telco, an avid amateur photographer and general purpose geek. He has been working Unix environments for 5 years, and bought his first Digital SLR body in mid 2004.
