How to Migrate WordPress and Drupal Sites to a New Host

GoDaddy's MySQL performance has been barely acceptable for my WordPress sites, but now that I'm using Drupal too, I need a more capable web host. I've been trying out Hot Drupal by Holistic Solutions and have seen good performance as well as responsive customer support. So now I'm migrating this site, my personal site, and The Everyday Cafe to that host.

This site is already migrated (though the DNS changes may not be entirely propagated yet since I just made them this morning). Now I'm working on the two WordPress sites, annezelenka.com and The Everyday Cafe.

Wondering what's involved in migrating to a new host? The steps are virtually the same whether you are running WordPress or Drupal:

  1. Use phpMyAdmin or your MySQL command line to export your data to a file. I did it in SQL format, zipped.
  2. Create a database at your new web host.
  3. Import the data into the new database.
  4. Download your current WordPress or Drupal files from your old web host.
  5. Edit your downloaded settings file (wp-config.php for WordPress, settings.php for Drupal) so it connects to your new database.
  6. Upload your Wordpress or Drupal directory with the new settings file to your new web host account.
  7. Test your new installation before pointing your domain name at it. Note: to test a WordPress installation, you'll need to edit the wp_options database table so that siteurl and home point to wherever you're currently accessing the site.
  8. Once you have the new site working, edit the wp_options for WordPress, and point the name servers for your domain at your new host's name servers. Before you do that, you might want to make a small change to the new site so that you can tell when the switch has been made -- add a draft post, for example.
  9. Now wait as the DNS changes are propagated. It allegedly takes days for this process to entirely complete, but meanwhile both the old and the new sites should be available.

Backup Strategy for Macs in 3 Tweets

I was going to write a lengthy post about what you should do for backups on your Mac, but Mike Gunderloy expressed a good strategy in three tweets:

I'm doing TM + SuperDuper + selected bits to S3 via JungleDisk. Color me paranoid (or many times bitten, twice shy). [http://twitter.com/MikeG1/statuses/810211409]

S3 gets Documents + source code. It's my "in case of house fire" backup. [http://twitter.com/MikeG1/statuses/810225224]

TM gives me "oops recovery", SD mirrors whole drive to protect against drive failure. [http://twitter.com/MikeG1/statuses/810225682]

So there you have it. Time Machine to recover files you accidentally delete or otherwise mess up. SuperDuper so you can recover your system in case of hard drive crash. And JungleDisk on Amazon S3 for extra-important working documents and code.

Securing Your Websites: The Basics

Cyber-criminals are now focusing on websites rather than email. Anyone who runs a website has to worry about whether it's been infected with bad code, as bloggers Tony Hung of Deep Jive Interests and Josh Porter of Bokardo recently discovered.

With the power of micro-publishing comes the responsibility of making sure you're publishing only what you want to publish. But that takes some knowledge and some work.

What do you need to know and do about security? Here are a few basics with a focus on WordPress and Drupal.

Keep your content management system up to date. Responsible developers will provide patches or upgrades as soon as security holes become obvious. WordPress 2.5.1 is out and it includes a security fix. The latest version of Drupal, Drupal 6.2, includes an important security fix as well.

Hint: if you're a WordPress user, install the Automatic Upgrade plugin. It handles everything from backing up your files and database to putting your site into offline mode while the code is upgraded. With this plugin, you're much more likely to keep your sites up to date.

Use strong passwords for your admin and FTP logins. Don't pick one easy to remember password and use it everywhere. Also, don't just go with the passwords that your CMS generates for you -- change them immediately to something stronger. Drupal 6 includes a nice password strength checker that shows you how strong your password is as you type it in.

Consider using a password management program that will remember long, strong passwords for you. I like 1Password for OS X. Sam Dean of Web Worker Daily recommends PassKeeper for Windows users. Other people swear by KeePass; it's open source and available cross-platform as KeePassX.

Use SFTP or FTP-SSL when uploading files to your website. FTP and telnet use clear text to transmit login names and passwords -- someone could get FTP access to your web site just by watching your network communications.

Note that many cheap web hosts don't provide SFTP or FTP-SSL access. In that case, you may want to use a personal VPN such as OpenVPN so all your Internet communications are encrypted or at the very least change your FTP password frequently.

Protect your files using operating system permissions. The web server itself should only be able to read the vast majority of your files, not change or overwrite them. Yes, there are certain cases where the web server needs to be able to change files -- for example, if you allow users to upload avatars or if your CMS offers you the ability to edit theme files from the management console.

Most of your files should be owned and writable by the user you use to modify the code or pages for your site -- your FTP user for example.

Register yourself as the owner of a website with Google. Google may know long before you do if your website has been hacked. At Google Webmaster Central, you can tell Google what websites you own and verify that you own them, then Google will keep you up to date on what they know about your website. If your website gets hacked as Josh Porter's did, leading to your site's removal from Google indexing, Google will leave you a message about what's happened.

Educate yourself about security. That's one of my goals in writing this article -- to better understand the range of security vulnerabilities a website might have and to know what precautions I might take against them.

You might want to subscribe to Google's Webmaster Central blog via which you'll stay aware not just of security issues but also other important topics like SEO.

WordPress users, subscribe to the WordPress.org blog, where you'll hear about security patches and Wordpress upgrades as they become available. Drupal webmasters will want to subscribe to the security announcements and read the handbook section Writing secure code.

Do you have anything to add? Share in the comments.

Further reading

The Magic of Patches

My first thoughts on exploring Drupal centered on what big thing I could contribute: a theme or a module, perhaps, or at the very least a D6 upgrade for a theme or module. But I soon realized that the key to participation in open source, at least for a newbie, is the humble patch.

What is a patch? A set of software instructions that fixes a bug or adds a new feature to the existing software. The great thing about offering a patch in Drupal is that anyone can do it (you don't need a source code control account), it's of real value to the community, and you are likely to get your code reviewed by someone who knows things you don't. For more on why patches are so wonderful, see the last item in Jody Hamilton's Drupal Time-savers article.

To understand the magic of the patch, consider how bug fixes work in commercial development. If you're using commercial software you probably can't debug it, because you probably don't have any source code to dig into the problem. You have to contact the software provider's tech support and describe your problem. And then you wait for them to reproduce the problem (maybe), figure out what went wrong (maybe), figure out a fix (maybe), and get it back to you (maybe). What hell!

Drupal is sometimes criticized for appealing mainly to developers, but that's part of what makes the community work so well. If you're a developer and you're using Drupal, you're much more likely to be able to offer a patch instead of just logging a bug or support request.

That doesn't mean that if you don't program you can't contribute. There are lots of ways to participate.

I offered my first patch to a Drupal contrib module this week -- it was humble indeed! -- but exciting nonetheless.

Hello World

Welcome to the Togetherism web site, a playground for my social web design and development ideas and experiments. To learn more about me, Anne Zelenka, the web technologist behind Togetherism, go to the About page or visit my personal blog.

The design of this Togetherism web site was inspired by the Acquia web site. I used the Zen theme as a starting point.

Syndicate content