[Solved] How to: Easily Move a WordPress Install from Development to Production?


@Insanity5902: Deployment of a WordPress site from one box to another has been a PITA since day one I started working with WordPress. (Truth-be-told it was a PITA with Drupal for 2 years before I started with WordPress so the problem is certainly not exclusively with WordPress.)

It bothered me that every time I needed to move a site I’d have to spend so much often duplicated effort and it kept me from deploying to test as frequently as I would have preferred. So about 4-6 months ago I started working on a plugin to solve the webhost migration problem and I mentioned my ideas on the WP Tavern forum.

Well fast forward to today and I’ve pretty much got it working and I’m conveniently calling it “WP Migrate Webhosts.” Even though the plugin is still very much beta (probably even alpha) given your question I think I’m ready to let people start banging on it.

The envisioned use-case is that:

  1. first the developer handles uploading all the changed theme and plugin files via FTP,
  2. then uploads the development MySQL database to the testing server in its entirety and finally
  3. then runs the plugin to migrate any references from the prior domain to the new one. (My plugin does not attempt to solve the merging of new database fields or tables with live data; THAT is a much bigger problem that I’m not sure how to solve.)

You can download the plugin from my website and unzip into your plugins directory (if you don’t know how to do this then this plugin is not for you because it requires someone who knows what they are doing to use it.) I’ll keep this plugin online until I release it to WordPress.org after which you should look for it there.

To use it you take a different approach in your wp-config.php that normal by commenting out the four (4) defines DB_NAME, DB_USER, DB_PASSWORD and DB_HOST and instead registering the defaults for webhosts and then registering info about each webhost itself. Here’s what that segment of wp-config.php might look like (note the first section is the unneeded code commented out and also note that I set up my hosts file on my local machine with non-routable .dev top level domains to make day-to-day development easier. On the Mac VirtualHostX makes this a breeze):

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
//define('DB_NAME', 'wp30');

/** MySQL database username */
//define('DB_USER', 'wp30_anon');

/** MySQL database password */
//define('DB_PASSWORD', '12345');

/** MySQL hostname */
//define('DB_HOST', '127.0.0.1:3306');

require_once(ABSPATH . 'wp-content/plugins/wp-migrate-webhosts/wp-webhosts.php');
register_webhost_defaults(array(
 'database'  => 'example_db',
 'user'      => 'example_user',
 'password'  => '12345',
 'host'      => 'localhost',
 'sitepath'  => '',        // '' if WordPress is installed in the root
));
register_webhost('dev',array(
 'name'      => 'Example Local Development',
 'host'      => '127.0.0.1:3306',
 'domain'    => 'example.dev',
 'rootdir'   => '/Users/mikeschinkel/Sites/example/trunk',
));
register_webhost('test',array(
 'name'      => 'Example Test Server',
 'rootdir'   => '/home/example/public_html/test',
 'domain'    => 'test.example.com',
));
register_webhost('stage',array(
 'name'      => 'Example Staging Server',
 'rootdir'   => '/home/example/public_html/stage',
 'domain'    => 'stage.example.com',
));
register_webhost('live',array(
 'name'      => 'Example Live Site',
 'rootdir'   => '/home/example/public_html/',
 'password'  => '%asd59kar12*fr',
 'domain'    => 'www.example.com',
));
require_once(ABSPATH . 'wp-content/plugins/wp-migrate-webhosts/set-webhost.php');

Hopefully this is (mostly) self explanatory. I attempted to make the code as clean as I could but unfortunately it requires those two cryptic require_once() lines before and after the block of webhost registration code since there was no way for me to “hook” WordPress before wp-config.php is called.

Once you have updated your wp-config.php then you can simply use the URL shortcut wp-migrate-webhosts to go to the admin screen like so:

http://example.com/wp-migrate-webhosts

The above will take you to an admin screen like the following which has a fair bit of description text and allows you to migrate FROM any of the other webhost domains with a single click after selecting the domains to migrate from (NOTE: this example shows going DOWN from test/stage/live servers to local development but rest assured it can migrate TO any domain where it happens to be located. This also means the plugin will be great for taking an existing live site and quickly getting a local development environment working!):

enter image description here

If it’s not clear “migration” in this context means to update all the references in the current database to be appropriate for the currently defined webhost (and “current” is sniffed by inspecting $_SERVER['SERVER_NAME'].)

What’s cool about the plugin is that it implements some basic migrations but anyone can hook it and perform their own migrations. For example, if you add a gallery plugin that stored full paths to images in the database you could hook the migrate_webhosts action which will be passed the “from” webhost and the “to” webhost each as an array of metadata and you’ll be allowed to perform whatever you need to do in the database using SQL or any applicable WordPress API functions to do the migration. Yes any of us could do this without the plugin but without the plugin I found that writing all the code needed was more effort than it was worth. With the plugin it’s just easier to write these tiny hooks and get it over with.

You may also find my migrations fail in edge cases I’ve not tested and maybe you can help me improve the plugin? Anyone who wants to can email me via my gmail account (my alias is “mikeschinkel.”)

Also, the plugin was designed to accept user-define webhost metadata in addition to the ones it recognizes like database, user, password, host, domain etc. A perfect example might be googlemaps_apikey where you can store a the different API keys for each domain that your Google Map’s plugin needs to operate correct (who among you who has used a Google Maps plugin hasn’t deployed an app to a live server and forgotten to change the code to the correct API key? Come on, be honest… 🙂 With this plugin, a googlemaps_apikey element in your register_webhost() array and a small custom migrate_webhosts hook you can effectively eliminate that as a concern!

Well that’s about it. I’m launching this plugin here on WordPress Answer’s Exchange because
@Insanity5902’s question triggered it. Let me know if it’s helpful, here if appropriate or via email if not.

P.S. If you do decide to use this remember it is alpha/beta and that means it will change so be prepared for some minor surgery if you want to use it now and then use the released version once its been beaten on by many hands.

P.P.S. What are my goals with this? I’ve love to see this migrate into WordPress core so that everybody would have access to it. But before that can even be considered lots of people have to be interested in using it to ensure it actually solves more problems then it potentially could create. So if you like the idea then by all means use it and help me gain momentum with it for eventual hopeful inclusion into WordPress core.

13

solved How to: Easily Move a WordPress Install from Development to Production?