Tracking versions of WordPress plugins in theme directories

On WordPress projects where the entire application is defined by the theme, it can be common to submodule or directly commit WordPress plugins to a directory like theme-name/lib. However, in doing so, you lose out on WordPress’ built-in update tracking.

It would be cool to have a utility plugin that loads theme-specific plugins into the Manage Plugins view and WordPress update check.

WordPress theme for WP REST API documentation

Much of the WP REST API v2 documentation is automatically generated from demo.wp-api.org/wp-json/?context=help. A Ruby script dumps the JSON into _data, and Jekyll generates pages like this:

2016-01-13 at 12.22 PM

It would be cool if someone wrote a WordPress theme (or plugin) to automatically generate a documentation site from a WP REST API index — and the only configuration parameter was the URL to the endpoint.

RESTful WP-CLI – The journey begins

This post originally appeared on the WP-CLI blog.

And so the journey begins. As with most journeys, I have a mixture of emotions: excitement, anticipation, trepidation, and eagerness. Although the destination may be far away, I know I can get there as long as I consistently take steps in the right direction.

Today marks the formal kickoff of my Kickstarter project, “A more RESTFul WP-CLI”. To celebrate the occasion, I’ve launched a project page to capture high-level goals and document my progress along the journey. I’ll keep it updated as I write blog posts every couple or few weeks. Consider these blog posts both a development log and an invitation to participate — I look forward to your comments, issues and pull requests.


For the past month or so, the question at the top of my mind has been: what does it mean to “unlock the potential of the WP REST API at the command line”? Or, even more broadly, why do this project?

These are big questions, and I consider myself fortunate to be able to explore them over the next six months or so. Here’s how I’ve unpacked them so far, in a series of loosely connected ideas:

  • WP-CLI’s goal is to be, quantitatively, the fastest interface for developers to manage WordPress. For anything you want to do with WordPress, using WP-CLI should save you multitudes of time over doing it some other way.
  • WP-CLI and WP REST API both offer CRUD interfaces to WordPress resources. wp post list is more or less GET /wp/v2/posts. But, wp widget list doesn’t yet have an equivalent in WP REST API. We still have a ton of work to do.
  • Building the WP REST API has been, and will continue to be, an exercise of modeling how WordPress works to a consistent (RESTful) interface. Furthermore, this model is declared in a common language for clients to interpret.
  • At some point in the future, WP-CLI will be able to ditch a substantial amount of its internals when it can use the WP REST API as its interface to WordPress. WP-CLI can continue to serve as the fastest way for developers to manage WordPress, offering higher-level meta operations like generate, (push|pull), and clone in addition to being a seamless command line interface to WordPress internals.
  • As WordPress developers write new endpoints for the WP REST API, it will be quite powerful to have those endpoints instantly accessible through the command line, and as accessible as core resources. For instance, where WP-CLI currently has the wp post * commands, WP-CLI requires Easy Digital Downloads to produce its own wp edd * commands.
  • It appears to be supremely possible to deliver this project as a series of improvements to WP-CLI, shipped over one or more versions in the next couple of quarters.

Lots of threads to pull on.


I’m starting development by working towards making wp tag list work interchangably with local and remote sites. Doing so already raises a few issues:

  • WP-CLI needs to be easier to register commands on the fly. In my prototype, I had to eval() a dynamically generated class. It would be much nicer to be able to register an arbitrary function, closure, or method as a WP-CLI command.
  • When we register REST endpoints to WP-CLI on the fly, there’s the potential for them to conflict with existing commands. Furthermore, the endpoints will vary from site to site. Ideally, the commands you see should represent the commands available on the target site. I think site aliases may offer us a backwards-compatible implementation; for instance, specifying an alias like wp @prod would only expose commands available on production.
  • Remote calls will need authentication. Ideally, it should be possible to authenticate once through a supported protocol (basic, oAuth1, API key, etc.), and store these authentication details somewhere on the file server. This is potential rationale for a config management command. If you aren’t blocking web requests to wp-cli.yml and wp-cli.local.yml already, you should be.

Using HTTP DIGEST authentication with WordPress’ wp_remote_get()

HTTP BASIC authentication (Wikipedia) is a form of client / server authentication where the username and password are base64 encoded in the request header. However, because these credentials can be easily decoded, BASIC authentication requires SSL for the request to be secured.

HTTP DIGEST authentication (Wikipedia) permits more secure communication between the client and server over insecure HTTP. It’s also a fair bit more challenging to implement, for a couple of reasons:

  1. Every API call actually requires two HTTP requests. Although the first request will fail with 401 Unauthorized, it returns a www-authenticate response header with values critical for signing the second request.
  2. Sending the second request requires creating a signature with several variables where the order matters. Because of the number of variables (pun intended), debugging authentication failures can be very frustrating.

To make HTTP DIGEST authentication requests easier in WordPress, here’s a function you can use:

Measuring the utility of WP_REST_Posts_Controller

A good measure of the utility of WP_REST_Posts_Controller and brethren would be to test how much (or little) time it takes for a developer to correctly model their custom post type data by extending it. If it’s easy to do, then we’ve established a great abstraction. If there are pain points or places we need to work around, then we should refine the abstraction.

Simple WP-CLI backup and restore

It would be neat if WP-CLI included a rudimentary backup and restore process for this use case:

richard.tape [8:19 AM] anyone used wocker? I’m looking to set up a dev environment that I can share with someone else so they’re able to more easily help me debug a problem and I want to modify the base containers and then package the whole thing up so I can just pass that to them and they just spin it up and are in the same shape I’m in… ideas?

wp backup would create a tarball of the database, WordPress files, and (optionally) the uploads directory. wp restore could then read said tarball, and expand it to a working WordPress install.

We could even potentially parse the original wp-config.php into a manifest file, which would permit the restoration process to override some details.