When most people start doing WordPress development, their workflow involves downloading a file from a theme or plugin via FTP, editing it, uploading it via FTP, refreshing the page, figuring out went wrong and then starting the whole process over again. This strategy, know as “cowboy coding” is not only inefficient, but dangerous.
Once you’ve put your cowboy days behind you, it will be obvious that no serious WordPress development can ever be done that way. The alternative takes a little work getting setup and used to, but the pay-off is more than worth it.
Developing your WordPress site in a local environment–one that is on your personal computer–is an essential practice that will speed up your development and prevent any of the mistakes that you inevitably make from being shown to the world. Working locally allows you to experiment without fear of causing your site to become unavailable to your users.
In this article I am going to give you an overview of a reliable, efficient and secure workflow for developing and maintaining your site locally and deploying it to a live server while creating automatic backups. I’m going to be discussing specific technologies that I use and recommend. I’m not going to cover all of the options or do an in-depth tutorials on each one.
While I do invite you to leave a comment about why you prefer another tool to the one I’m suggesting, please think of this post as being more about a general strategy than a set of hard and fast rules or recommendations. Once you’ve familiarized yourself with the concept, you can improve it to fit your needs.
Before We Begin
Local vs Remote Environments
To avoid confusion for anyone who may be new to this, I’d like to make sure everyone is clear that when I refer to a local environment or local server, I’m referring to any web server that is running on a personal computer and is used for development–i.e. not for actually making the site available to others on the internet. Conversely, the terms “production,” “remote,” and “live” by themselves or in front of “server,” “host,” or “environment” refer to the web server that is used to serve the page to the internet. This type of server is generally provided by a hosting company of some kind.
My Tools
Here is a list of the tools that I use to manage my local WordPress environment and deploy it to my live server. I recommend you give them a try as you begin improving your own workflow.
- DesktopServer – There are a variety of tools for creating local WordPress sites. In my opinion, the best tool is Vagrant, but the easiest and second best is DesktopServer. Vagrant is an automated system for creating and managing complete server environments in a virtual machine. DesktopServer creates a server for you using XAMMP, using a simple GUI.
- SourceTree – A free, easy to use and very powerful GUI tool for Git.
- Private BitBucket Git Repository – While most of the time the only truly sensitive information in a WordPress install is in the wp-config file, which I don’t include in my Git repository, I keep whole sites in private repos, which are free from Bitbucket. Open-sourcing your entire site might make sense, but it’s something to think through thoroughly before doing so, and erring on the side of caution is a good policy, especially when doing client work.
- WP Migrate DB Pro – While Git can keep all of the site’s files in sync between environments, a different tool is required for keeping the MySQL databses in sync. WP Migrate DB Pro is an excellent plugin that automates this process.
- Web Hosting With Git – More and more these days, even shared hosting offers Git preinstalled and SSH access. If your shared host doesn’t offer these features, I recommend you get a new one as Git and SSH are essentials for modern web development. Many hosts, such as WP Engine and Site Ground, now offer Git as a standard feature in their lower-end hosting packages.
The workflow I am outlining here is for a simple, one server per site configuration, which allows for the use of Git as a deployment tool.
If you are using a more complex server configuration, or may be in the future, getting your site under version control is the first step to using a deployment tool more suited to that type of job, like Beanstalk. Beanstalk makes pushing one Git repository to multiple hosts very easy as well as improving most other aspects of deployment. For a simple site it can be helpful, but is really not needed.
Setting Up Local And Remote Sites With Git
Step 1: Create A Local Site
Creating a local WordPress site with DesktopServer takes only a few clicks, but before you begin you will want to create a few blueprints. A blueprint is a WordPress folder or zip file that DesktopServer will use to build your site. They are stored in the blueprints directory of the DesktopServer application folder.
This feature allows you to build one or more starting points to work from. You can even customize your wp-config file in the blueprint by modifying wp-config-sample.php as needed. Leave the database settings and security salts as is, and DesktopServer will fill them in when it sets up the site.Personally, I keep two blueprints at a time. They both have WordPress itself in a sub directory of the root directory, with a content folder in the root directory as well. I load up the themes and plugins folders with the themes and plugins I always like to have installed.
To learn how to do this, see my article on wp-config tweaks. The end results are heavily inspired by Mark Jaquith’s WordPress Skelton.
(Note that WordPress is added as a git submodule from the WordPress Git mirror. The main difference between the two blueprints I use is that one has that submodule set to the master branch, and the other is set to the branch for the last release.)
Once you have your blueprints set up, open up DesktopServer and restart your web server. Once it’s started, select the “Create a new development website.” option.
On the next screen you will give the site a name, which will be its address with the fake top-level domain .dev appended to it. You can also select the blueprint, set the location the site will be saved to, and choose to allow WordPress multisite or not.
Once you have entered your settings, click “Create” to create your site. When DesktopServer is done, it will give you a link to the WordPress install page, and from there, the experience is just like using any other WordPress site you’ve ever used.
Step 2: Create Local Git Repository
The next step is to put the site under version control. In Source Tree select “New/Clone” from the file menu. In the window that pops up select “New Repository”, select Git for “Repository Type” and browse to the root level of your new site in the “Destination Path” field. Once you click create, you will see your new repository in the bookmarks window. Go ahead and open it up.
Before making your fist commit, which will be everything in the working tree, it is very important to first tell git to ignore you wp-config file. We will address managing the different wp-config files for the different servers shortly. Getting git to ignore wp-config is as simple as right clicking it in the “Files In The Working Tree” list and selecting “Ignore”. Once that is done, commit everything else.
Deploying To The Live Site
Step 1: Push To Bitbucket
It is possible to push your site directly from your personal computer to your remote site, but I don’t like to do this. Instead, I deploy from BitBucket.This extra step spares me from having to setup SSH keys on the remote site, and more importantly, it creates an automatic backup of all site files that are stored either on my server or on my personal computer.
It also means that if I move to a more complex hosting setup that requires a deployment tool like Beanstalk or a similar service, I already have the necessary remote Git repository ready to go. Further more, if I want to collaborate with another developer, all I have to do is give them access to the BitBucket repository.
You can create repositories in your Bitbucket or GitHub account from inside of SourceTree. Just go back to the repository we created in step 2 and select “Add Remote” from the “Repository” menu in SourceTree.
In the window that pops up, click the planet earth icon next to the “URL/ path” field.
In the next pop-up select “New Repository.”
If you haven’t already, you will need to provide your username and password for your BitBucket or GitHub account. Once you have, SourceTree will let you create and name the new repository.
Once the new remote is added, you can push a branch to it by right clicking the branches name in the right hand column of SourceTree and selecting it in the “Push To” sub-menu.
Step 2: Prepare Remote Server
In the remote server, we will need to create a database, wp-config file and directory, with nothing but an empty git repository. You will want to create a new database manually and then make a copy of your local wp-config file, change the database details and any other constants that should be changed for live use, such as WP_DEBUG, and then upload it one level above the WordPress root directory with an FTP client.
WordPress will automatically find the wp-config file there, so there is no additional setup required to make this work, and it probably increases your site’s security.
This approach has the added benefit of keeping sensitive information from the wp-config in your git repo. This means you can use a public repo and not worry about exposing your database information or security salts during regular Git pulls.
Git Repository
Creating the empty Git repository is probably the only part of this process where you will need to work from the command line, since most hosting packages have a wizard in their control panel for creating MySQL databases.
Open up your terminal app and create an SSH connection to your remote server.
Once you are in, navigate to the web root or whatever directory you will be running WordPress from and clone the BitBucket repository there. You can get the address either from the remote settings window of SourceTree or from the repositories page in the BitBucket web app.
$ ssh -p username@hostname $ cd public_html/wordpress_directory $ git clone
Step 3: Sync The Database
You will now have a WordPress site on your remote site with all of your WordPress files, but a totally different database.This is where WP Migrate DB Pro comes in. Be sure you have it installed on both your local site and your remote site, and you have activated your API key in both sites.
On the remote site, in the settings tab of the WP Migrate Pro admin screen select the “Accept push requests allow this database to be overwritten” option and then copy contents of the “Connection Info” field.
Once you have done that, go to the same place in the local site and select “Accept pull requests allow this database to be exported and downloaded.”
The next step, still in your local site, is to go under the “Migrate” Tab to select push and enter the connection info for the remote site.
Once that is done, click connect to establish the link between the two sites. Once it is established, you can push your local database to the remote site.
In the future, you can reverse this process to update your local environment’s database with new items added to your remote site.
Staying In Sync and Other Considerations
As long as you use DB Migrate Pro to keep the local and remote databases in sync, and don’t revert back to the old cowboy coding ways of making changes to the live site WordPress files, staying in sync and backed up will be automatic.
As I said in the beginning, this is an introductory article, once you get started working this way, new ways of improving your workflow should become apparent to you.
The Uploads Issue
The one issue that the workflow I’ve outlined in this article has is that media files or other uploaded files added in the live site are not synced back to the local site. The entries in the database will be synced, but not the actual files themselves.
Many people choose to have Git ignore their entire uploads folder and keep it in sync manually via FTP, or they write a separate script to handle uploading and downloading them automatically. Personally, I let Git handle the uploads and do the downloads manually.
This is a very valid reason to disagree with my no direct connection between local and remote Git repositories policy. I think it’s worth the trade-offs for me, but I don’t use tons of media in my sites. You will have to be the best judge of your own needs.
WP Migrate DB Pro recently announced a new media files add-on that syncs the WordPress media library along with your database. This new add-on, which I have not tested, is only available with their more expensive license options. It may, however, be a possible solution for this issue with sites that have lots of media files.
Option: Direct Deployment With DesktopServer
DesktopServer does have a deployment tool built in. I don’t use it because it doesn’t support sub-directory installations, which is a non-starter for me. If you are only running one site on your server and it is in the root directory, this tool may be a good option for you.
More Options For Creating Local WordPress Environments
I recommend DesktopServer or Vagrant for creating local WordPress environments, but there are a ton of other great options out there. For a good break down of some more options, see Sarah Gooding’s article 10 Ways to Set Up a Testing Environment for WordPress.
Free Bonus Security Feature
One of the key tasks that a WordPress security plugin performs is scanning your files for malicious code that might have been introduced by any of the nefarious methods hackers use to get evil-doing code into your site.
Once you have your site under version control, you can test for unwanted changes, including those introduced to the security plugin itself, by simply running the “git status” command on your live site.
When you run Git status, you will see everything that has changed since your last commit. If anything has changed that shouldn’t have, you can simply revert back to before the changes were introduced. Of course you will want to figure out how the malicious code got there and deal with the vulnerability directly.
Putting Aside The Cowboy Hat
Well, that’s what it takes to take off your cowboy hat and implement a proper WordPress development environment. There are countless other ways to improve the process, for example automating the process with custom web hooks and Composer scripts.
Any time you put into improving your workflow should be returned to you in multitudes when it comes to efficiency gains.
I’d love to hear what improvments on the basic strategy I’m outlining here you come up with. Let me know in the comments.