Recently a friend of mine asked how they could get a copy of a new client’s website on their local computer so they could develop a new theme for the site. They were already using VVV, the popular WordPress vagrant virtual machine, so the main challenges were in creating a new site on VVV, and copying the live data to that new site.
I recommend reading this whole post once before working through it. This process may take you an hour or two the first time you do it, but once you get the hang of all the pieces involved you’ll be able to copy sites in about 10 minutes.
Note: There are certainly other ways to create a new VVV site more quickly, but this post aims to provide understanding of what scripts like that are doing behind the scenes.
Let’s get started!
Setting up a new site on VVV
First thing we want to do is create a new site for this specific client on your vagrant virtual machine (VVV). This video does a great job of showing what all it takes. Pay attention to what he is typing, because in a few places it may not be clear.
Thanks to Curtis McHale for the excellent video.
He does a few main things to setup VVV for another site (Note: He does Not have VVV running. You can stop vagrant by running
- First, he copies an existing Nginx configuration file (Nginx is the webserver in VVV) and edits the copy to serve his new site at his new domain.
Personally, I like to use
.devfor my local domains. This way your local domains don’t ever conflict with real ones. ex:
cd /path-to-vvv/config/nginx-config/sites cp local-nginx-example.conf-sample daggerhart.dev.conf
- Next, he creates a new folder for the new site within the VVV www folder.
And he copies an existing WordPress code base to that new folder. You can do this by downloading a fresh copy from here http://wordpress.org/latest.zip, and extracting it to your new folder..
- The next step is to edit a VVV database file that handles the creation of databases, and adds an entry for his new database.
cd /path-to-vvv/database nano init-custom.sql
If you do not have the
init-custom.sqlfile, copy the sample to that file name, and then edit the new copy file:
cp init-custom.sql.sample init-custom.sql nano init-custom.sql
- Next, he edits his computer’s hosts file to send requests for his new domain to his VVV machine.
On Windows, this file is at
C:\Windows\System32\drivers\etc\hosts, and it is a system file so you’ll have to edit it as an administrator.
On OSX, the file is
/etc/hosts, and will need to be edited with administrator privileges.
The hosts file is how you can map custom domains to ip addresses. In the video you’ll see him making a new line using the IP of his VVV machine, and the new domain he wants to use.
Your new entry should look like this:
- Starts vvv
- Visits his new site and performs the WordPress install
Migrating data from a live site to your new local site
For moving the site data & content, I recommend using All in One Migration. https://wordpress.org/plugins/all-in-one-wp-migration/
- First, install that plugin on your client’s site, and then again on your new local site.
- On the live client site, perform an export (there is a short video on the plugin’s homepage that gives an example of this). Be sure to replace the live site’s domain with your new local site’s domain.
- On your local site, go to the plugin’s Import option, and upload the file you just exported from the live site.
- (video tutorial)
Video by @servmask
Pro tip: Once you’re done working on the live site (after you’ve downloaded the export file), close that tab so you don’t accidentally confuse the two sites later. I try not to have live sites and my local dev versions open at the same time, to help prevent mistakes.
Make sure to follow the steps the All-in-One Migration gives, it recommends saving your WordPress Permalink settings twice (Dashboard > Settings > Permalinks).
After you perform the import you’ll have to log back into your new local copy using the live site’s login credentials. This is necessary because the import process empties the database before it imports the new data.
Now you should have a fully working version of your client’s site on your local computer.
Hey Jonathan, thanks for the great info here.
I’m new to VVV but need to setup a local env for an existing WP site. With the latest version of VVV it seems we can spin up a new local site by simply adding an entry to the vvv-custom.yml file and then running ‘vagrant reload –provision’. This gives us a working local but empty WP site.
My theory is to do the above and then: 1) replace the code files with those from live – ideally via git, 2) migrate the live data to the new site, 3) change the database settings in local.
Do you see any reason why the above would not work? It would avoid the need to change the VVV files as per Curtis’ video.
Thanks for sharing! I haven’t tried that approach yet, but it sounds much easier.
I can’t foresee any reason why that wouldn’t work. As long as the
vvv-custom.ymlfile doesn’t get overwritten when updating VVV, it seems like a great solution. Maybe make a backup of that file before updating the first time just in case it gets lost?
I’d love to hear back about how well this approach works.
Did this workflow work as intended for you? I am about to do the same. Would love your insight.
I wonder if this might be done with Backup Buddy, rather than All In One Migration.
I’m not very familiar with Backup Buddy, but I don’t see why not. The main thing is to get a copy of all the content files for the site, and a copy of the database with the live site domains replaced with the domain of your new local test site.
I’ve done this before using WP Migrate DB to get a copy of the database with urls replaced, and a zip of the content files.