How a Small Version Parser Bug Broke WP Staging CLI Self-Updates

If you are running WP Staging CLI v1.10.0 or v1.11.0, the built-in wpstaging update command will refuse to check for updates and print “Update check skipped for development version”. The CLI cannot upgrade itself in place on these two versions. This post explains what went wrong, what we have fixed, and the one-time command that brings you back to a healthy install.

TL;DR

Affected versions: v1.10.0 and v1.11.0 only. To recover, re-run our official installer. It detects your existing install, replaces the binary in place, and leaves your sites, license, and configuration untouched.

Linux, macOS, WSL:

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

Windows PowerShell:

irm https://wp-staging.com/install.ps1 | iex

Windows CMD:

curl -fsSL https://wp-staging.com/install.cmd -o install.cmd && install.cmd && del install.cmd

After that, you will be on v1.11.1 or later, and wpstaging update works normally again.

What Happened

The updater treats anything that does not look like a clean semver string as a development build, and silently skips the update check. The intent was reasonable: when you build the CLI locally with go run or make build without a version flag, you would otherwise see a confusing “Update vX.Y.Z available (current: vdev)” message every time you ran a command.

The bug: our release tags are pushed as v1.10.0, v1.11.0, and so on, with a leading v. The version parser, however, required a bare 1.10.0. The leading v was supposed to be stripped first, but the development-build check ran before the strip step. So every release-tagged binary saw itself as a development build, and silently skipped its own update check.

Both code paths were affected:

• The explicit wpstaging update command, which is why running it bailed out with the “skipped” message instead of upgrading.
• The automatic background check that runs once a day on any command, which is why no upgrade banner ever appeared either.

The net effect is that installations of v1.10.0 and v1.11.0 cannot recover themselves. The fix has to come from outside the broken binary, which is why the recovery step is the installer one-liner above and not wpstaging update.

What We Did

1. Released v1.11.1 with the fix. The development-build check now strips the leading v first, and only skips the update path on genuine development tags such as v0.0.0-dev and dev.
2. Added regression tests covering the four shapes that matter: v1.11.1, 1.11.1, v0.0.0-dev, and dev. The first two must pass the dev check; the second two must skip the update path. The tests will fail loudly if the ordering ever regresses.
3. Started building a server-side notification channel in our license API, so that in the rare event of a similar lockout in future, we can surface an in-product message without depending on the update path itself.

What You Need to Do

Run the installer one-liner for your platform from the TL;DR section above. It will:

• Download v1.11.1 (or later) for your operating system.
• Verify the checksum.
• Replace the existing wpstaging binary in place.
• Leave your sites, license, cache, and configuration untouched.

Once it finishes, confirm the upgrade landed:

wpstaging --version

You should see v1.11.1 or higher (released binaries print the leading v). From this point onwards, wpstaging update works as expected, and the daily background check will pick up future releases automatically.

Preventing This Class of Bug

This bug was particularly painful because the broken code path is the same one that would normally tell you to upgrade. A user-side workaround was not possible; the recovery had to come from us. To make sure a similar lockout cannot recur silently, we are putting three layers in place:

• Regression tests that exercise the version parser against both real release tags and development tags, so the ordering between strip-and-check cannot be quietly inverted again.
• A release-time smoke check on the built binary that asserts the development-skip path is not taken for the actual release tag. If a release ever ships with the dev check incorrectly active, the build will fail before the binary reaches users.
• A server-side notification channel in the license API. Once delivered, the CLI will be able to display short messages we publish from our side, so any future incident can be communicated without going through the update path itself.

Thank you for using WP Staging CLI, and sorry for the friction this one caused.

This was a plain old human engineering mistake, not an AI-generated code issue. We missed it, fixed it, and added regression and release-time checks so this specific failure cannot silently ship again.

Questions or Problems

If the installer does not work for you, or you see something unexpected after re-installing, please reach out:

• Contact form
• GitHub: open an issue on the WP Staging CLI release repository