How We Test Docket Cache With WP Staging CLI

By Nawawi Jamili · 22 October 2026 · 5 min read

Docket Cache runs on a lot of different WordPress sites. Some use PHP 7.4, others PHP 8.4. Some run the latest WordPress, others an older one. Some are single sites, others are multisite networks. Before each release, we need to check Docket Cache on as many of these as we can. This post shows the tool we use for that, WP Staging CLI.

Why a cache plugin is hard to test#

A bug in a cache plugin often does not show on the first page view. The first view saves data to the cache. The second view reads it back. If the data comes back wrong, the problem only shows then, and sometimes only on one PHP version.

So we cannot test on one site and call it done. We need many sites, and we need to throw them away and start again often. Building each test site by hand takes too long. We want to type one command and have a fresh WordPress site a minute later.

What WP Staging CLI is#

WP Staging CLI is a command-line tool from WP Staging. It runs on Linux, macOS and Windows. It does two main jobs.

It builds local WordPress sites. Each site runs in its own Docker containers, with the PHP version, WordPress version, web server and database you pick. You do not write any Docker files yourself.
It works with WP Staging backups. It can restore a .wpstg backup into a local site, or take files and the database out of a backup, without a running WordPress.

WP Staging CLI needs Docker, which you install yourself. You also need a WP Staging Pro licence on the Developer or Agency plan. The WP Staging CLI page has the details, and the release page on GitHub has the install steps and all the commands.

On Linux and macOS, one command installs it.

curl -fsSL https://wp-staging.com/install.sh | bash

Our test sites#

We keep two sites for Docket Cache. dctest.local is a single site, and dcmu.local is a multisite network. Each one took one command to create.

wpstaging add dctest.local --label="docket-cache 26.04.09 test"
wpstaging add dcmu.local --multisite --label="docket-cache 26.04.09 multisite test"

Each site gets its own address with HTTPS, and opens in the browser like a real site. Both run nginx and MariaDB. wpstaging list shows every site with its PHP version, WordPress version and status.

A terminal running wpstaging list for dctest.local and dcmu.local. Both sites run PHP 8.1, WordPress 7.1.3, nginx and MariaDB 11.8. dcmu.local is a multisite and dctest.local is a single site. Both are running, and each one shows its Adminer address and a magic link. — Our two Docket Cache test sites in wpstaging list

When we do not need a site, wpstaging stop dctest.local stops its containers. wpstaging start dctest.local brings it back.

How we use it#

Other PHP versions#

Docket Cache stores its cache as PHP files, so the PHP version matters a lot. One command moves a site to another PHP version.

wpstaging switch-php dctest.local 8.4

WP Staging CLI changes the set-up and restarts the containers. The database, plugins and settings stay as they are. We then run the same checks again, and switch to the next version. WP Staging CLI offers PHP 7.4 and 8.1 to 8.4.

Other WordPress versions#

In the same way, we can move a site to an older WordPress, the latest one, or even the nightly build of the next one.

wpstaging switch-wp dctest.local nightly

This only replaces the WordPress files. The database, themes, plugins and uploads stay. Testing on the nightly build can tell us early if a coming WordPress release changes something that Docket Cache uses.

WP-CLI without logging in#

Docket Cache has its own WP-CLI commands. With wpstaging wp, we can run them on a test site from our own terminal.

wpstaging wp dctest.local cache status
wpstaging wp dctest.local cache run:gc
wpstaging wp dcmu.local site list

Everything after the site name goes to WP-CLI unchanged. This makes it easy to put a set of checks in a small script and run it after every change.

A clean start#

Sometimes a test leaves a site in a state we do not want, for example after we test what happens when the cache folder is full. Then we start again.

wpstaging reset dctest.local

This gives us a fresh WordPress on the same address. Then we install the new Docket Cache build and test again.

Into wp-admin with one link#

Many of our checks are in the Docket Cache screens in wp-admin. wpstaging magic-link prints a link that logs us in and opens the page we ask for.

wpstaging magic-link dctest.local --redirect='admin.php?page=docket-cache'

Each new link stops the one before it from working, and the link only works for a short time. We also use this to take the screenshots for this blog. The Cronbot screen in Cronbot Is Now Written In Go came from dctest.local this way.

A copy of a real site#

Some problems only happen on one real site, with its own plugins and data. If a user can share a WP Staging backup of a site, we can restore it into a local test site.

wpstaging add problem.local --from=backup.wpstg

We then try Docket Cache on that copy, and the real site is never touched.

What it does not cover#

WP Staging CLI does not test anything by itself. It gives us the sites, and we still write the checks and look at the results. Its lowest PHP version is 7.4, but Docket Cache still supports PHP 7.2.5, so the oldest versions need a different set-up. And a site on our computer is not shared hosting. Some problems, such as file limits on a busy shared host, only show on a real host.

In short#

Testing a cache plugin needs many WordPress sites, on many PHP and WordPress versions, that we can throw away and build again. WP Staging CLI gives us that with a few short commands. If you build plugins or themes, and you already have a WP Staging Pro Developer or Agency plan, it is worth a try.