Duplicating a live WordPress website in a local development environment

Once your (or your client's) WordPress website is launched it often gets updated with new version of WordPress, plugins, parent theme and content updates. In this scenario it is very much possible that your local development environment which once mirrored the live version of the website is now pretty behind & outdated. Working in such an outdated version of local codebase for any new developments is not recommended as your local codebase is not in synch and any new developments you make will not necessarily work with the live website. The ideal way is to replicate the live website in your local environment before making any updates to ensure your new changes/developments work on live.

However, the replicating procedure is not that straight forward especially if you have your live websites on shared hosts with limited tools & access. There can be number of ways it could be done and it also depends on your work flow. We at Regur Technology Solutions have recently come up with a pretty reliable and straight forward workflow for the WordPress websites that we develop and manage for our customers. I will share this process in this article.

Workflow using Git & Duplicator Plugin

Our development workflow mainly includes GIT and the Duplicator Plugin.

Git to manage only the required theme and plugin files

At any given WordPress project there are about 2 developers working on them. Our workflow is to install a WordPress version in our local development enviornment and git pull/check-out the necessary custom theme and plugins development done from our GIT repo. It is important that we don't check-in the WordPress core files and any third-party ready-made plugin folders and parent theme folders. - i.e. we commit only the theme (or specifically child-theme folders if used any) and specific plugin folders only, inside the wp-content/themes and wp-content/plugins folder respectively. To ensure we don't check-in these files other than the custom development done in theme and plugins we include these files in the .gitignore file. Our .gitignore by default excludes all files & wp-* directories in WordPress root and also wp-content folder and we update .gitignore to include only the necessary theme folder and plugin folder that we custom developed. This also helps ignoring any third-party ready-made plugins that we might use during the project without checking-in those plugin folders accidently.

Advantage

The main advantage of having the above setup is your GIT repository is clean and does not depend on any WordPress version or plugin files. You can check-out these theme and plugin customizations in any WordPress version and on any developer machine to test it out.

Duplicator plugin to replicate the live website

Now it is possible to duplicate a live website locally by just downloading the live websites using simply FTP and downloading the latest database using a tool like phpMyAdmin. However this flow is pretty cumbersome as you have to do everything manually and restoring a live database on local development environment and make it work with local dev URLs is cumbersome. Additionally it is not easily replicateable. Wouldn't it be awesome if this could be automated with just few simple clicks? Welcome Duplicator plugin!

The duplicator plugin is actually a plugin that helps you easily migrate WordPress websites from one host to another host reliably and easily. However in our case we will be using this plugin to duplicate the live website into our local development environment. I will describe the steps quickly below.

1. Install the Duplicator plugin in your live website.

2. Once installed, head on to create a new Installer Package

3. On the first step the plugin will check for any already existing installation files created from any previous setup. It will give an option to remove those files before continuing. Once it finds your website root to be clean and all other requirements passed you are all set to create your package.

4. Package creation screen is straight forward. You need to specify the name of the package so you can easily recall the package in future. Select the option wheather you want to archive only the database and leave out the files, and specify the file & directory filters which will drop out any files & directories that you don't want in your package.

5. This is a very useful feature, because it gives us the flexibility to leave out any files from the package which we don't want in our installer package. For example it could be some large backup directory that you might want to skip. We will use this feature to leave not only some unnecessary directories but to also skip the child-theme and our custom developed plugin directories. Since this code base is already available in GIT we would checkout those files from our GIT repo instead of the installer files. The screenshot below shows this.

6. Once you have specified your filters you can proceed to next step where it scans your site for creating the package. It will bascially check for the size of files and also allow you to quickly add filters to skip any big size files from the installer package. It is recommended to clear any website performance cache (e.g. W3TC plugin cache) before you build your package to reduce your installer package size.Once the scan is complete and everything appears to be good, you can go ahead build your package.

7. Once the build is complete you can download the installer package.

8. Download the installer and archive files from the above screen and put it in your local dev website root directory. At this point you should be able to access the installer.php from your local dev website.
   Ex. local-penuel.somewebsite.com/installer.php

9. You should now be ready to run the installer file, but before that you need to checkout your GIT repo to download the required custom developed theme and plugins directory into your wp-content folder. Our GIT repo root looks like this.

10. Once you have checked out your GIT repo load the installer URL (see above) to start the installation process, which will basically install the entire live WordPress website (or whatever your included in your package) in your local dev website directory.

11. The installation process is pretty straight forward where you specify the local mysql login details and most of the options are auto-populated so you can quickly and reliably complete the installation.

12. One important option to remember during the installation process is to specify the correct local dev URL. Duplicator auto-detects this for you and pre-fills it. Duplicator will replace all the isntance of live URL to this local dev website URL in your database without you having to do anything in the database. This is pretty cool.

13. Go ahead to complete the installation steps after verifying all options. Once all steps are completed, your website is ready on your local-dev URL. Verify the website is loading with correct theme and plugins active.

14. The beauty of this work-flow is you can easily share the installer package with other developers in your team and can quickly setup a local website and start working on the project.

I hope you found you this workflow useful and inspired you to develop similar or even better workflow for your project and team needs.