Trellis & Bedrock For Fast WordPress Development
I am continually trying to speedy up and improve my WordPress workflow process. Unlike a lot of JS framework communities, WordPress seems to be a little behind in creating a fast and efficient roll out process. The whole thing seems a little “work it out yourself”.
That being said, there are hundreds of tools littered around the interwebs once you start looking. I have been aware of Roots, and the resources they have created for a while, but never had the time to properly look into them. Today I decided to look into Trellis and Bedrock.
What the Hell is Trellis? Bedrock who?
Trellis is labelled as “WordPress development and production servers done right”. Basically a complete WordPress server on your local machine, with the ability to deploy and update with a single command. This also means that if someone else on your team needs to spin up the theme to take a look, it is as easy as a few commands. No more sending a zip file across email.
Bedrock is a WordPress boilerplate that completely overhauls the standard environment setup. It means that the project is organised, and just easier to work with.
I will only go as far as setting up a local development environment in this article. I will come back and write an article on remote servers once I have my head around the process.
Installing the Requirements
To begin with Trellis runs on Vagrant – a tool for building and distributing development environments. And Vagrant runs on VirtualBox. So before we can do anything, these two need to be installed.
Firstly, to install VirtualBox, go to https://www.virtualbox.org/wiki/Downloads and find the package for your machine. As I am running Windows I have a feeling this process is going to be harder for me, than someone on Mac on Linux. We shall see…
Once VirtualBox is installed, go to https://www.vagrantup.com/downloads.html and download the package.
Vagrant takes care a dependency called Ansible for us. This is a automation system that handles application deployment and task execution. In essence removes the need to run repetitive tasks ourselves. Vagrant only installs Ansible within the project, so if you are going to consistently roll out new project, to save time it would be worth installing locally from https://github.com/ansible/ansible. This is not essential thought.
Create a Project
Now to get into the fun bit. Roots recommend a directory structure that is not the WordPress standard. This is handled by Bedrock, so no problems here.
It looks like this:
Firstly we need a project folder to put everything in.
mkdir example.com && cd example.com
Now we need to introduce Trellis.
At this point you are working with GitHub and SSH. Make sure that you have a SSH key set up on your computer, and also on your GitHub account. If you have not, you will need to do this now.
git clone --depth=1 firstname.lastname@example.org:roots/trellis.git && rm -rf trellis/.git
And now Bedrock
git clone --depth=1 email@example.com:roots/bedrock.git site && rm -rf site/.git
So far so good!
Configure Your Site
Trellis is built around the concept of “sites”. Each Trellis managed server (local or remote) can support a single, or multiple WordPress sites. Trellis handles the configuration everything required to host a site. This includes the databases, folder directories and Nginx vhosts. This means that this process only needs to be carried out once. After this everything can be run from here.
Trellis uses YAML files for each environment. There are two files that you need to be aware of.
Normal settings file: group_vars/development/wordpress_sites.yml
Passwords and secrets: group_vars/development/vault.yml
This file manages the top level settings that is used to define all your sites. This is the bare minimum example that is given in the Trellis documentation.
Each site starts with the website name as the key. This is used by Trellis internally to name the site and as a default variable throughout the build. It is recommended that sites are named after the domain, so that it is easy to understand which is which.
To access the development site on your localhost, set the canonical link to the URL of your choice. Trellis will set your system to show your WordPress site when you visit this domain. In the example above, visiting www.example.test will take you to the site.
Under this site name are the settings for that particular site. There is no need to redefine these variables, but if you do, be aware you will also have to edit the corresponding entry in the Password file.
Passwords and Secrets
This file is used by Ansible. It is used as we do not want to include passwords in our Git repository. This is an example of the vault.yml file given in the documentation. As you can see the site names match in both files.
To get the server up and running, three things need to happen. Firstly move into the Trellis folder, inside your project root. Secondly, run the following command:
Vagrant will go away and get certain dependencies it needs to run. Once these are installed you will need to re-run the command.
At this point I found on my work machine Vagrant got an error when trying to download a build essential: build-essential_12.1ubuntu2_amd64.deb
The console returned the following error message:
The following SSH command responded with a non-zero exit status. Vagrant assumes that this means the command failed! apt-get install -y -qq build-essential curl git libssl-dev libffi-dev python-dev Stdout from the command: Stderr from the command: E: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/main/b/build-essential/build-essential_12.1ubuntu2_amd64.deb 400 Bad Request [IP: 188.8.131.52 80] E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
I found by logging into the Vagrant machine:
and following the command given in the console
apt-get install -y -qq build-essential curl git libssl-dev libffi-dev python-dev
I was able to fix the issue. Once these packages had properly installed, I ran
vagrant reload --provision
To kick off the machine again.
Once running, this will take around 5 – 10 minutes to complete. As soon as this is finished, your WordPress site is accessible. In your browser following the canonical URL set in settings earlier to see the site.
When you need to shut down the machine, you can roll it down without deleting the whole machine by running:
This is essentially shutting the computer down. To start it back up just run:
Once this has been run once and you have the hang of it, your workflow speed is dramatically increased. By including Gulp into your theme development will turn the whole process of developing WordPress themes so much more enjoyable. Rather than messing about with the setting up of environments you can just be creative!