Going Live (or, How to Hand It Over: WordPress)
For Andi’s presentation at WordCamp Miami (see end of this post), we put together a pretty comprehensive list of the entire gamut of processes we have to go through to launch a WordPress website in any number of scenarios.
The list was long. Too long for one 40-minute presentation. So we put together this blog post as an appendix of sorts to give you more detail and better explanations of the more complex command-line approaches (fastest and easiest) to moving your databases and sites from a development environment to a production site.
Our New Project Checklist
To save ourselves hours – no, days of time when we’re ready to launch, we send all of our new clients this simple checklist to solicit all of the credentials and information we might need as we build their website.
Feel free to copy/paste and redesign to your needs. You’re welcome :).
Moving Your Database
Transferring a database can be a nightmare without the right tools. Did WP’s export function cover everything? What happens if you’re using a plugin that doesn’t play nice with that? The easiest way to move your database live is, of course, to actually be developing on the live DB in the first place, but for large sites that will have ongoing work, that’s not an option. You’ve got to have a quick and easy way of copying your database.
So, there are two options:
phpMyAdmin. First, your host probably has an installation of phpMyAdmin that will allow you to access, export, and import your databases. This is your best bet if you aren’t comfortable working in a shell account via SSH (Secure Shell).
When you log into phpMyAdmin and select your database, there’s an EXPORT tab near the upper right. Navigate to that, select everything, and export it as a gz-compressed file. Create your new live database (likely via your host’s control panel), then open that in phpMyAdmin as well, and do the reverse: Go to IMPORT, and upload the DB dump you just downloaded.
Option 2? SSH. This one’s easy: Create the destination DB first, then do the following:
mysqldump -u [dev username] -p [dev database name] > dump.sql
mysql -u [live username] -p -D [live database name] < dump.sql
You may need to supply the -h [hostname] or -P [port] parameters, but that’s the gist of it. How you move the dump file between servers is up to you, but using scp (try man scp) is much better than the old download/upload. You just copied the DB. One last thing for security: rm dump.sql
Fixing WordPress Options and Entries
You’ve cloned your database. If you were working on a subdomain, you now have a problem: Your WordPress installation will be pointing at the wrong place. There are two entries in the wp_options table that determine where links point, “siteurl” and “home.” One points to the root of your site, one to the root of your WP installation (these are often, but not always, the same thing).
If you’re using phpMyAdmin, navigate to the wp_options table and edit those two settings to match the new site.
If you’re using SSH, enter mysql -u [live user] -p -D [live db], then enter the following SQL:
UPDATE `wp_options`
SET `option_value` = 'http://your.live.site/'
WHERE `option_name` IN ('siteurl','home');
If your site root and wp install differ, enter that twice and substitute WHERE `option_name` = ‘siteurl’ or WHERE `option_name` = ‘home’.
Another issue you may encounter if you’ve added a bunch of posts that link to one another: The links in your posts are probably pointing to the development site. That’s cool, we’ve got a SQL formula for that, too. If you’re using phpMyAdmin, you’ll want to bring up the SQL tab for this one:
UPDATE `wp_posts`
SET `post_content` = REPLACE(`post_content`,'http://old_url/','http://new_url/')
WHERE INSTR(`post_content`, 'http://old_url/');
You’re all set. Close phpMyAdmin or type exit if you’re using the command line tools.
Let’s move the site itself.
Moving Your Files
This part’s for SSH; If you don’t have SSH access, sorry, you’re stuck doing it via FTP. This’ll make moving files painless. There are two situations:
Same server: cp -R ./dev_dir ./live_dir (substitute directories appropriate to your server)
Different servers: use rsync or scp to copy your blog files.
We like to move files directly from server to server to save time. Depending on your connection, moving a large WP install can take over an hour via FTP. This method will most likely take less than a minute, given the speed between two servers and not having to transfer it all twice. You can do this via a mobile tether and not have to worry about your bandwidth being throttled.
In fact, if you’ve got an iOS device, check out Prompt from Panic, Inc.
Once your files are moved, update the database credentials in wp-config.php, and you’re good to go.
Using Beanstalk for Deployments & More
We’re big fans of Beanstalk (www.beanstalkapp.com) for version control and deployments. If you’re going to be maintaining the site you’ve just launched for any amount of time, it’s probably a great idea to look into using Beanstalk.
Why? Deployments. Deployments are awesome. Once you’ve used them, FTP will become a miserable experience by comparison (not that FTP needs any help there).
Here’s why it’s so awesome: You can set up automatic and manual deployments to multiple locations from your SVN or Git repository. It works over FTP or SFTP (recommended) for SVN. If you’re using Git, you may prefer deploying via capistrano.
When using SVN, we like to automatically deploy to the development site from /trunk. If you like branches and merging, you can set up a deployment from /branches/live to the live server, but Versions (a popular Mac SVN client) can’t merge. If you’re not down with doing merges, you can deploy from /trunk just fine, just be sure you’ve got it set to manual deployment – it’s safer for the live site if pushing code is always 100% intentional.
That applies to git as well, except you’d be deploying from tags (master, live, etc) instead of SVN paths.
Chris Coyier of css-tricks.com recently published a pretty cool screencast that walks through getting deployments set up. Aside from MySQL acting up, it’s a smooth process.
Mac users will likely want Magic Bean for deployment notifications and not having to log into the website to manually deploy.
Odds & Ends
WP plug-ins we find ourselves using a lot:
- Redirection by John Godley: Easy to manage redirections from the client’s old site.
- WP-Help by Mark Jaquith: Write documentation that lives in the WP admin area.
You might also check out any of a number of security-related plug-ins.
Need an SSH client? It’s built in to mac and unix/linux environments (just open a terminal), but if you’re working in Windows, we recommend Putty.
