For the last couple of years, WP-CLI has been changing the way developers work in WordPress. WP-CLI helps developers take regular, repeat tasks and automate them using a set of command-line tools for managing WordPress-installations. Using the interface, you can update plugins, set up multisite installs, and much more, without using a web browser. This helps developers take tedious, manual tasks and automate them for a more efficient workflow.
WP-CLI is essential to WordPress core and therefore, it is essential to our customers. WP Engine is proud to be a co-sponsor for the WP-CLI project. This is the second consecutive year WP Engine has sponsored the WP-CLI efforts by contributing $15k to the project.
Since becoming an official part of the WordPress open source project in 2017, the project has evolved. To learn more about WP-CLI, we sat down with Alain Schlesser, the current maintainer for the project.
You recently took over the WP-CLI project from Daniel Bachhuber. What made you decide to step up and do that?
I started getting properly involved with WP-CLI when I first joined as co-maintainer for the project. During that time, both Daniel and I split up the maintenance work and responsibility and continually tried to figure out how to make this process as frictionless as possible. We often ended up having diverging opinions on how things should be handled, coming from a different background, but I usually relied on Daniel’s more extensive experience in this particular project and would go with his final say.
I suspect Daniel was already thinking for some time about slowly pulling back from the project, having already invested many years with absolute dedication (you’ll have to ask him yourself whether that’s really the case, I guess). At one point, he suggested for him to skip an entire release so that he wouldn’t be a restricting factor for me to own the entire process.
Shortly after that release, when it was clear that we didn’t face any major difficulties and the release was of reliable quality, he asked me about my thoughts on taking over maintenance completely.
I have to say that I did put a lot of thought into this before giving my final “yes.” Maintaining WP-CLI is a big responsibility, as it is a critical piece of infrastructure for a large number of actors in the WordPress space.
But I like the particular combination of code and technologies it represents. It also provides an opportunity for me to work on open source software in both an impactful and sustainable way.
How has WP-CLI evolved in the last year?
WP-CLI started out as a very rough hack on top of the (at the time also very rough) WordPress Core.
Over time, WP-CLI’s importance has grown to a point where it has more and more impact on WordPress Core itself—to the point where code paths in Core have changed so that they better fit the requirements of WP-CLI.
This has not only allowed for WP-CLI to become cleaner and more straight-forward over time but it has also cemented its position in the ecosystem.
More recently, it has joined the WordPress project as an official team, and can thus make use of the infrastructure that the family of wordpress.org sites and associated services provide.
Finally, it has moved from a monolithic piece of code, over to a modularized framework with its own package manager, up to where we are now where individual commands can be included as requirements of a site project without even pulling in WP-CLI as a whole. Any client project, plugin or theme can now make use of its own custom commands in a streamlined and efficient way.
What has been the biggest success for the project this far? What has been the biggest struggle?
The biggest success definitely has to be the wide adoption it has managed to achieve. There’s hardly a hosting company, control panel, automation tool, or related service that doesn’t rely on WP-CLI. It has become a critical piece of infrastructure and will be going strong for the foreseeable future.
The biggest struggle is finding enough regular contributors that can grow into key roles, as it requires a very diverse skillset. It does not only cover a lot of technical areas but also spans the whole of WordPress Core use cases. A lot of contributors focus on specific areas that map to their strengths, but it is rare to find developers that can work on the whole of WP-CLI with confidence. This is then further amplified if you are looking for people to help with documentation, as they quickly get stuck on the technical nuances.
What will the WP-CLI project focus on in 2019 and how will that benefit the WordPress community?
My main focus for 2019 is to improve the scaffolding tools in WP-CLI in order to establish it as the sort of go-to code generation tooling you can also find in other projects like the artisan command in the Laravel framework.
This not only makes development faster and more convenient, but it also establishes conventions and a baseline code quality that naturally educates people on how to best go about solving particular programming problems.
I’d like for WP-CLI to smartly educate people on best practices and elevate the general code quality in the WordPress space as a by-product. This benefits all parties involved (more scalable code is easier to host, better-perceived code quality leads to higher average salaries, embracing more best practices attracts more cross-framework collaboration, and more diverse skill sets, …).
Who all is currently involved in the WP-CLI project?
That is actually quite difficult to answer. Right now we have a group of people who have permissions to actually commit changes to the source code in use. These are currently (in alphabetical order): Daniel Bachhuber, Pascal Birchler, Jon Desrosiers, Takayuki Miyauchi, and Siddharth Thevaril.
But there is a large number of contributors that keeps growing. We usually keep statistics and props in the release notes for each release. As an example, 39 contributors collaborated on the most recent v2.1.0 release.
What important lessons have you learned as a co-maintainer of a popular open-source project?
I personally learned two big lessons through collaborating on WP-CLI maintenance with Daniel Bachhuber.
- There’s a time for a properly engineered solution, and there’s a time for a pragmatic solution. No single approach wins all the battles, you need to be able to pick the right approach in the right context.
- Always give immediate feedback on new issues or pull requests, even if you don’t yet have anything meaningful to say. Often times, not answering to an issue or PR right away because you still want to figure out more details means the original reporter doesn’t get the impression that something is happening at all. Even worse, when you need to deal with a lot of distractions, you can easily forget that feedback you were still going to post later on… and find out three months later you dropped the ball on that one.
What are your three favorite and most helpful WP-CLI commands?
For a developer, one of the most useful ones has to be wp shell. It allows you to enter an interactive PHP shell after the entire WordPress stack has loaded (including plugins and themes). This allows you to run arbitrary PHP code and examine output. What’s more, if you install an additional package using the command “wp package install schlessera/wp-cli-psysh,” it will use PsySH, a debugging shell on steroids.
Another one of my favorites is wp config, which lets me quickly change settings on a site like turning WP_DEBUG on or off. The wp config list subcommand also lets you conveniently search for specific settings you might need.
Finally, the wp search-replace command is an indispensable tool for anyone dealing with WordPress sites, and especially their migration. Once you know in what order to write the different search/replace operations, you can not only migrate between domains very easily but also make sure you don’t hit these pesky mixed-content security warnings anymore by having all local links use the HTTPS protocol.
What products or platforms are using WP-CLI in clever ways?
There are lots of creative ways that people tie into WP-CLI to have it solve specific issues.
The WP Starter project has a nifty integration with WP-CLI in its upcoming version 3 (in beta at the time of this writing). This project is a tool to bootstrap a WordPress installation out of a single composer.json file, with all additional steps and required hacks included. Just state the sequence of commands to run and WP Starter does the rest.
The VersionPress project basically adds custom commands to WP-CLI that turn it into “git for your entire site,” letting you push and pull changes to the database and merge conflicts. It’s quite exhilarating to see a command like wp vp restore-site pull an entire site with files and database from a git repository…
Finally, the WP-CLI Restful project is a glimpse into the future (which seems to be farther away than originally thought, unfortunately). It maps REST API endpoints (as they are provided by WordPress Core or plugins) into WP-CLI commands. This basically means that a GET /my-plugin/v1/product/<id> request would end up being executable on the console through wp @prod product get <id>. The main issue right now is that the REST API is not in a state where you can do this reliably and across all use cases. Hopefully, the increased attention that the REST API is currently garnering because of the move from server-side code to client-side code in WordPress Core will help move this further along in the near future.
What’s the best way for the community to get involved to support the project?
I also wrote a handy contribution guide that you can find at https://make.wordpress.org/cli/2018/07/14/contributing-to-wp-cli/. It provides an overview of the different types of contributions you can do for the WP-CLI project. Hint: you don’t need to be a developer to contribute…
If you really don’t know how to get involved or where to start, just join the #cli channel and say hello! We’ll figure out the rest together!