In the previous post, we saw some tips to improve your WordPress development workflow. To get clearer, let’s go to practice, showing some tools that can help you in each of the environments mentioned in the previous post.

The local development environment

Our first step is to set up the local development environment. You can configure PHP, MySQL, and Apache on your computer or go for more practical alternatives such as Vagrant or MAMP. I recommend Vagrant because of practicalities, and because it runs in a virtual machine. In addition, you can back up a configured environment and put it on another computer whenever you need, using the same settings.

We have a post addressing the configuration of the Vagrant development environment.

You can also easily find tutorials on the Internet explaining the installation/configuration of Vagrant / MAMP, or explaining how to configure Apache, MySQL, and PHP on your computer. I will use Ubuntu 14.04 LTS in the following examples, so if you use OS X or any other operating system, some commands may vary. We did not test these tools in Windows.

To assist us in managing our local project, we installed WP-CLI, a command line assistant for WordPress. With it, we were able to do several WordPress operations per command line, such as downloading, installing, configuring, creating and removing the database.

Installing and configuring WP-CLI

There are two ways to download WP-CLI from the terminal:

Curl: curl -O

Wget: wget

After downloading, we can test if everything is ok with the downloaded files:

php wp-cli.phar –info

If all is right, let’s extract the file in the bin folder, and create the wp command to do the operations:

chmod +x wp-cli.phar

sudo mv wp-cli.phar /usr/local/bin/wp

Turn the command wp –info and see if the wp command is working.

Downloading WordPress with WP-CLI

Create a directory for your project in the local development environment. Enter this directory from the terminal and run the following command (make sure you have given permission to write to this directory):

wp core download –locale= nl_NL

The above command will download WordPress in the directory we created. Now let’s configure WordPress:

wp core config –dbname=database –dbuser=mysql_user –dbpass=mysql_password

The above command generates the file wp-config.php. Do not forget to replace the values database, mysql_userand mysql_password. With our file configured, we can run the following command:

wp db create

With this command, we are creating the database, with the information that we defined in wp-config.php with the previous command. Finally, we passed the final configurations and installed our project:

With just these four commands, we have WordPress installed and configured in our local environment. Now open your browser at the address of your local project. If all went well, you’ll see a default installation of WordPress.

Version control

Now that we have our local project installed and configured, let’s set up version control. First, we must create a repository on GitHub. Then we need to add the remote address of our project. After creating the repository, open the terminal, enter the project directory and enter the following commands:

Now our project already has version control. After each change, if you type git status, you can see the files that have been modified. If you want to see exactly which snippets of the files have been modified, you can type git diff. To send the changes to GitHub, do the following:

There are several other things we can do using Git, but initially, these commands will serve us.

Staging – the type approval environment

So far we’ve set up our local development environment and our repository on GitHub. With each change in the project, we send the files to GitHub. Only with this, we are already allowing revision of code and allowing errors to be reversed. The next step is to set up our homologation environment.

We support Git and we can set up a staging and production environment. This helps a lot in productivity and organization since we can deploy using Git.

You can add the remote repository to your local environment as follows:

git remote add staging

You should have noticed that this command is the same as the one we used to add the GitHub remote repository. What changes is the domain, which instead of GitHub is WP Engine, and the name of project. WP Engine creates the repositories for you on the server itself. Once this is done, you can deploy staging as follows:

git push staging master

If you want to opt for cheaper alternatives and use traditional servers that do not have Git support, you can deploy your project using Wordmove.


Wordmove is a Rubygem that allows us to deploy our WordPress project in several different environments. In our case, we can use it to deploy in the approval and production environments. How to transfer files is done via SSH, we need some services installed on our computer: rsync, sshpass and openssh. To install them type the following commands:

With these dependencies installed, we can already install wordmove:

gem install wordmove

In the main directory of your local project (same folder as wp-config.php ), create a file called Movefile, with the following content:

This file is written in YAML, and quite self-explanatory. If you would like to learn more about wordmove, you can visit the official project repository:

The Wordmove configuration file is divided into major sections, which are our environments: local, staging and production. Each of the environments has its specific settings, but in general, we have these options:


  • Is the URL of our project


  • The absolute path of our project


  • Access credentials to our database


  • Files that you do not want to send to the environment in question (we do not need to send wp-config.php to the server for example)


  • Credentials of access to the environment in question via SSH

These settings already allow us to deploy our project in the approval and production environments.

Deploy with Wordmove

You already know how the development process works so far. First, we developed in the local environment, we uploaded the changes to GitHub and then we went up to the staging environment. We show above that you can deploy staging on some servers using GIT (as in the case of WP Engine). But if you have chosen traditional servers and are using Wordmove, you can upload the project to the approval environment as follows:

wordmove push -e staging –all

The above command will raise our entire project to staging, including the database, so be careful. If we want to upload only the theme we are working on, we can do the following:

wordmove push -e staging -t

The same goes for the plugins:

wordmove push -e staging -p

To “copy” the entire project from our certification environment to the local environment:

wordmove pull -e staging –all

The use of Wordmove is very simple, for more information you can consult the documentation, or type wordmove helping the terminal.

Production environment

So far we have seen how to configure our local environment, we have already created the repository of our project in GitHub and we have already upgraded our project to the homologation environment. Remember that we need to make sure everything is working perfectly before we move into the production environment.

We have previously seen two ways to deploy our project: Git and Wordmove.

Deploy in production with Git

If you use servers with Git support, you need to add the remote repository, just like we did with the staging environment. Let’s use the WP Engine example again:

Adding the Remote Replacement: git remote add production

Deploy: git push production master

Deploy in production with wordmove

wordmove push -e production -all

Remember that you –all will have the entire project shipped to production, including the database, so always be aware of the context in which you are working. If you are just developing a plugin, you can override it –all by -p, for example.

The process from start to finish

Summarizing the whole process, what you’ve done so far was:

  • Configure the local environment
  • Install WP-CLI in the local environment to facilitate WordPress operations
  • Set up WordPress (local environment)
  • Create a repository in GitHub
  • Add the remote address of the repository (local environment)
  • Develop functionalities / changes (local environment)
  • Test the project (local environment)
  • Upload to GitHub
  • Go up to the homologation environment
  • Up to the production environment

Following all these steps can be a bit confusing and difficult at first, but then you will gain a lot in productivity.

Keep in mind that while making this whole setup a bit dull, you only need to do it once. After that, you can control the entire workflow with just a few commands, and with all those advantages we’ve seen in these two posts.

Comment below to exchange ideas.