Version 1.2.1 released

As it turns out, refactoring can introduce bugs. Who knew?!

WP-CLI v1.2.1 fixes a few regressions introduced in v1.2.0:

  • Properly registers commands to existing namespaces when defined by plugins [#4123, #4130].
  • Restores compatibility with using WP-CLI as a dependency of a Composer-based WordPress install [#4126].
  • Only forces use of /usr/bin/mysql on *nix systems [#4132].
  • Improves wordwrapping by using total columns in terminal, instead of an arbitrary width [#4133].

Want to help us catch these bugs earlier? Run wp cli update --nightly in your local and staging environments to use the latest and greatest.

Contributors to this release (4 total): danielbachhubergitlostschlesseraszepeviktor

Command dependencies revisited

As I already described in Managing command dependencies, we have added two hooks that allow developers to explicitly state what type of requirements need to be fulfilled before loading their custom command.

This works just fine when you know about these hooks and make proper use of them.

But there’s a large number of third-party commands out there already that are not yet making use of these new hooks, obviously. As we want to provide a safe update path, we had to look into providing a mechanism for the commands that might break due to the bootstrapping and package distribution changes.

Automatic dependency resolution to the rescue

As it turns out, having these hooks available makes it very easy to solve the dependency resolution in a fully automated way.

If a sub-command depends on a parent command that is already registered, or if a command does not have a dependency at all, we add the command immediately, just as before. This is the standard behavior.

If a sub-command depends on a parent command that is not yet registered, adding the sub-command immediately would just break. Imagine wanting to add a scaffold my-plugin sub-command, when the scaffold command has not yet been registered. In this case, we hook up the sub-command addition to the after_add_command:<parent command> hook, and add the command to the list of deferred command additions.

Once we add a deferred command when its hook has been triggered, we remove that command from the list of deferred command additions.

If we processed all commands, any remaining additions on the list of deferred command additions are executed as a final step. This is needed for sub-commands like network meta, where the parent does not actually exist (and thus, the after_add_command:<parent command> hook is never called).

Backward compatibility and ease of use

With the above mechanism, all current commands that relied on the fact that bundled commands were always loaded first will still work, even if the bundled commands might now be loaded later, due to the fact that all bundled commands have been split out into their own packages.

What’s more, any command depending on any other command will now just work, no matter what the loading order is, as long as both commands are loaded eventually.

Good first issues for new contributors

Want to submit your first pull request to WP-CLI? We’ve identified a few good first issues for new contributors to get their feet wet:

Read through the contributing guide for details on how to get started, or join us in the #cli channel with any questions you might have. Office hours are today, Tuesday, April 25 at 16:00 UTC

RFC: Usage analytics and WP-CLI v2.0.0

There are two issues in the backlog we’d love your input on:

  • Capture and report anonymized usage statistics (scheduled for v1.3.0) – In addition to the data points listed, what others might be worthwhile to capture? And, are there other aspects to the project we should consider?
  • WP-CLI 2.0.0 (scheduled for late 2017) – What breaking changes should we consider and why?

Feel free to weigh in as you see fit.

 

New support venue: WordPress.org support forum

Have a question about something related to WP-CLI? There are now two places you can go for general help:

  • Join the #cli channel in the WordPress.org Slack to chat with whomever might be available at the time. This option is best for quick questions.
  • Post a new thread in the WordPress.org support forum and tag it with ‘WP-CLI‘ so it’s seen by the community.

Want to help others with their use of WP-CLI? Click “Subscribe to this topic tag” to receive email notifications of new forum discussion:

GitHub issues are meant for tracking enhancements to and bugs of existing commands, not general support. Use the wp-cli/ideas repository to up vote existing ideas or share your own.

Planning for Community Summit 2017

In preparation for the 2017 WordPress Community Summit (“CS”) on June 13th-14th before WordCamp Europe in Paris, France we’ve been asked to provide the following (in summary):

  1. A list of topics for the CS
  2. A list of representatives to attend the CS
  3. One or two contributors who are willing to help with the organization of the CS

This post serves as a request for input for the above three areas. Note that these three requests are detailed further with some clarifying notes on Make/Summit.

Feel free to ping me privately in Slack if you prefer. I will send a summary of the responses with the Community Summit team on Wednesday, March 1st (as I’ll be offline on Thursday and Friday).

New home for WP-CLI docs

WP-CLI’s long-form documentation has a new shiny home: make.wordpress.org/cli/handbook

2017-01-26 at 3.47 PM

Want to suggest an edit?

Click on the “Edit” next to the title to submit your changes via pull request workflow. The documents are tracked in a GitHub repo for easy collaboration. Just like with code changes, documentation contributors receive credit in every WP-CLI release.

Have five minutes to make the documentation better?

Read through the handbook and open an issue with ideas on how we can improve or expand upon our documentation.

Happy scripting!

What do you wish you had a WP-CLI command for?

At the heart of it, WP-CLI commands enable you to do anything you want with WordPress, faster. Performing some task at the command line almost always yields some (often huge) amount of efficiency gain over the alternative.

For instance, consider the following (from #2523):

Using the theme list command without url parameter shows if a theme is enabled for the network and active in the default site.

If you pass the url of a site of the network, this command shows if a theme is active in that site.

But i can’t find a way to list which themes are inactive in every site of the network so i can safely disable and delete them, and i’d love to have this feature

Without WP-CLI, you’d need to:

  1. Find an intern.
  2. Prepare a spreadsheet of all sites and themes.
  3. Have the intern go through each site to log the active theme on your spreadsheet.
  4. Evaluate the spreadsheet to determine with themes can safely be deleted.

With WP-CLI, you can simply run wp find-unused-themes. Pretty much infinity time savings.


So, what do you wish you had a WP-CLI command for?

Now you have a place to request them. Head over to the new wp-cli/ideas GitHub repo and file issues to your heart’s content.

There’s no such thing as a bad idea. We’ll implement the best, and maintain them as canonical WP-CLI community packages.

But wait, how will you pick which ideas to build?

That’s a great question — I’d love your input on how to decide.

The end goal for the WP-CLI package index is to be a directory of well-maintained, canonical features. Packages will be considered community projects shepherded by one or more maintainers, instead of the domain of a specific author. There’s a two-fold benefit in taking this approach:

  • You (as a WP-CLI package author) will feel less burdened in maintaining your package, because you have supporting resources to help you out.
  • You (as a WP-CLI user) will have greater confidence in using the packages in the package index because you know there’s a small community of maintainers around each of them.

But, we need to work out how we get from 0 to 1 (idea to initial implementation), and then 1 to n (ongoing development and maintenance).

But wait, who’s “we”?

That’s a great question too.

I’m now actively looking for someone to help me run with this vision. They’ll focus on facilitating great community packages: soliciting and vetting ideas, establishing best practices and standards, and supporting package maintainers. The best candidate sweats the little details, and commitment is already a part of their track record.

In the near future, we’ll be looking for people to maintain packages in the directory. Our goal is for maintainership to be a rewarding, enjoyable experience — and for maintainers to extend the same to contributors.

Know anyone who might fit either of these roles? I’d love to hear from you. Email daniel@handbuilt.co or ping ‘danielbachhuber’ on the WordPress Slack.

Hello world!

Supporting the Future of wp-cli

How much is WP-CLI worth to you?

Update 3 12/28: WP-CLI is now an official WordPress project. Fundraising will continue into 2017.

Update 2 12/15: Undecided on how much WP-CLI is worth to you? The experiment ends Dec 28th — please make a decision by then 🙂

Update 1 (12/13): Up to 17 subscribers so far. If we can get to 50, I’ll launch a members-only forum.

Last week, I tweeted:

At a decision point with @wpcli: it’s too large for me to voluntarily maintain. Have an opinion on its future? I’d love to chat.

Last February, I started a business, runcommand, as an indirect way of being able to invest my time into WP-CLI. The business is doing alright, not great but not horrible. What I’ve come to realize, though, is that my time is zero-sum. I’m incentivized to spend time on runcommand, when I’d rather spend it on WP-CLI.

Ultimately, the challenge I’m running into is opportunity cost. I’d love to be able to invest more into WP-CLI, but doing so comes at the cost of other business pursuits. Because WP-CLI is such a large project, the several hours I volunteer each week are basically enough to fight entropy — not make headway on larger initiatives.

The response to my tweet has been overwhelmingly supportive. One future I’m considering is directly commercializing WP-CLI, through patreon-esque membership, advertising on the website, and other ideas to be determined.

So, dear reader, a question: how much is WP-CLI worth to you?

Or, phrased another way, how much time does WP-CLI save you?

If the experiment goes well, then we’re in business! Your purchase will support ongoing maintenance of WP-CLI, as well as development of new commands like wp doctor and wp profile, improvements to the website and package index, and so on.

If the experiment doesn’t go well, then at least I can say I tried 🙂 To avoid any risk with the investment above, a full refund will be made available to you should the campaign not reach its goal, before we look at other approaches to help with maintaining the project.

Happy to take any questions you might have: daniel@runcommand.io. I’ll keep the list below updated as new questions come in.


Have you tried crowdfunding?

Yep! See the post I wrote, “Using Kickstarter to fund open source“. Nadia Eghbal has a series of great articles on open source sustainability as well.

How much money do you want to see to consider this a success?

I have a number, but I’m not going to share it. I want to see if this is a viable approach for funding a for-profit business.

What if I want to pay a different amount?

Email me, and I’ll create a purchase link for you.

Do I get anything special for paying the amount I paid?

Potentially, but nothing to announce at this point.

I do have some ideas in mind for offerings at different levels (e.g. members-only support forum, feature prioritization, etc.).

Do I need to keep paying after I pay the first time?

Well, if everyone cancels, then the business will tank 🙂

All levels are billed annually unless you disable automatic renewal.

What if I’m an existing runcommand customer?

If the experiment goes well, then wp doctor and wp profile will become completely open source. I’ll reach out about the other aspects of your purchase.

What about scribu and Andreas?

I’ve been talking with them a bit. We’re all very interested to see how this plays out.