WordPress Bedrock: environment variables and plugins as dependencies

In the last article, I talked about migrating the WordPress project to Git and deploying it via D2C panel. That way is acceptable. However, it has a number of drawbacks: you have to create 2 configs, each time you should request the file system, access details are stored in the repository and you should upload and update all the plugins there. Now I’ll tell you how to eliminate these shortcomings at once.

Artyom Zaytsev


What you need

To implement the idea I will use Bedrock, create a few environment variables and make some changes in composer.json.

Why Bedrock

Bedrock is an add-on for WordPress website development. It improves the project’s structure. The variable parts of the application and the WordPress core are separated, the “Composer” is used to manage dependencies, and the entire configuration is done using environment variables.

The “Bedrock” would be ideal for our task. We will not need to store all plugins and WordPress core in the same repository with the application. We’ll be installing them from packages every time we update the source code. The configuration we’ll be stored directly in the service, not in the Git. Here we go.

Step 1. Creating dev-version locally

You’ll need a Composer, if you don’t already have one. If you are running Windows, it will be enough to use the installer. For Mac OS and Linux, you will have to install it via command line.

Now we’ll create a remote repository and clone it to a clean folder with the future project on the local machine.

I use Bitbucket and SourceTree, it’s comfortable for me. If you have not worked with Git before, I recommend to go through the tutorial on creating a repository and working with Source Tree.

Next, in the created empty folder, you need to deploy Bedrock. There are two ways to do this:

1. With the commandcomposer create-project roots/bedrock

2. Clone or download the source code to your folder and execute command composer install.

Note that during the installation Bedrock has already installed the WordPress core and the necessary plugins for its work. The WP installation itself is stored in the /web/wp directory, and the /web/app folder stores plugins, themes, and downloads.

The mu-plugins directory stands for “must to use plugins”. Here are stored plugins that must be necessarily active after the deployment, they will also not be possible to deactivate in the admin panel. All other extensions are stored in the plugins folder.

To specify access details for the database and other settings, you need to create an “.env” file in the root with such content:


# Optional variables
# DB_HOST=localhost


# Generate your keys here: https://roots.io/salts.html

Step 2. Specifying the required plugins as dependencies

First, let’s define the plugins that are freely available through the official catalog. The composer will install them from https://wpackagist.org. For example, I will add WP Supercache plugin.

First, we need to find the package, make sure it’s there and see what versions are available.

The package is called wp-super-cache, the latest available stable version is 1.6.4

We’ll add it to the composer dependencies with such a command: composer require <namespace>/<packagename>:<version>

composer require wpackagist-plugin/wp-super-cache:^1.6.4

In this case, I put “^” before the version and now composer will be installing all new versions without critical changes up to 2.0.

If the plugin is not in the official directory, the task becomes a bit complicated. To add an extension to the list of dependencies which is not available in public, you need to create a separate repository for it and describe the sources in the composer.json file with such content:

	"name": "evilmarketer/projectbundle",
	"description": "Improve your work",
	"keywords": [
		"project bundle"
	"homepage": "https://homepage",
	"license": "GPL-2.0-or-later",
	"authors": [
			"name": "YoYO",
			"email": "support@yoyo.com",
			"homepage": "https://youhomepage"
	"type": "wordpress-plugin",

In my case, I use a private repository, so authorization will add to us additional complexity. To solve the problem we should create an auth.json file at the root of the project on Bedrock with the following content:

    "bitbucket-oauth": {
        "bitbucket.org": {
            "consumer-key": "YOURKEY",
            "consumer-secret": "YOURSECRET"

Consumer key and secret can be obtained from the Bitbucket settings/OAuth section.

Let’s add one more repository in composer.json to an existing “wpackagist”. You should see something like that:

 "repositories": [


     "type": "composer",

     "url": "https://wpackagist.org"



     "type": "vcs",

     "url": "https://bitbucket.org/evilmarketer/projectbundle"



Now let’s execute the such a command: <owner>/<repo>:<dev-master>

composer require evilmarketer/projectbundle:dev-master

Done. The required plugin is added to the list of dependencies.

Step 3. Pushing changes to Git and deploying the project in D2C

Generally, you’ll be working with a theme in web/app/themes folder. At first, I recommend working directly there. In theory, you may create a separate repository for the template and specify it as a dependency, as in the example with own plugins. However, such a solution, in general, will be unnecessary and will add inconveniences on deployments. So lets our theme will be in the web/app/themes folder.

We need to make a commit and push it to a remote repository (bitbucket, in our case). Now the project is ready for deployment.

Bedrock deploys very easily. To do this, we’ll take “php-fpm” service and specify:

1. Repo link.

2. ‘Composer install’ command in local dependences.

3. Same as in .env file we’ll specify Environment Variables. The result should be something like the following:

In “WP_SITEURL” you should specify a path to “/wp” folder

4. In configuring NGINX in the “server > root” section we will also add the path to the /web folder. It should look like this:

root /var/www/$serviceName/web;

one. Passwords are not stored in our repository, and the necessary plugins are installed as dependencies. Awesome!

To be continued

In the following, I will tell you about Sage and compiling your assets in a bundle on deployment.