If you need to do a major redesign job on a WordPress site – either for a client or for yourself – it’s best to copy the whole darn site and work on it in private.
Once the site is copied and invisible to the rest of the world, you are free to go crazy on it. You can play around on the “dev” site’s redesign and functionality while your live site remains the same.
There are two ways of “working in private”. One is by installing MAMP for Mac and XAMPP for Windows and setting up the server environment locally. The disadvantage of this is only you can see it. You can’t show off your new design nor get others to test it.
The second is by creating an exact copy of your site on the same server, usually in a .dev subdomain. This is a great way of doing things as you can work on the site in private and your friends and/or clients can look and test it during development.
Create a .dev subdomain version of your site
If don’t have cPanel or you’re unable to take any of the following steps, please consult your host. And, first of all, back up all your files. The following video shows copying a client’s site onto a subdomain using cPanel. (I show the reverse process in another video further down this page).
In order to make a subdomain copy of your WordPress site with cPanel you need to do the following:
1. Create a dev subdomain on your host (eg www.dev.mysite.com). This can be done through cPanel.
2. Copy all the files from your live site to the folder that houses the dev subdomain. This includes all your WordPress files, the .htaccess and anything that’s currently on the root folder of your site (sometimes called “public_html” or “http-docs”).
3. Make a copy of the WordPress database. This is the database that is specified in your wp-config.php. Export it from PHPMyAdmin, create a new empty database with the same user and password, import the old one to this.
4. Change the database name in your wp-config.php to the new one.
5. Add the following lines to your wp-config.php:
6. Your dev subdomain should now be working. Go ahead and log in to the backend with the same username and password as you use on the live site.
7. If you’re going to be uploading new images through the WordPress media uploader, go to WordPress > Settings > Media and have a look under “Store uploads in this folder:” you may have to update the path to the new dev site root there.
Now you have a complete copy of your site with it’s own database. You can change the static pages, the widgets, the menu, the theme, anything. The public-facing live site will be unaffected by what you’re doing to the dev site.
Redesigning and developing the dev site
Now you have a copy of the live site to play with. Remember, before you do, to add some sort of password-barrier to the site so that so one can see it. I use the UnderConstruction plugin. This is particularly good when redesigning with clients as they will know exactly what they’re getting.
The above method creates a new database for the dev site for making wholesale changes to the site. The advantage of copying the database means you can create new pages, widgets and theme settings and they will all be saved on the database for easy transition to the live site when the time comes.
The disadvantage of copying the database is that the dev database will NOT contain any new posts or comments that have been written during development. These either have to be copied manually after going live with the new design or imported from the other database.
Finally, moving the dev site to the live site
This process will hopefully be more simple.
Check out the video above which shows me move the dev site to the live site on my client’s host. As I’ve said above, I’d made multiple changes to the static pages, the widgets, the menu and changed to the Genesis theme framework. So I had to use the dev site’s database on the new site. This meant that new posts on comments on the live site needed to be replicated.
1. Copy the files from the dev folder to the live site’s root folder. It may just be a question of updating the /themes/, /uploads/ and /plugins/ folders of /wp-content/.
2. Amend wp-config.php. Change the name of the database to the one you’ve been using on the live site.
3. Delete the following lines from wp-config.php:
4. Your dev subdomain should now be working. Go ahead and log in to the backend. It may be necessary to go to WordPress > Settings > Media and have a look under “Store uploads in this folder:” and update the path to the live site’s /wp-uploads/ folder.
If something can go wrong it probably will. If this is the case here are a few things you can try:
- Dev site doesn’t work period? Check the .htaccess in both the live site’s root and the dev site’s root – there may be a redirect that’s causing issues.
- White screen of death? Can you login to the backend? What are the error messages? Try disabling plugins.
- Are the links in your dev site going back to your live site? If so, these are probably hard-coded links so don’t worry. And don’t bother changing them.
- Are you having problems uploading images through the WordPress image uploader? Go to WordPress > Settings > Media, have a look under “Store uploads in this folder:” and update the path to the correct /wp-uploads/ folder.
- The home page works but none of the other pages do? Go to WordPress > Settings > Permalinks and put them on default and then back again to custom. This sometimes gets you out of a jam.
You can do it
Creating a “mirror” or “dev” site is a great way to redesign a site. You can make your mistakes in private and the client can see what they’re getting.
Remember, the client should know exactly what they’re getting before embarking on a redesign, otherwise inviting a client to view a dev site can cause “brief creep”. Be careful!
If you’re doing a big redesign, I suggest giving this method a try. And, if you do, let me know how you get on.