For awhile now, WordPress has been my favorite option for providing clients with a Content Management System. And since the release WordPress 3, it’s become the easiest sale on the planet. After showing them a demonstration, 75% of the time, the client loves it, and it persuades them to pay double the price they would have paid for a generic ol’ static website. It’s amazing how much WordPress 3’s menu builder has had such an impact on the entire software and the overall presentation of it.
So, needless to say, I’ve been churning out a lot of WordPress sites recently at the agency. In this post, I’m going to talk about that last step you take in delivering your shiny, new WordPress site to your client filled with all of their content.
Generally, you’re not going to build the website on your client’s live domain. I usually develop the initial WordPress theme and put in whatever parts of the content I have at the start of the project locally on my computer using MAMP. Then I’ll transfer that site to a dev server where the client and everyone else my agency can view it. After a billion rounds of edits and changes, it’s finally ready to go live, and so then it’s transferred to the client’s live domain.
In creating all of these sites, it’s absolutely crucial to be transferring WordPress correctly. Your concern should be developing your client’s website and not struggling with elementary things like installing and moving around WordPress. If you’re new to the process of moving WordPress, don’t worry. I’m going to explain in it detail. I also would suggest that you practice moving WordPress a few times to different servers. After a few times, you’ll get the hang of it, and see how easy it is. If the first time you’ve ever moved WordPress is the time when you’re putting you client’s site live, you are putting yourself at some serious risk for embarrassment.
Keep in mind that if you’re simply moving your personal WordPress site a new server, all of the following steps are the same.
The Quick Version
To start with, here is a quick version of the process of moving your WordPress site from one to server to another. Even after you’re familiar with the process, it’s not a bad idea to have a checklist of all the steps you need to take sitting by your desk.
If all of those steps weren’t clear, don’t worry; I’m going to explain each one. In the following steps, I’m going to show some screenshots from when I transferred the demo site for my Complexity WordPress theme from my local computer to my live demo website.
The Long Version
Step 1: Export a copy of your dev site’s MySQL database as an SQL file.
The first thing I do is make a copy of the dev site’s database. Login to phpMyAdmin on your development server and export a copy of database.
When you do this, make sure you are actually within the database. You should see all of the tables of your WordPress installation as the screenshot below shows. Then, click “Export.”
Next, configure your export file as I have in the screenshot below. Make sure you have all tables of your database highlighted on the left side. Also, make sure you have the “save as file” checked at the bottom. Click “Go” and a copy of your database should be saved to your computer as an SQL file.
Step 2: Open this SQL file in a text editor and do a mass find and replace of your dev site URL with the new server’s URL.
Update: August 14, 2012
For the most accurate results when transferring your WordPress database, do not follow how it's outlined in this step. The problem here is that much of your data in your WordPress database is serialized, and when you simply open up the SQL file and start changing the text, you will most likely get varied results. -- For example, most of your data may transfer, but maybe your theme options won't transfer, all of your widget data might not transfer, etc.
So instead, to perform this find/replace step of your site's URL, I strongly suggest you temporarily upload the following PHP file to your live site and follow its steps:
Open up the SQL copy of your dev site’s database you exported in the last step in a decent text editor like Dreamweaver, Coda, Textmate, Netbeans, etc. Avoid using a default text editor that comes with your computer (like Notepad with Windows, for example). With large files, sometimes screwy things can happen.
Do a mass find and replace of your dev site’s URL with your new server’s URL.
This is a very important step. If you do this properly, all of your hyperlinks throughout your entire WordPress site will linked up properly on the new server (i.e. manual links you put to other pages in your content, links to images you’ve uploaded, custom links you’ve used in the menu builder, etc.)
I personally use Coda for Mac OSX for all my coding, and below is an example of how to do a mass find and replace with your database SQL file in Coda.
I know Dreamweaver is much more popular, and so here is a screenshot of doing the exact same thing in Dreamweaver.
Step 3: Make a copy of your dev site’s files so they’re ready to upload to the new server.
I personally feel it’s a good idea to actually make a copy of the files of your dev site because if you screw something up, it’s nice to know you have a fully functional dev site still sitting somewhere. So, make a copy of all files, meaning your entire installation of WordPress.
If you have your website locally because you’re using MAMP or WAMP, make a copy of the files. If you have your dev site on a live web server, download all the files to your local computer.
Important Note: Confirm everything in your wp-content directory gets copied. This directory contains everything crucial in the actual configuration of your WordPress site – Themes, Plugins, and Uploads.
Step 4: Create a MySQL database on your new server.
If you’ve created your dev site, I’m going to assume you know how to create a MySQL database. So find where your new server’s database management is (usually in cPanel or whatever similar software your web hosts uses) and create a new, empty database and assign a new username and password to it.
Step 5: Configure your dev site copy’s wp-config.php file with the new server’s database information.
Within the copy you made of your dev site’s files, open up the wp-config.php file and put in all the information from the database you created in the previous step on your new server – database name, database username, database password, and database host.
This is the typical process of installing a WordPress theme, which I’m sure you’re already familiar with. However, it’s a good idea to have your wp-config.php file all ready to go before you upload your files so you can minimize the amount of downtime on the new, live server before the site is actually running.
Step 6: Upload the dev site files to the new server.
Now that you have a copy of all your files, you’ve made sure everything in your wp-content directory is there, and you’ve configured your wp-config.php file, you’re ready to upload!
So, use an FTP client and upload all of your files.
Simply uploading all of your files via FTP is the most common way of doing this process, and it’s perfectly fine to do it that way. However, I do have a tip if you want to be a little more efficient.
Archive all of your files into a ZIP package and then upload that ZIP file to your new server. Most hosting accounts have an interface like cPanel with some kind of File Manager interface, which you can log into and then extract the ZIP package. And if you’re a little more saavy, you can shell in with an SSH client, and unzip that package really quickly.
There are a few of reasons why it’s a good idea to ZIP the files first before you upload the files. When transferring a WordPress site that has been fully developed, chances are you have a lot of files (i.e. your plugins, uploads, themes, etc). These files will take a while to upload and it’s much faster to upload an archived ZIP package.
Other than just the files taking forever to upload, another issue arises sometimes when uploading a lot of files at once through an FTP program. Often, your upload will time out or there will be a temporary connection loss to your server, or something breaks the upload for whatever reason in the middle of the uploading process. When you’re dealing with your client’s new, live site, you don’t want to be wondering if you’ve missed any files. By uploading a ZIP package you can be a lot more certain that you’ve gotten everything successfully to the new server on the upload.
Also, if you are uploading the files one at a time to your new server and someone happens to visit the live URL, they’re going to be presented with funky error messages because WordPress is only half there. This is actually more for the benefit of your client. Clients are always excited about their new website and will keep checking the live domain like an eager schoolboy on Christmas morning, waiting for it to be up. When they see some PHP error, they are going to freak out and call you. You’re going to have to then explain to them that you’re still in the process of uploading files and working on the site.
Step 7: Make your uploads directory writeable (permissions 777).
If you want your client to be able to upload images and files via the WordPress admin panel, make sure you remember to make the uploads directory writeable (permissions 777) on the new server.
You can go in do this with any FTP client.
Step 8: Confirm your database is linked up correctly by going to the new site and seeing the Install WordPress screen.
Now that all of your files are uploaded and in place, it’s a good idea to make sure the files are there and that your wp-config.php is connected properly to your new database. So, if you visit the URL of the new site, you should be forwarded to WordPress Installation screen because your new server’s MySQL database is still empty.
If you’ve inserted something incorrectly in your wp-config.php file or the new server’s MySQL database was not setup properly, you’ll know because you’ll see WordPress’s database connection error.
Step 9: Import your dev site’s SQL into your new server’s database.
Now you’re going to need that SQL file you created back in steps one and two.
Login to the new server’s phpMyAdmin and navigate to the database you’re using. If you’re unsure how to do this on the new server, make sure to contact the web host’s customer support and ask.
Click the Import tab. Then, select the SQL file from your computer and click “Go” to import the data.
You should see a message that lets you know your query was successful, and you should see that your database is now populated with all of WordPress’s content.
Now if you go back to the new, live site, you shouldn’t be forwarded to the WordPress installation page. You should see your website!
Step 10: Login into the WP admin of the new site and go to Settings > Permalinks and click “Save Changes” so an .htaccess file with permalink structure is created on the new server.
At this point you should be just about finished. If you had permalinks setup on your dev site, and you start clicking around the new, live site, you might initially notice that none of your pages are showing up when navigating away from the homepage. What the hell? Don’t fear! There’s a simple answer.
Basically, your WordPress database is configured with the correct permalink structure, however the needed .htaccess file that gets created back when you setup your permalink structure on your dev site isn’t there anymore on the new server. So WordPress is trying to navigate to the correct links, however, your server isn’t setup to handle them yet.
The fix is easy. Login in to your WordPress admin panel and navigate to Settings > Permalinks and simply click “Save Changes” so WordPress can create a new .htaccess file on your new server.
With some web hosts, WordPress will give you an error message when you try and save your permalink settings, telling you that it couldn’t create an .htaccess file. This just means that you need to go into your web host’s file manager and create a new file, name it “.htaccess” and then make it writeable (permissions 777).