Why You Should Develop Plugins With wp-cli

I started work on a new plugin this week1 and I quickly started running into those little things that add up to a lot of wasted time while developing. So far that’s three things:

  1. Flushing a cache of data I retrieved from an API. (In this case, I process that data before caching it, so changes require a cache flush.)
  2. Saving setting data for the plugin.
  3. Getting the current setting data from the plugin.

In the past, I’ve done all kinds of silly things for these. For #1, I’ve hacked together one-off shell scripts, but usually just threw a delete_transient call in the plugin file and hit refresh. Fun times when you forget to remove that!

For #2, I’ve often hacked together a prototype of the eventual UI, and set up all the various save handlers (because that’s fun in WordPress!) just so that I could get data into the plugin. Oh, and then I change the data structure in mid-development and now I have to change the UI just to get that new data in.2 Fun! Or, when that approach grew tiresome, I’d take a cure from my #1 approach, and maybe hardcode an update_option call, or maybe override the getter function to return hardcoded data.

And #3 just comes in handy as a sanity check to see if the current data is what’s expected. Good for debugging. I won’t detail the hodgepodge of ways I’ve done this, you’re getting the idea.

This time, I started with a simple command: wp sekritplugin flush-cache. Then the curtain was drawn back, and I realized that three common tasks I’ve done in the past could be:

wp sekritplugin flush-cache
wp sekritplugin set --format=json < dummy.json
wp sekritplugin get

The great part about this is that in order to expose this functionality to wp-cli, I have to have it in my plugin, and I'm forced to make cleaner plugin API design decisions.

And here's a familiar scenario: I'm working on the backend of the plugin, while my teammate is working on the frontend UI. I realize there's deficiency in the data structure, and push a change. Previously, this wreaked havoc (been there). But now, I just pop a dummy.json file in our repo that replicates dummy content for the new data structure. My teammate runs:

wp sekritplugin set --format=json < dummy.json

…and is back up and running, no fuss, no muss. They can also look at the changset for the dummy.json file to get a quick sense of how the data structure changed.

Another great thing is that I can leave all of the data saving and validation tasks right until the end, when the data structure is finalized. No wasted time changing things in a rapidly changing plugin.

I'm sure I'll come up with more use cases as I move along, I'm only three days into this particular project.

So, tl;dr: adding wp-cli commands to your plugin is great for:

  1. Encouraging good API design
  2. Collaborating amidst a changing data structure
  3. Efficiency
  4. Better debugging

Commands are easy to write, so what's stopping you?

  1. Actually a ground-up rewrite, so new-ish. 
  2. If the data structure changes didn't break the UI prototype, which they probably did. 

2 thoughts on “Why You Should Develop Plugins With wp-cli

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s