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 https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
Wget: wget https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
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:
wp core install --url="url_local" --title="My website Title" --admin_user="username" --admin_password="password" --admin_email="email"
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:
git init git remote add origin remote-repository-address
Now our project already has version control. After each change, if you type git status, you can see the files that have modified. If you want to see exactly which snippets of the files have modified, you can type git diff. To send the changes to GitHub, do the following:
git add. git commit -m "Description of changes" git push origin master
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 reverse. 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 [email protected]:staging/meu-site.git
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 the project. WP Engine creates the repositories for you on the server itself. Once its 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
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:
sudo apt-get update sudo apt-get install rsync sudo apt-get install sshpass sudo apt-get install openssh sudo apt-get install openssh-server
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:
# ambiente local local: vhost: "https://vhost.local" # Url from your local environment wordpress_path: "/home/username/sites/seu-site" # Absolute path of your project database: name: "database_name" # Local database user: "user" # User database password: "password" # Database password host: "127.0.0.1" # Database host # Approval environment staging: vhost: "https://example.com" wordpress_path: "/var/www/seu-site" database: name: "database_name" user: "user" password: "password" host: "host" exclude: - ".git/" - ".gitignore" - ".sass-cache/" - "bin/" - "tmp/*" - "Gemfile*" - "Movefile" - "wp-config.php" - "wp-content/*.sql" ssh: host: "host" user: "user" password: "password" # The password is optional, you can use SSH keys, if you prefer # Production environment production: vhost: "https://example.com" wordpress_path: "/var/www/seu-site" database: name: "database_name" user: "user" password: "password" host: "host" exclude: - ".git/" - ".gitignore" - ".sass-cache/" - "bin/" - "tmp/*" - "Gemfile*" - "Movefile" - "wp-config.php" - "wp-content/*.sql" ssh: host: "host" user: "user" password: "password" # The password is optional, you can use SSH keys, if you prefer
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: https://github.com/welaika/wordmove
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:
Vhost
- Is the URL of our project
WordPress_path
- The absolute path of our project
database
- Access credentials to our database
Exclude
- 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)
SSH
- 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 [email protected]:production/my-site.git
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.
