Over the past 6 years or so I've launched close to 100 Wordpress sites. It's safe to say I'm familiar with the process. Still, I get contention occasionally when we need to launch on someone else's infrastructure. In my opinion however, there is only one proper way to take a Wordpress site live.
Before I list out the proper steps, here are the common alternatives I run into and why they're not as good a route.
Wrong
1) Zip up the theme, use the wordpress import/export tool
This one is bad for so many reasons but I get it a lot. You'll lose all of your plugins and configurations for them, you'll lose all of your theme configuration, you'll miss the wp-content uploads directory, menus will be missing, and so much more. This route is fine when you're installing a purchased theme with demo content, but not for a completed actual website.
2) Use a plugin to backup and import
This one may have a better shot but I still don't trust it. Plugins like XCloner are pretty nice and full featured, but unless the person on the client side is already using such a plugin, what's the point? I'd rather have full control over the details and be sure each action is performed properly. There are also a number of such plugins which you'll need to learn as you encounter them, each with varying degrees of success. You'll run into things like server timeouts, file size restrictions, permission issues, etc. Who needs the headache?
Right
The right way, especially when moving between domain names (i.e. dev.newsite.com -> www.newsite.com) is the tried and true manual way. True I'll use one particular plugin for convenience but it's mostly manual.
1) Backup Everything
First thing's first, make a backup before you start the process. I do this by SSH and simply zip up the entire web directory and the dump the database:
$ tar -zcf preLaunch.tar.gz /path/to/web/$mysqldump -u username -p database_name > preLaunch.sql
You can do this any way you like. Do an export from PhpMyAdmin and copy the web directory via FTP if you need to.
2) Tie up loose ends
- Make sure you've created a user with Administrator access for the client that isn't your account.
- Remove any plugins that don't need to be there and update everything that does.
- Make sure you've removed the check mark to discourage search engine.
- Delete any demo pages and content.
- Ensure you've replaced your test email addresses in the general settings and any contact forms.
3) Switch the domain name to the production name
Warning: once you do this, the site will no longer be accessible to you in your dev environment until you edit your hosts file.
For years I've made this switch manually by executing UPDATE statements on the database. Recently We've begun to use an excellent plugin that makes this far easier. Go Live Update URLs takes the pain and error out of this process. The plugin will take one string (usually a URL) and replace every instance of it, in every table of the database with a new string (URL). You definitely want the PRO version of this plugin ($35) because it will also hunt through JSON encoded data and update the url's in them too.
Once you've installed the plugin, simply enter the old URL and the new URL and let her rip.
Mat Lipe 4) Modify your hosts file to regain access
By editing your computers hosts file, you can change what IP address a domain name points to. For instance, if your dev site used to be at the IP 1.2.3.4, you can tell your computer to look for www.newsite.com at 1.2.3.4 even though the real IP address will be different. This will let you preview the new live site before actually making it live, allowing you to correct any issues that might pop up before you move it over.
The format for the host file entry is simple (IP Hostname):
1.2.3.4 www.newsite.com
The location of your host file will depend on your operating system and version, but Rackspace has a thorough guide for finding it if you don't know how.
Once you've regained access, fix any problems and ensure you're ready to go. I usually remove the Go Live Update URLs plugin as well.
5) Pack up the site
This is identical to Step 1 except now the contents of your backups will be the deliverable site and database, so name the files appropriately.
6) Transfer the site to the new server
FTP is usually fine for this, or you can host the assets somewhere accessible and do a wget on the new server to pull down the files.
7) UnPack and configure
Unzip the site files and import the database script into the new environment:
$ tar -zxf Launch.tar.gz$mysql -u username -p database_name < Launch.sql
Open up the wp-config.php file and update the database connection settings for use on the new server. Finally, make sure the file and directory owner and group are correct:
$ chown -R username:group /path/to/web/
Finished
If everything went to plan, you should be up and running. Now enable caching, install some security measures, and enjoy your site.
This story, "From Dev to Production - The proper way to take a Wordpress site live" was originally published by ITworld.