v0.0.1-beta.23

Added — update notifier + instawp upgrade

• The CLI now checks npm for a newer version at most once a day (cached in ~/.config/instawp/) and prints a one-line hint to stderr when an update is available — e.g. ⚡ Update available: 0.0.1-beta.22 → beta.23 · run: instawp upgrade. It's instant on cache hits and only does a short, timeout-bounded network call on the daily refresh.
• instawp upgrade (alias update) self-updates via npm i -g @instawp/cli@latest; --check reports without installing.
• Never pollutes output or surprises you: the hint is suppressed in --json, CI, and non-interactive shells (so harnesses never see it), and it never auto-installs by default. Opt into hands-off updates with INSTAWP_AUTO_UPGRADE=1; silence the hint with INSTAWP_NO_UPDATE_NOTIFIER=1.

v0.0.1-beta.22

Added — plugin install, sql, and HTTP-ready create

• instawp plugin install <site> <zip|dir> [--activate] — install a plugin from a local .zip (scp + wp plugin install --force) or directory (rsync into wp-content/plugins/, then activate). Removes the base64-over-exec dance.
• instawp sql <site> "<query>" — run a SQL query via WP-CLI; hits MySQL directly so it's immune to the object cache (handy for verifying state behind a cache).
• instawp create now waits until the site answers HTTP, not just until the provisioning task finishes — DNS/edge propagation lags task completion by 30–120s, so "Ready" now means actually reachable (no more hand-rolled curl-retry gates). --no-wait still returns immediately; --json includes http_ready.

Notes (from heavy CLI-driven test-harness use)

• exec/wp faithfully forward argv with per-arg shell-quoting (since beta.21) — quoted multi-word args and wp db query "…" work without --. For bulk file transfer use sync push (rsync), not exec: passing large data as a command argument hits the OS ARG_MAX limit (that's a kernel limit, not a CLI cap), which is what made base64-over-exec unreliable.

v0.0.1-beta.21

Fixed — local push --with-db broke wp-admin on sites with a custom table prefix

• After a DB push, wp-admin became inaccessible on sites whose cloud table prefix isn't wp_ (which is most InstaWP sites — they use a random prefix like iwpa797_). WordPress stores roles/capabilities under the table prefix ({prefix}capabilities, {prefix}user_level in usermeta; {prefix}user_roles in options). The local Playground DB is normalized to wp_, so the imported keys were wp_capabilities etc. — which the cloud (looking for iwpa797_capabilities) ignored, leaving the admin with no capabilities.
• Fix: after import, local push --with-db now remaps those access-critical keys to the cloud's prefix (exact key names only — never touches plugin options). Verified end-to-end on a real custom-prefix site (admin role resolves, wp-admin accessible). If you hit this on beta.20, restore the cloud DB from the ~/db-backup-*.sql.gz the push saved, update to beta.21, and re-push.

v0.0.1-beta.20

Added — local push --with-db (push the database back to the cloud)

• instawp local push <local> was files-only (it synced wp-content but not the database), so content changes — new pages, posts, settings — never reached the cloud. New --with-db flag also pushes the local Playground database, OVERWRITING the cloud MySQL.
• How it works: backs up the cloud DB first (--no-backup to skip), converts the local SQLite to MySQL data-only (reuses the cloud's existing schema — no fragile type-mapping), imports it, and runs a serialization-safe wp search-replace to fix local→cloud URLs. Only tables present on both sides are synced; local-only tables (e.g. a plugin's tables created after cloning) are reported and skipped. --dry-run previews with zero cloud writes; --force skips the confirmation; --json requires --force.
• A plain local push now prints a one-line reminder that the database wasn't pushed (use --with-db).
• Validated end-to-end against a real InstaWP site (clone → add page → push --with-db → page + correct URLs on cloud). There is no official WordPress SQLite→MySQL exporter (sqlite-database-integration#36); this is a self-contained, data-safe implementation.

v0.0.1-beta.19

Fixed — local push after local clone created a new site instead of pushing back

• A cloned instance didn't remember which cloud site it came from, so instawp local push <local> (with no cloud-site argument) fell into the "create a new site" path and provisioned a new site named after the local instance — instead of pushing to the original. local clone now records the origin (cloudSiteId) on the instance, and local push targets it by default (explicit arg → cloned origin → otherwise create). Pushing with an explicit cloud site once also backfills the link on instances cloned before this fix.
• Also fixed the cloned instance name: local clone derived it from the full domain, so client-store-1234.instawp.site became client-store-1234-instawp-site. It now uses the site name, or the first DNS label of the subdomain (client-store-1234).

v0.0.1-beta.18

Fixed — local push --dry-run provisioned a real cloud site

• instawp local push <name> --dry-run with no cloud-site argument ran the "create a cloud site" path — so a dry run provisioned a real, permanent cloud site, then tried to connect to its not-yet-resolvable hostname and failed with connect: Address lookup failed for host / rsync exited with code 1. (Reported by QA on Windows; the bug was cross-platform.)
• Fix: a dry run is now side-effect free. With no cloud site specified, it previews the local wp-content files that would be pushed (a pure local filesystem walk respecting the same excludes — no provisioning, no network) and reports that no site was created. Passing an existing cloud site (local push <name> <site> --dry-run) is unchanged.

v0.0.1-beta.17

Fixed — local start / local create mount failure on Windows

• On Windows, instawp local start (and local create) failed with Invalid mount format: C:\...\wp-content:/wordpress/wp-content. wp-playground-cli's --mount=<host>:<vfs> splits the value on :, and a Windows host path's drive-letter colon (C:\...) produced 3+ parts, so Playground rejected the mount.
• Fix: on Windows the CLI now uses Playground's --mount-dir / --mount-dir-before-install flags, which take the host and vfs paths as two separate arguments (no colon to split). Applies to fresh sites, cloned-site subdirectory mounts, and individual file mounts. macOS/Linux keep the existing --mount=<host>:<vfs> form unchanged. (Reported by QA on Windows; @wp-playground/cli ≥ the version exposing --mount-dir.)

v0.0.1-beta.16

Changed — renamed snapshot → versions

• The command added in beta.15 is now instawp versions create|list|restore|delete (alias version). Renamed from snapshot to avoid confusion with InstaWP's separate Snapshots product — these are a site's restorable versions. Same flags and behavior; only the command name changed.

v0.0.1-beta.15

Added — snapshot command (restorable site versions)

• New instawp snapshot create|list|restore|delete (alias snapshots) for managing site snapshots — InstaWP's restorable "site versions", point-in-time copies of a site's files + database. Unlike backups, a snapshot can be rolled back to in-place.
• Built for the AI-agent workflow: take a snapshot before letting an agent run a batch of changes, then roll back the one that broke it in a single command.
  • snapshot create <site> [--name <label>] [--no-wait] — waits for the snapshot to finish by default; --no-wait returns as soon as it's queued.
  • snapshot list <site> — ID, name, size, status, and creation date.
  • snapshot restore <site> <version-id> [--force] [--no-wait] — overwrites the live site's files + database; prompts for confirmation unless --force.
  • snapshot delete <site> <version-id...> [--force].
• All subcommands support --json. Long-running create/restore poll task status with a progress spinner.

v0.0.1-beta.14

Improved — clearer first-run for local commands

• When local create/start/clone falls back to npx (no global wp-playground-cli), the CLI now prints a one-time dim hint explaining the first-run download (~30s) and how to skip it on future runs (npm i -g @wp-playground/cli). Previously users just saw npm's raw download output with no context. Shown once per run, on stderr, and suppressed in --json mode.