Diving into Dictator: A Provisioning Tool for WordPress

Some of you may have seen the announcement of a new WP-CLI package known as Dictator. Dictator allows you to define the “state” of your WordPress install. It keeps a running record of your WordPress configuration options, broken up into three categories.

“Settings” stores basic site information like title, description, and active theme and plugins. “Users” stores the name, email, and display_name of each user. “Terms” holds categories, tags, and other post metadata. All of this information is stored neatly in a small YAML config file. That way, you can hand off a config file to various members of a team, and they can have an exact replica of your WordPress site up and running in minutes. No complicated database migrations. Simply record the state of WordPress, and pass it on.

Installing WP-CLI

First of all, Dictator is for developers. It assumes a pretty high comfort level with the command line and basic WordPress development.

Dictator is a package for WP-CLI, which is a set of command line tools for working with WordPress. I won’t go into too much detail in this article, but make sure that you have Composer and WP-CLI installed.

Your other option is to use a development environment. I prefer Varying Vagrant Vagrants (VVV), which gives you Composer and WP-CLI for free.

Once you have WP-CLI up and running, and a new WordPress install running alongside it, you will need to install the package manager.

If you’re developing in VVV, then you can simply navigate to the wp-cli folder, open up “composer.json” and add it just underneath the “require-dev” section.

"repositories": {
    "wp-cli": {
        "type": "composer",
        "url": "http://wp-cli.org/package-index/"
    }
},

If you are running WP-CLI in another environment, there are step by step instructions and a pre-coded script that can help you get started.

Installing Dictator

Ok, now you’re ready to install dictator. From your terminal, simply run:

composer require danielbachhuber/dictator=dev-master

You will now have access to the wp-cli dictator command. If you set up WP-CLI to include an alias such as “wp,” then you can use “wp dictator” to run your various commands. Let’s start small. Run this line of code:

wp dictator export site site-state.yml

This will give you a YAML site state file that describes the set-up of your WordPress install, including active themes and plugins, user info, and term meta.

If you are running a multisite, use:

wp dictator export network network-state.yml

You’ll be given general information about the network of sites that you have.

Now, simply change the file a bit. Erase something, or add a new plugin. Then run:

wp dictator compare site-state.yml

You’ll see in your terminal window a brief description of what is different—colorized and highlighted. What Dictator is really doing is checking your WordPress install against the settings in your config file and highlighting the differences for you. That comes in handy.

When to Use Dictator

Dictator can be used a few different ways. At its most basic core, it’s a way to move configuration details (other than post data) without having to bring the database along. This makes it a powerful provisioning tool to set up local and development environments, with a few use cases.

As a tool to help teams keep configurations in sync

At the moment, it’s hard to keep everyone on a team in sync with one another. Even if you have a shared git repo that has all WordPress core files, theme files, and plugin files—it’s impossible to define which themes and plugins should be activated, and basic configuration options. The only way to do this is to pass around the database with it. The process gets messy quick.

With Dictator, you have a fairly simple workflow. At any point, you can export your configuration.

wp dictator export site site-state.yml

Then include this file in a git repo. When a developer pulls down that file, they can quickly check how their WordPress configuration differs from the master by running:

wp dictator compare site-state.yml

Or, they can choose to change the settings automatically to match the included configuration by using dictator’s impose feature:

wp dictator impose site-state.yml

When the impose command is run, the current WordPress install will automatically change the settings of wp-admin to match the existing YAML file. So plugins can be activated or deactivated, the site name can be changed, categories can be added, etc. All from the command line. Simply pass this configuration file between team members and keep everybody in sync.

I’d like to see Dictator include plugin specific configuration files in the future—possibly in separate files, so these can be passed along as well. But that may be too heavy for the current iteration.

As a quick provisioning and testing tool

I do a lot of testing and WordPress development. Each time I do, I have to get a site up and running with my favorite plugins and basic options. WordPress import/export helps a little, but that can only do so much. But now, every time I want to provision a new site, I can use WP-CLI and Dictator, all from the command line. For instance, let’s say I wanted to get a site up and running quick. I can keep my master Dictator YAML file saved somewhere, copy it into a new folder, and then just run a few commands.

wp core download
wp core config --dbname=newdb --dbuser=root --dbpass=root
wp db create
### Omitting some flags here
wp core install
wp plugin install user-switching query-monitor --activate
wp dictator impose site-state.yml

And just like that, I have a new WordPress install, with several of my favorite plugins installed and activated. Then with Dictator, I can import all of the settings with one line of code, so my WordPress install is fully provisioned and ready to rock.

As another means of version control

Another potential use for Dictator is to simply act as an extra layer of version control. If you’re using a version control system like git or SVN, you can introduce the creation of a Dictator config file into your commit build step. That way, each time a new commit is made a timestamped or other meaningfully labeled config file is produced at the same time. It adds an extra level of protection if you need to revert back to a previous step, but forgot what your configuration was.

Dictator is still very much in its early stages, but I think it’s something we’ve been looking for. I think it marks an important step towards making WordPress appear more lightweight and more portable. If we use it, we can test it, add to it, and make WordPress that much better.

How would you use Dictator? Let me know in the comments.

---

Jay Hoffmann is a WordPress developer hailing from NYC. In the strictest sense of the word, he is a WordPress enthusiast with an eye for front-end development and design. He has been working with WordPress since 2006 and currently works for a popular children’s media company. This year, Jay started Tidy Repo, a curated list of the best and most reliable plugins from around the web. You can also follow Jay on Twitter.