Welcome to…. a Wikimedia CLI.

My involvement with what eventually became mwcli goes back to the Wikimedia Hackathon in Vienna in 2017. I put together mediawiki-docker-dev, or MWDD, to make testing MediaWiki against different combinations of PHP versions, web servers and databases easier. It gradually became a development environment that people used day to day, with a collection of Bash scripts wrapping Docker Compose. I wrote up that early history in 2021.

By May 2020, I was experimenting with a more intentional CLI around it. That prototype was written in PHP using Symfony Console, split the environment into independently controlled service groups, and reduced the number of containers needed at startup. It also made tools such as Composer, Fresh and Quibble easier to use alongside the development environment. The basic idea was still Docker Compose, with a friendlier way to manage all the moving parts.

Meanwhile, the Wikimedia Foundation’s Release Engineering team was working on a Go-based MediaWiki CLI. I began porting the MWDD functionality into that project in 2020, with the work continuing through 2021. This brought the development environment into a tool that could be distributed as a single binary, with built-in help, automated tests and regular releases. By November 2021, I could finally point existing MWDD users towards its new home under mw docker.

The wider Wikimedia scope was already starting to appear then. Alongside the development environment, mwcli had commands for GitLab, Gerrit, Codesearch and Toolhub. When I looked back at its usage in January 2025, the development environment still accounted for most recorded activity. But the ambition was to make the CLI useful across more MediaWiki and Wikimedia workflows, and I ended that post wondering whether a rename should accompany a rework, restructure and refocus.

Which brings us to a Wikimedia CLI. The development environment remains a substantial part of the project, but there is now more to discover around Wikimedia data, Toolforge, Cloud VPS and working with wiki content. After several iterations of the tooling—and quite a few years of carrying names from earlier ones—it feels like a good time to start making that broader direction more visible.

A naming discussion

The naming had become rather muddled. The project was generally called mwcli, the executable was mw, the documentation lived on the Cli page of mediawiki.org, and the repository was called releng/cli. In March 2023, Sam Wilson asked the fairly reasonable question of what the project was actually called. Calling a command-line tool “CLI” also gives people very little to distinguish it from all the other command-line tools they might be looking for. See the naming discussion on the talk page.

There was also another mwcli already out there. Sam had a separate PHP-based command-line client for working with MediaWiki wikis, including uploading files and exporting pages. Two tools with the same name, operating in the same ecosystem, made a distinct identity particularly important. His project has since moved to Wikimedia GitLab and continues to use that name.

The scope of this project was another reason to reconsider “MediaWiki CLI”. Back in April 2023, I suggested that “Wikimedia” would better describe where it was heading, pointing to the GitLab integration as something that wasn’t specifically about MediaWiki. With analytics, EventStreams, Toolforge and Cloud VPS functionality now available, that broader description makes even more sense.

Naturally, agreeing that a name should change and actually changing it turned out to be rather different tasks. I said I would get to it before the end of 2023, we discussed names including kiwi and wicli in 2024, and I then aimed for the end of that year too. Naming things remains hard, apparently!

a Wikimedia CLI gives the project a descriptive identity that fits its wider ambitions. It also leaves room for the many other useful command-line tools in the ecosystem. The practical transition can happen gradually, keeping existing commands and scripts working while the documentation and branding catch up. (More on that in future versions)

0.34.0 release

The 0.34.0 release brings together the new branding (with more to come) and a fairly substantial collection of changes across the CLI. There is plenty for existing development-environment users, alongside more functionality for people working with Wikimedia services, data and wiki content. The full changelog has the details, but here are a few highlights.

The Wikimedia data commands are probably the easiest place to start exploring. mw analytics can retrieve pageviews, edit counts, editor counts, most-viewed pages, media requests and more. Results can be returned as tables, JSON or CSV, or displayed as graphs directly in your terminal. For example:

mw analytics pageviews 'Albert Einstein' --project en.wikipedia.org --output graphCode language: JavaScript (javascript)

There is also mw api for making direct requests to Wikimedia REST APIs, and mw events for discovering and following public EventStreams feeds. These commands give the CLI something useful to do even when you have no intention of running MediaWiki locally.

Toolforge’s CLI is now embedded under mw tools, making its jobs, builds, deployments, shells and Kubernetes commands available from your local machine. The Cloud VPS commands have also expanded, covering instance discovery, SSH sessions, remote command execution, instance creation and volume management.

I’m preparing for more interactive and visual documentation, now with automated recordings of some of the more complex command interactions, such as deploying a k8s service in toolforge from your local machine. (see below)

The wiki commands have received some attention too. You can upload files and new versions, move individual pages or batches of pages while preserving their histories, and download files in their original format or as PNG/JPEG images. For example, getting a small PNG version of the new logo from Commons is now:

mw wiki file download 'File:Logo of a-wikimedia-cli.svg' --wiki commons.wikimedia.org --format png --width 250 --output logo.pngCode language: JavaScript (javascript)

I’m sure I’ll properly flesh out the wiki interactions in another future release…

For development-environment users, mw dev is now the main entry point, with mw docker retained as an alias. Traefik is the default proxy, and Cloudflare Quick Tunnel and Holesail support make it possible to access an environment through an authenticated gateway. There is optional log browsing through OpenSearch Dashboards, improved suspend/resume behavior, parallel source cloning, and a new mediawiki update-code command for updating core, extensions and skins.

This is going toward being able to use the CLI to entirely manage a remote development environment on a VM for MediaWiki and more. I expect one of the next services that will be added will be VsCode itself.

There are also plenty of smaller improvements around installation output, Composer failures, Docker contexts and service images. MariaDB now defaults to 11.4 LTS, and replication retains its position across service restarts. Existing MariaDB data is upgraded automatically on startup; that upgrade is one-way, so take a database backup before updating an existing environment.

In-fact, I basically cleared out the entire Phabricator board of issues in this release (I look forward to more being filled in).

Finally, there are more workflow guides available through mw help guides, alongside recorded demonstrations. And these will all also be viewable and searchable on mediawiki.org.

Where next?

I’m going to try and start “speeding up” development, and releasing monthly (at least), continuing to expand coverage of “core” Wikimedia services that are often used by devs, or tech savvy folks.

What’s already in my view?

• Better secret support for CLI related passwords, keys and users details
• Automatic integration with VsCode if running remotely on a VM
• Expanded development environment dashboard support
• Wikimedia service shortcuts, so commands such as wm @en.wikipedia.org page get Foo could exist alongside wm @en.wikipedia.org analytics pageviews Foo

But if there is something you might like, just let me know!