Migrating and/or Deploying WordPress Sites

As a freelancer I see a lot of RFP’s go by for WordPress sites. Every time I use it, I grow a little more fond of it. Today I want to address one of the common complaints I hear from WordPress developers–migration. It’s one of Web development’s best practices to use a testing/dev/staging site, and then migrate changes after sufficient testing. I’m not sure why so many developers find this difficult.

For a new site (or framework change), it’s easy to drop a WP installation on a “dev” subdomain, leaving a construction notice on the primary domain. Once the dev site is ready for the initial launch, this is the easy process I use:

1. Install WP on the primary domain (the production site).
2. Using FTP, copy the wp-content folder from dev to production.
3. Through the WP Dashboards, install WP Migrate DB plugin on both dev and production.
4. On dev, use the WP Migrate DB plugin to create a SQL dump with the primary domain as the site URL.
5. Run the SQL to update the production database (perhaps via phpMyAdmin–you can find which database to run it on in the wp-config.php file).
6. If changes were made to wp-config.php, be sure to update wp-config.php on production.

For an existing site, this process can work to create a copy of the production site at a development location.

Once there are two copies of the site (dev and production), how the site is maintained determines whether or not you can simply migrate dev over to production for every update. If users are creating content through the dashboard, it’s important to use the SQL dump to update development before every iteration of development work.

If the dev site is being maintained alongside the production dashboard content, that gets a little more hairy, but not too bad. When ready to deploy, one option is to add these steps:

• Just prior to deployment, use WP’s built-in Dashboard->Tools->Export tool to save the pages and posts from production, and also use FTP to back up the media library uploads.
• Just after deployment, use WP’s built-in Dashboard->Tools->Import tool to recover the pages and posts to production, and use FTP to restore the media library uploads.

Here are some more helpful tips:

• Aside from creating pages, creating posts, and uploading media, users should NOT be changing dashboard settings in production without testing them on dev first. This will help create a more stable production environment and avoid losing changes when migrating from dev to production. Ideally, ALL users would make ALL changes in dev before making them in production (though that is understandably not practical in some cases).
• Plugins should be chosen that use pages/posts to generate content, so that the built-in Import/Export tools will handle such production content.
• ALWAYS activate plugins on dev before installing them on production, since plugin conflicts are one of the top causes of bugs in WP sites.
• Choose a theme with a sufficient framework that you do not have to edit any files manually. Theme settings that are saved in the Dashboard will be included in the SQL dump, which will make for more stable updates. Similarly, choose plugins that are regularly maintained and easy to hook into via PHP filters and/or JavaScript event triggers.

The process outlined here is, I will grant, a little more than the one-step deployment that so many people demand. On the other hand, I’ve worked on Ruby sites with supposedly one-step deployments, and I have to say that it’s never really one step. Setting up the deployment process in the first place is a pain, and pipelines errors are notoriously difficult to debug. Hosting environments are not typically set up to handle, say, a capistrano deployment, and even if they are, the typical client must hire an expensive Ruby developer who is very comfortable on the command line to set it up and deal with the initial errors (there are always initial errors–always).

I much prefer my 6-to-8 steps that I know will work. For a simple informational/e-commerce Web site, WordPress is my go-to solution. I would probably bust out Ruby again for a site which is truly a custom application, but I estimate that WordPress can handle 90%+ of the types of public Web sites, and my favorite migration process not only works for me, but is also something that I can train my clients to do for themselves, which makes them happy and frees me up to expand my work into another new project.

I’d be very interested to read comments about your favorite way to deploy WordPress sites. I’d also love to hear your thoughts on WP Migrate DB and other plugins you use to make your WP sites more manageable.