Getting a “ERROR! Trellis no longer supports Ansible 126.96.36.199.” error? You probably upgraded to the latest Trellis from an older version and now you need Ansible 188.8.131.52 or higher. So how do we upgrade this baby? Well in my case the box I just had the issue at runs Ansible via Homebrew. Also I have one older Trellis version for another site so I want to be able to use the older version from time to time. So I do want to go back to version 184.108.40.206 when need be.
Homebrew Ansible Upgrade
To upgrade my Homebrew installed Ansible I ran:
and then when I checked the version:
I found out it did upgrade, but not to the next version. Silly me. I would need to remove ansible and then so a brew install firstname.lastname@example.org . But then the next time I needed to run 220.127.116.11 I would have to reverse all using two commands. Sounded like doing it with pip was easier which allows version changes with one command and which is recommended by Roots core members.
And with pip I can also go back to my older version needed for the older Trellis setup using
sudo pip install ansible==18.104.22.168
So then I tried another vagrant up to see if I could avoid the error message:
ERROR! Trellis no longer supports Ansible 22.214.171.124.
Please upgrade to Ansible 126.96.36.199 or higher.
Ansible failed to complete successfully. Any error output should be
visible above. Please fix these errors and try again.
vagrant up did work, but the site failed to load so I did another
The provisioning took quite some time. Clearly first vagrant up had not really completed the installation of the new packages. But that did the trick and I was able to load the site locally and import the database backup. Yay!
The Bedrock Plugins Installation is set up differently. More efficiently too I daresay. That is why often beginners with Bedrock bump into the fact that they cannot install plugins from the Dashboard. In this post I will get into the reasons and benefits behind it. For a general overview of Bedrock see the post Bedrock Modern WordPress Stack.
Dashboard Installation Deactivated
Bedrock disables Installation of Plugins from the Dashboard with:
The standard installation of plugins – and themes by the way – is blocked so all installed themes and plugins stay in version control. Once you start adding plugins or themes on the production server they are no longer in version control. And every time you do a Trellis deployment you run the risk of losing plugins and themes as they are nog part of version control.
Plugin Installation with Composer
You can install plugins with Bedrock using Composer. You can also activate and deactivate them using Composer or WP CLI. You can also manage commercial plugins with composer with a custom composer serve. Either that or you can do it by adding them manually to your site and version control. You will need to remove them from the .gitignore list to get them versioned. You do this by using an exclamation mark like so for example:
Composer in practise
Composer allows you to download and install WordPress plugins from packages registered with Composer and also from WPackagist, which syncs with the WordPress plugins repository.
Just run a command to install the plugin like so:
This install all the plugins in your composer.json file in your Bedrock directory. At WPackagist they show you an example of themes and plugins added from their repo:
NBB It is possible with WP CLI, but not recommended as this way things are not kept in version control.
This method of managing plugins is way better for keeping solid installations that are equal locally (Vagrant) on staging (Trellis server (recommended)) and on production (Trellis) . So this allows for code parity. No more “But it works on my computer”. All changes added with composer will be part of Git version control.
Therefore they will be the same in all environments. Even the plugins not added with composer will be added to version control. All installations that are not done with composer or not committed will be lost to our version control.
As the Roots theme stated:
“Manage your WordPress install and plugins with Composer, a PHP dependency manager. Composer will make development more reliable, help with team collaboration, and it helps maintain a better Git repository.”
On top of that the plugin and theme version can be managed easily. You can enforce a version to make sure the site does not break. Then locally on development you can test a new version by a small composer.json tweak and commit once you are satisfied it works
Composer Bedrock Example
Here the current composer.json as an example. It is one you will find with a standard Bedrock WordPress setup:
For each installed plugin or WordPress installation a version is set. And for every update this has to be adjusted. Then you can commit it to version control and deploy it using Trellis’ deployment script ./bin/deploy.sh production domain.com . During deployment this file is checked and updates will be made. The latter fully automatically.
If customers do want to install plugin you can comment out the
at bedrock-site/config/production. We sometimes use something like
/** Production */
define( 'WP_MEMORY_LIMIT', '128M' );
/** Disable all file modifications including updates and update notifications */
As you can see the DISALLOW_FILE_MODS has been commented out to allow the adding of plugins and themes.
Do however remember to exclude the plugins and themes you add from the .gitignore and to add them to the repository. Otherwise you run the risk of removing elements. Also make sure you enforce some parity by syncing from production another way. Either that or forget about version control altogether.