Easy wp-cli automation with wp-bootstrap

I’ve created a PHP Composer package to provide an easier way to automate WordPress installations using wp-cli. If you are unfamiliar with wp-cli and composer. I suggest you read up on composer here, wp-cli here and the rationale of automation in my book or in my blog series on the subject.

Another great resources for learning more about using WordPress, git and Composer together is to check out the roots.io post on the subject as well as their Bedrock project.

What is wp-bootstrap

Wp-bootstrap is a composer package that adds a bunch of commands to your environment that helps you set up WordPress and themes, plugins and settings in a consistent manner using configuration files rather than scripts or worse, point and click installations. Wp-bootstrap depends on two files that it expects to find in your project root folder:

  1. appsettings.json that contains settings, themes and plugins that your WordPress site needs to use. It also has a way to manage some of the content of your application. This file is meant to be a part of your application and managed in a source code control system.
  2. localsettings.json that contains settings that are specific to each environment. This includes database name, password, WordPress installation path and more. This file is meant to be unique to each environment that your site runs in (development, staging, production etc) and is not supposed to be managed by source code control.

By combining these two files wp-bootstrap is able to setup a WordPress installation from scratch, let’s see how.

INSTALLING wp-bootstrap

"require": {
"eriktorsner/wp-bootstrap": "0.2.*"

$ composer update
$ vendor/bin/wpbootstrap wp-init-composer

To include wp-bootstrap to your project, just add the above lines to your composer.json file. Or if you prefer, use this command:

$ composer require eriktorsner/wp-bootstrap
$ vendor/bin/wpbootstrap wp-init-composer

By running the command “vendor/bin/wpbootstrap wp-init-composer” to add the wp-bootstrap commands to composer so that you can call wp-bootstrap easier, this step is not strictly needed.


In addition to installing wp-bootstrap, you also need to have a localsettings to tell wp-bootstrap where to find your database, some of the credentials and where to install WordPress (where the web server expects to serve the files from). Note that your’re not really supposed to install WordPress in the same folder as your configuration files. Here’s a sample localsettings.json file:

"environment": "development",
"url": "www.wordpressapp.local",
"dbhost": "localhost",
"dbname": "wordpress",
"dbuser": "wordpress",
"dbpass": "wordpress",
"wpuser": "admin",
"wppass": "admin",
"wppath": "/vagrant/www/wordpress-default";

I think it’s fairly self explanatory, but here it goes:

  • environment is typically one of the values “development”, “staging” or “production”. A description of the environment that this installation is
  • url The url for this installation
  • dbhost, dbname, dbuser and dbpass are the database credentials. Wp-bootstrap assumes that a database already exists and is accessible using those credentials
  • wpuser, wppass are the credentials for the default WordPress admin user.
  • wppath is the path where WordPress will be installed.


The last thing you need to add is an application settings file. The very minimum file you need to provide is:

"title": "TestingComposer approach";

Title is the only mandatory field in this file, but it’s far from the only one.

Section: plugins:

This section consists of two sub arrays “standard” and “local”. Each array contains plugin names that should be installed and activated on the target WordPress site.

  • standard Fetches plugins from the official WordPress repository. If a specific version is needed, specify the version using a colon and the version identifier i.e if-menu:0.2.1
  • local A list of plugins in your local project folder. Plugins are expected to be located in folder projectroot/wp-content/plugins/. Local plugins are symlinked into place in the wp-content folder of the WordPress installation specified by wppath in localsettings.json

Section: themes

Similar to the plugins section but for themes.

  • standard Fetches themes from the official WordPress repository. If a specific version is needed, specify the version using a colon and the version identifier i.e footheme:1.1
  • local A list of themes in your local project folder. The themes are expected to be located in folder projectroot/wp-content/themes/. Local themes are symlinked into place in the wp-content folder of the WordPress installation specified by wppath in localsettings.json
  • active A string specifying what theme to activate.

Section: settings

A list of settings that will be applied to the WordPress installation using the wp-cli command “option update %s”. Currently only supports simple scalar values (strings and integers)

Using wp-bootstrap

The easiest way to use wp-bootstrap is to simply call the binary file that is added to your vendor/bin subfolder. Using the sample files above, you could do this:

# Install WordPress
$ vendor/bin/wpbootstrap wp-install

# alternate:
$ composer wp-install

After running this command, you should have a fully working WordPress installation, accessible via the url specified in your localsettings.json file. The title of the site should match whatever you specified as the title attribute in the appsettings.json file.

More Settings

So far we’ve managed to reproduce what wp-cli can do in three separate commands, good but perhaps not that great. The real power of wp-bootstrap lies in extending appsettings.json with some more settings. Here’s a slightly more advanced example:

"title": "TestingComposer approach",
"plugins": {
"standard": [
"local": [
"themes": {
"standard": [
"active": "agama"
"settings": {
"blogname": "New title 2",
"blogdescription": "The next tagline"

Using this file, we can customize the WordPress installation with a new command:

# Install plugins, themes etc.
$ vendor/bin/wpbootstrap wp-setup

# alternate
$ composer wp-setup

Let’s walk through this:

  • In the Plugins section, we specify a number of standard plugins that will be fetched, installed and activated from the WordPress plugin repository. The if-menu plugins will be installed with version 0.21, but the rest of that list will just be whatever version that is the latest in the repository
  • We also install and activate a local plugin that will be symlinked from [project root]/wp-content/plugins into the WordPress installation. This is so that we can include our own plugins developed specifically for this project.
  • The themes section works very similar, the theme agama is added to the installation from the WordPress theme repository and it’s also set as the active theme.
  • And finally, the settings “blogname” and “blogdescription” are overwritten with the values specified. These names corresponds to what the settings are called in the wp_options database table.

There are more settings…

If you’re curious enough to try this, I suggest you head on over to the github page for this project. It got some additional settings that you should read up on, especially if you’re keen to manage pages, menus and images in a similar fashion.

I’m also very curious to hear what you think about this, don’t hesitate to let me know in the comments. You can also reach out to me on Twitter with comments or questions.


WordPress DevOps – The book

I’ve written an ebook on this subject. Released in September this year on Leanpub.com. Expect a 100+ tightly written pages where we walk through the creation of the skeleton of a WordPress based Saas application, connected to Stripe and Paypal with a working deployment process that takes content into account. Just add your billion dollar idea. Jump on over to Leanpub to get your copy.

WordPress DevOps - Strategies for developing and deploying with WordPress

WordPress DevOps – Strategies for developing and deploying with WordPress


[wysija_form id=”3″]

Leave a comment

Your email address will not be published. Required fields are marked *