So you have developed (or starting to develop?) WordPress plugins and/or themes and have come to the point where you don’t want to repeat yourself by following all those (exhausting) steps to create something cool you have in mind.

Thats where Boots comes into play, allowing you to enjoy while you bring  those cool ideas into life. Let’s see how we can get started.


Boots can be downloaded either via Github or via Composer.

via Composer

This is the preferred way of downloading Boots. After installing Composer in your system, cd into your plugin/theme directory in terminal and run the following command (without the $ sign).

This will download the dev-master version of the framework (as it is currently in beta release) into the root of your plugin/theme directory

via Github

You can optionally download boots via Github. Unzip it, rename it to ‘boots’ and move it to the root of your plugin/theme directory. Note that this is not the preferred way of downloading the framework because you still need to install the default (or any) extensions via Composer.

Hook up

For demonstration purposes, we will hook things up as a plugin. The same would go for a theme (functions.php) nonetheless.

Create a new .php file in your yet to build (if your creating from scratch) plugin folder. Name the file whatever you like (as usual). Look at the code below and we will see through it shortly.

We reference the boots api class on line 14.

Coming to line 16, we create the application settings array. ABSPATH should remain as is. This basically will hold the path to the current file. APP_ID is the unique identifier of your plugin. APP_NICK refers to a pretty name of your plugin (usually your plugin name). APP_VERSION will hold the version of your plugin you are working on. APP_MODE is optional and defaults to ‘live’ but should be set as ‘dev’ when you are developing. Change it to ‘live’ or remove the statement completely before you release your plugin (your choice). APP_ICON and APP_LOGO are optional and (if used) should contain the file uri to the respective images and have dimensions of 20px/20px and 64px/64px respectively.

We instantiate the Boots class on line 25, passing on ‘plugin’ (‘theme’ if using in a theme) as the application type. The second and final argument is the settings array that we created on line 16.

The settings array is passed by reference and gets updated with all the application settings (plus some useful extra suff).

Only variables can be passed by reference.


So what’s next? Well as you (may) know, Boots is modular and uses extensions robustly. Some are dependant, others are standalone. Having that said, lets dig into extensions.

Extensions can be installed via Composer.To install an extension you first need to edit the composer.json file.

Lets see how we do this by installing a sample extension for the boots framework.

Installing an extension

Open up composer.json file located inside the root of the boots directory. At the bottom of the file, you will have something like this:

We will install the Enqueue extension as a sample, so modify the composer.json file to look like this:

On line 30, we have added the “<vendor>/<extension>”: “<version>” format string for the Enqueue extension under the “require” (line 29) section.

This is basically how composer manages dependencies. The composer.json “require” block, simply tells composer, “Hey, you are about to install me, hang on, I require the following packages/libraries, so load them up as well!” You can learn more about how composer works.

You can add more extensions by separating each with a comma.

Lastly, to download/install the extension(s) you listed, you need to run the following command in terminal.

You need to cd into the boots directory to run the above command.

The install command not only downloads the extensions, but also runs some useful scripts behind the scenes. These tasks are limited specifically for our boots extensions.

Behind the scenes

When you run  composer install, composers normal operation (besides more tasks) is to fetch the packages listed in the “require” section of the composer.json file and store it in a vendor/<package-vendor>/<package-name> directory. But behind the scenes, this is what happens:

Post extension installation

After an extension (package) is downloaded to the vendors directory, the Boots installer script checks the version of the extension and modifies the ‘class name’ in the extension file accordingly. Then it writes that information to a boots.json file inside that package directory and copies the package over to the boots/extend/ directory.

Post installation wrapup

When the install is finished, the Boots installer script removes the vendor directory because it is neither required in development nor in production and simply contains a copy of all the extensions that were installed plus some autoload stuff which is obsolete in our case.

You can override the default behaviour of removing the vendor directory by answering ‘n’ to the question that comes up after you run the install command. This may benefit if you don’t want to download the entire extensions over and over again when updating/adding more extensions.


Okay, so we know how everything works and its time to consume them. Lets browse the extensions.