Dictator controls the State of WordPress, and is now available for you to use.
Strongly influenced by Salt provisioning and installable as a WP-CLI package, Dictator now allows you to:
- Export WordPress’ configuration to a human-readable YAML state file.
- Commit the state file to version control to share between environments, or with another developer.
- Compare the state of WordPress to the declared state file, with a colorized diff.
- Impose a state file onto WordPress.
Dictator understands WordPress in terms of states. States are collections of regions. Each state file has the state declaration along with tracked configuration details for each region. Regions have a defined schema which produces the translation between the human-readable YAML file and how WordPress stores state in the database.
One key idea Dictator adopted from provisioning systems: environments are ephemeral. WordPress no longer doing what you want it to? You should be able to destroy it and provision a brand new version.
For 0.1, Dictator packages two states: network and site. The network state comprises regions for network settings, users, and sites. The site state comprises regions for site settings, users, and terms. Management of widgets, roles, and more is just waiting for a pull request.
Think downloading the entirety of a production database is a messy way to get just a few configuration details? Me too — and with Dictator I can provision full WordPress environments without the bad assumptions that come with using production data.
Ever had a site launch that required a frantic amount of widget configuration right after changing DNS? More than I can remember — and I’m automating myself out of the problem.
Think non-posts data portability would be neat? So do I — and I built a tool for it that I’m very excited to share with you: Dictator. Try it out with wp dictator export site site-state.yml
10 Comments
Thank you for making this. I’ll definitely try it out and let you know how it goes 🙂
“Ever had a site launch that required a frantic amount of widget configuration right after changing DNS? More than I can remember — and I’m automating myself out of the problem.”
LOL… soooo many times. I startd using https://wordpress.org/plugins/widget-settings-importexport/ which uses a standard JSON format one can edit directly without TOO much difficulty, but YAML looks way easier.
Looking forward to checking this out. Thanks!
Daniel, this is fantastic! Loving the idea of implementing this as states. It makes a lot of sense.
It also looks extremely useful to “provision” new sites in a network without writing boilerplate code!
Over the past few months I’ve been working to automate our development setup process as much as possible. This just adds one more layer on top everything else. Utilizing Vagrant, VVV, WP-CLI and some others we’ve cut our dev time by more than half.
Thanks
@aronwp
Hi–can you explain to a noob the difference between this and version control?
Dictator is a compliment to version control, in fact. The idea is that you can export how WordPress is configured to a human-readable version you can commit to version control.
I have similar question: does it provide kind of “dev” and “production” environments, where we can develop on “dev” environments and when everything is good, we push to production (and if not we can roll back)? I know version control can do that, but in terms of managing both files and database, VC seems not a good solution.
Sure — in the sense that you can commit a state file to version control, and “back up” the current state of production by doing an
exportright before animpose.Any chance we can get an example of how to use Dictator::addstate(); to, say, save individual plugin or theme options to the config file?
The details are intentionally vague right now because the
Regionconcept needs to be formalized before I want to commit to it.I’ve opened an issue to track the conversation.