Roots.io and Bedrock: WordPress on steroids
Roots.io is a good choice for those developers who like WordPress and want to keep using this CMS, but at the same time want to build the website in a professional and flexible manner. After only 20 minutes you can have a local WordPress site fully installed. It only takes 10 minutes of active work to install the necessary programs for WordPress perfect functionality and another 10 more minutes waiting. If you spend an extra 20 minutes you also can install your remote WordPress site.
The Roots.io WordPress workflow solution consists of 3 tools: Trellis, Bedrock and Sage. You can use them together or separately, depending on what you need for your projects.
In this article we are going to focus on Bedrock, but apart from this there are another 2 interesting parts that I recommend taking a look at:
Trellis: allows you to easily and quickly setup the complete WordPress server including possibility of local, staging and production environments. It does everything for you including the possibility of one-click deploy via Ansible.
Sage: It is a starter template that provides an advanced workflow with modern front-end development tools, like Gulp and Bower. There are many projects based on this starter template, just check the official site.
We are going to cover the advantages that Bedrock offers against a regular WordPress installation and why you should use Bedrock for all your projects no matter what size they are. Maybe you ain’t convinced at all about this - if you have been working with WordPress for a few years, you have your routine, tips, tricks... but trust me, it is worth a try.
Let's go on with Bedrock, the reason you are reading this - I'm not gonna make you wait any longer.
Bedrock is a Roots.io project that gives you with a choice of typical environments for development such as production, staging and testing. It brings the modern development tools, folder structure and enhanced security to WordPress development.
Bedrock allows you to manage WordPress core installation / updates and management of plugins and templates the Composer way. For those who don't know Composer (I hope you all do :-)) it is a dependency manager for PHP with numerous advantages like keeping the same versions of libraries across all the developers of the project. It improves collaboration with team members and helps keep the Git repository more clean.
You can install command-line interface, called WP-CLI, which allows you to call many WordPress functions from the command line, for example:
install theme or plugin - means the regular way apart from Composer.
As you probably noticed, you can do Composer way of adding themes and plugins together with the regular way (WP-CLI / WordPress administration).
WordPress is one of the best-known open source CMS out there with a long development history, and therefore most vulnerable and hacked ones nowadays. For example, WordPress uses very old MD5-based passwords, which don't provide enough security for your site, which is an even more worrying factor if you are working with sensitive data.
A solution to these troubles is Bedrock, which provides a plugin to use secure bcrypt hashed passwords instead of that ugly MD5. This plugin is called wp-password-bcrypt.
Let's compare the 2 ways to use WordPress
Regular WordPress use case
To install different plugins or themes you have to use WordPress admin panel and that takes some extra time.
If you want to install a few new plugins you can do it by installing them directly from WP or uploading the zip files. If you try it for only one plugin, it won’t take too much time. But if you need to install like 10 plugins you will need to go through the whole process 10× which is a total waste of time.
You will spend a lot of time performing such manual jobs. That’s not a good approach, as human beings make more mistakes than a machine does on repetitive tasks, and we want to avoid that.
If you've faced some of this problems in the past, I'm pretty sure you will like Bedrock and once you try it, you won't ever look back. After you learn more and more about its functionalities, you will see how it will help you make your life much easier.
To sum up this standard approach:
Long time needed to install new plugins / themes.
Not really flexible control of the new updates (there’s an automatic update mechanism in the core, though, you just don’t have much control over when and how it happens).
You need to keep track of updated plugin versions across all the environments of the website.
If you add a new plugin you need to check that it is activated in another environment - like production or staging.
Innovative Bedrock way
This approach will cause fewer problems, especially by means of automation. You are able to install plugins with one simple command and can have a simple configuration with PHP dotenv.
update – will try to update the packages to the latest version and rewrite
install – will install the specific version which is on
Multistage setup out of the box:
development – for working locally
staging – for tests
production – for your live site
Environment configuration - inside your
config directory, you have a specific file that complements
wp-config for each of our environments, where you can define your specific configurations.
If you are used to working with WordPress you should know the WP-CLI command interface - this tool works in parity with the Composer, which is really awesome. If you run a command with this tool, it will check automatically if you have any Composer file and update it with the correspondent stuff you entered on the command line.
Better project structure - Bedrock allows you to keep all of your code more structured and maintain WP installation on an independent directory called
app directory that substitutes
Let's inspect the file structure in more detail:
composer.json: manage versions of WP, plugins and dependencies
config: here is where you configure WP, the configuration files.
config/application.php: this file contains the primary WP configuration and normally includes the common settings for all the environments. This is the
config/environments: contains environment specific settings, these are preferred over the settings declared on
development.php: development environment configuration
staging.php: staging environment configuration
production.php: production environment configuration
vendor: where the dependencies managed by the Composer will be installed, except for the plugins and themes
web: is the web root, so as not to expose delicate files Bedrock moves required into this directory including the vendor
web/app: this is the old
wp-content, renamed to better reflect its contents. Here is where all your plugins and themes will be installed.
web/app/mu-plugins: Bedrock includes an autoloader that allow standard plugins to be required as “must use” plugins
web/wp: is the whole WP package, it's also managed by the Composer and should go into
vendorbut can't be there because of the WP limitation
web/wp-config.php: is required by WP, but only loads the other main configs; you should never edit this file
Manage dependencies with the Composer- you can manage the installation of WP, plugins and themes using Composer.
If you work with WordPress daily, it is a fact that your whole job is greatly facilitated with Bedrock, where you can manage everything in the most simple way and even automate tasks with WP-CLI.
If you are still reading this, I dare say that I have sold you on Bedrock, so I encourage you to start working with it.
There are tons of documentation about all the possibilities that Bedrock offers on the official website.
After giving a try to Bedrock, you can use complementary tools like Sage or Trellis.
The advantages of Bedrock should be clear now. We are very happy you have read the whole article. The main reasons why we at Kurzor use Bedrock in WordPress development are:
Better project structure.
Support in multiple stages.
Almost everything managed with Composer, saving a lot of time.
Fewer problems and more automation.
We plan to give a try to Sage and Trellis in our next projects. You can continue by reading how we develop in WordPress.