spinuptui 0.19.0 → 0.20.0

package/CHANGELOG.md

@@ -11,6 +11,67 @@ versions; such changes are called out here.
 
 ## [Unreleased]
 
+## [0.20.0] - 2026-07-08
+
+### Added
+- **The clone wizard's existing-server picker now shows each server's current
+  site count.** Picking a destination previously showed only provider/region/
+  IP — no sense of how busy a candidate already is. Each row now leads with
+  `N site(s)`.
+
+### Fixed
+- **The clone wizard no longer routes git-deployed non-WordPress sites through
+  a Bedrock pull.** `cloneStackFor` trusted `git.repo` alone as "this is
+  Bedrock" — true often enough (`is_wordpress` is unreliable for git sites),
+  but a git-deployed **static** site (confirmed live: a client's static site,
+  repo literally named `*-static-site`) would be routed through
+  `composer install`/wp-cli anyway, which it can't survive. A conclusive
+  non-WordPress probe (`whmcs`/`laravel`/`static`) now overrides `git.repo`;
+  a probe saying `bedrock`/`wordpress`, or no probe at all, still trusts it
+  (same "probe the site (`d`) before cloning" caveat as the sibling fix
+  above).
+- **The clone wizard no longer silently skips the database for API-mislabeled
+  WordPress sites.** Its stack picker read `is_wordpress` straight from the
+  API, unlike every other view (Stacks, Browser), which corrects that flag
+  against a `d` probe result. A site the API wrongly reports as non-WordPress
+  (confirmed live against two real client sites) would default to a
+  files-only pull — filesystem copied, database never touched, so the
+  "clone" wasn't a working WordPress site. The wizard now consults the same
+  probe-corrected classification: **probe the site (`d`) before cloning** so
+  the wizard picks it up as WordPress.
+- **wp-cli reads now use the site's own configured PHP version, not the
+  server's system default.** wp-cli's installed binary shebangs
+  `#!/usr/bin/env php`, which resolves through `PATH` to whichever PHP a
+  server's `update-alternatives` currently calls default — independent of
+  any individual site's configured version, and it can be missing extensions
+  that version's CLI never got configured with. Confirmed live: a site
+  configured for PHP 8.1 silently ran its wp-cli reads under the server's
+  default 8.4, whose CLI was missing `mysqli` — every WordPress-content read
+  (posts, pages, users, active plugins, site/home URL) failed silently,
+  while file-only or native-MySQL-client commands (`core version`, `db
+  export`/`import`/`check`) were unaffected. This broke the clone wizard's
+  **Verify** step (`v`) and the **installed plugins & themes** view (`p`) for
+  any site whose configured PHP differs from the server's system default —
+  both now pin wp-cli to the site's own PHP-CLI binary, falling back to the
+  system default only if that specific version isn't installed.
+- **Verify now tells the difference between "the clone actually differs" and
+  "wp-cli couldn't read one side's database."** If `core version` succeeds
+  (a file read, no DB) but every database-backed fact comes back empty, that's
+  the missing-extension failure above, not a real content difference — Verify
+  now reports it plainly instead of a wall of misleading ✕ rows implying data
+  loss.
+
+## [0.19.1] - 2026-07-08
+
+### Fixed
+- **Finished the SpinupTUI rebrand in the README and cover banner/social-preview
+  images.** The v0.19.0 rename swept the CLI banner, header wordmark, and app
+  chrome, but missed 14 mid-sentence "Spinup" mentions scattered through the
+  README's prose, and the cover banner/social-preview images still spelled out
+  "SPINUP" in block-letter art. Both are fixed now; `spinup-sudo` (a Keychain
+  service name) and the `spinup-tui` machine key (a literal SSH key identity)
+  are unaffected — they're real persisted identifiers, not branding.
+
 ## [0.19.0] - 2026-07-08
 
 ### Changed
@@ -918,7 +979,9 @@ Initial tagged release.
 ### Notes
 - Read-only release: works with a SpinupWP **Read Only** API token.
 
-[Unreleased]: https://github.com/mwender/spinupwp-tui/compare/v0.19.0...HEAD
+[Unreleased]: https://github.com/mwender/spinupwp-tui/compare/v0.20.0...HEAD
+[0.20.0]: https://github.com/mwender/spinupwp-tui/compare/v0.19.1...v0.20.0
+[0.19.1]: https://github.com/mwender/spinupwp-tui/compare/v0.19.0...v0.19.1
 [0.19.0]: https://github.com/mwender/spinupwp-tui/compare/v0.18.0...v0.19.0
 [0.18.0]: https://github.com/mwender/spinupwp-tui/compare/v0.17.0...v0.18.0
 [0.17.0]: https://github.com/mwender/spinupwp-tui/compare/v0.16.1...v0.17.0

package/README.md

@@ -1,5 +1,5 @@
 <p align="center">
-  <img src=".github/assets/banner.png" alt="SpinupWP TUI" width="100%">
+  <img src=".github/assets/banner.png" alt="SpinupTUI" width="100%">
 </p>
 
 <h1 align="center">SpinupTUI</h1>
@@ -110,7 +110,7 @@ Once you're in, the dashboard looks like this:
 - **Create & connect a server** — press `c` on the Servers tab to provision a new
   server (DigitalOcean / Vultr / Linode / Hetzner), priced from the provider catalog
   and pre-filled to match a selected server. Then press `V` on any server that
-  doesn't yet have a **site at its own hostname** to connect it end to end: Spinup
+  doesn't yet have a **site at its own hostname** to connect it end to end: SpinupTUI
   writes the DNS A record, creates a
   placeholder "vanity" site, enables HTTPS, hands you off to add your SSH key, and
   publishes a status page — turning a bare server into one you can actually work
@@ -123,10 +123,10 @@ Once you're in, the dashboard looks like this:
   verifies the clone against the source, and finally repoints DNS on your word.
   Runs in the background with a header badge. (See "Cloning a server" below.)
 - **Privileged writes over SSH (sudo + SSH keys)** — the SpinupWP API can't manage
-  SSH keys or sudo users, so Spinup does it directly. Press `S` on a server to
+  SSH keys or sudo users, so SpinupTUI does it directly. Press `S` on a server to
   **connect sudo** for the session (optionally **remembered in your macOS Keychain**
   so it auto-unlocks next time), then `K` on a site to **grant or revoke** your
-  personal key and/or Spinup's dedicated machine key — one site or every site on the
+  personal key and/or SpinupTUI's dedicated machine key — one site or every site on the
   server. (See "Privileged writes over SSH" below.)
 - **Uptime Kuma monitoring** — press `m` on a site to wire it into your own
   [Uptime Kuma](https://github.com/louislam/uptime-kuma) instance (one-time
@@ -146,7 +146,7 @@ Once you're in, the dashboard looks like this:
   (See `docs/uptime-kuma.md` for recipes.)
 - **Site monitoring: fingerprints, a doctor, and a Redis sentinel** — press `M`
   on any site (Servers / Stacks / Search) for the monitoring overlay. `f`
-  calibrates a **front-page check**: Spinup reads your healthy front page,
+  calibrates a **front-page check**: SpinupTUI reads your healthy front page,
   derives a template-identity fingerprint from what WordPress itself stamps
   into the markup (not a headline someone might edit), proves it discriminates,
   and registers a Kuma keyword monitor at your chosen window (5m–1h) — catching
@@ -155,7 +155,7 @@ Once you're in, the dashboard looks like this:
   proven by the server's own `fastcgi-cache` headers) plus a wp-admin door
   probe, diagnosing stale caches and **partial outages** — cached pages fine
   while everything uncached throws 500 (a dead Redis does exactly this) — and
-  ending in a copyable runbook. `n` wires **alerts**: Spinup detects the
+  ending in a copyable runbook. `n` wires **alerts**: SpinupTUI detects the
   notification providers configured in Kuma by name and toggles them per site.
   And servers get a **Redis sentinel**: the heartbeat cron pings Redis every
   minute and reports up/down to its own `{server} redis` monitor.
@@ -163,7 +163,7 @@ Once you're in, the dashboard looks like this:
 - **Completion toasts** — background writes that take a while (a PHP upgrade, a
   server reboot/restart, resolving your fleet's DNS) raise a non-focus-stealing
   toast when they finish, so you're not left guessing after you've moved on.
-- **Release notes** — after Spinup updates to a new version, a one-time overlay
+- **Release notes** — after SpinupTUI updates to a new version, a one-time overlay
   shows what changed (sourced straight from that version's GitHub release —
   no separate feed to maintain). Press `n` in `?` Help to see the current
   version's notes again any time.
@@ -461,7 +461,7 @@ server's row keeps a spinner).
 Everything hangs off one overlay: press `M` on a site in any view (the Servers
 tab also keeps its original `m`). It talks to your own
 [Uptime Kuma](https://github.com/louislam/uptime-kuma) — Kuma watches 24/7 and
-sends the alerts; Spinup creates the monitors *correctly* and diagnoses on
+sends the alerts; SpinupTUI creates the monitors *correctly* and diagnoses on
 demand.
 
 - **`a` — uptime monitors.** Regular sites get a homepage monitor (up/down +
@@ -472,7 +472,7 @@ demand.
   SpinupWP's default object-cache drop-in, a dead Redis is **fatal (HTTP 500)
   for every request that misses the page cache** — cached pages keep serving
   200, so only the sentinel notices, within a minute.
-- **`f` — the front-page check.** Spinup reads your *healthy* front page,
+- **`f` — the front-page check.** SpinupTUI reads your *healthy* front page,
   derives a template-identity fingerprint from WordPress's own `body_class()`
   output (`class="home`, `page-id-N`, …, falling back to the canonical link),
   validates it against a throwaway search render to prove it discriminates,
@@ -493,7 +493,7 @@ demand.
   pages 200, fresh renders or wp-admin 5xx — Redis or a PHP fatal; visitors
   look fine, admins are broken) · recalibrate (`f` jumps straight there) ·
   down · inconclusive.
-- **`n` — alert wiring.** Spinup detects the notification providers configured
+- **`n` — alert wiring.** SpinupTUI detects the notification providers configured
   in your Kuma (by name — Telegram, email, whatever you've set up) and shows
   whether each is attached to this site's monitors (`✓` all / `◐` some / `○`
   none); `⏎` toggles a provider across all of the site's checks at once.
@@ -520,7 +520,7 @@ id (Account Settings → Server Providers) and saves it — once per provider. T
 build fires `POST /servers` and tracks the ~10-minute provision in the background.
 
 **Connect it with a vanity site (`V`).** A brand-new server has **no site**, so
-there's nothing to attach an SSH key to and no way for Spinup to reach it — empty
+there's nothing to attach an SSH key to and no way for SpinupTUI to reach it — empty
 servers are flagged in **amber** in the Servers list. A busy server benefits from
 the same thing (a status page at its own hostname + a site user to hold your key),
 so `V` is offered on **any server that doesn't yet have a site at its own
@@ -546,11 +546,11 @@ shows where, with `r` to retry or `x` to discard.
 ## Privileged writes over SSH (sudo & SSH keys)
 
 Some things the SpinupWP API simply can't do — it has **no** surface for SSH keys or
-sudo users. Spinup does them directly over SSH instead, which means these actions use
+sudo users. SpinupTUI does them directly over SSH instead, which means these actions use
 **your own SSH access**, not the API token.
 
 **Connect sudo (`S`).** Press `S` on a server and enter its SpinupWP **sudo user**
-and that user's **sudo password** once. Spinup validates them against the live server
+and that user's **sudo password** once. SpinupTUI validates them against the live server
 (`sudo -S -p '' true`) and then holds the password **in memory for the session only**
 — the username persists to config, the password is never written to plaintext config.
 A connected server shows a green `● sudo` badge on its row; `S` again disconnects.
@@ -568,7 +568,7 @@ A connected server shows a green `● sudo` badge on its row; `S` again disconne
 keys into the site user's `authorized_keys`:
 
 - **Pick which keys** — any of **your personal keys** (discovered from `~/.ssh/*.pub`
-  and your ssh-agent, so you can SSH/SFTP as yourself) and/or Spinup's dedicated
+  and your ssh-agent, so you can SSH/SFTP as yourself) and/or SpinupTUI's dedicated
   **`spinup-tui` machine key** (an ed25519 identity generated once into the config dir,
   deliberately **never added to your SpinupWP account** so SpinupWP's key reconciliation
   can't clobber it). Your selection is remembered.
@@ -589,10 +589,11 @@ migration and **only repoints DNS when you say so**. It needs a **Read/Write tok
 over SSH). The steps:
 
 1. **Plan** — pick which of the source's sites to clone (all selected by default;
-   `space` toggles). Spinup sizes each one live (disk + database) into a payload total
+   `space` toggles). SpinupTUI sizes each one live (disk + database) into a payload total
    so you know what you're moving; a concurrency cap protects the busy source.
 2. **Destination** — provision a fresh server pre-matched to the source (reusing the
-   `c` flow), or `d` to pick an existing server as the target.
+   `c` flow), or `d` to pick an existing server as the target — each listed with its
+   current site count, so you can see at a glance how busy a candidate already is.
 3. **Connect** — connect sudo on **both** servers. The clone is a server-to-server
    **pull**: the destination pulls each site directly from the source over SSH (no
    bytes routed through your laptop), authenticating with a key granted onto the source

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "spinuptui",
-  "version": "0.19.0",
+  "version": "0.20.0",
   "description": "SpinupTUI — a terminal dashboard for browsing, monitoring, and managing your SpinupWP servers and sites.",
   "type": "module",
   "bin": {

package/src/lib/serverClone.ts

@@ -11,6 +11,7 @@
 // that shape the Bedrock branch).
 
 import type { Server } from "../api/types.ts"
+import { wpCliResolveScript } from "./wpCli.ts"
 
 const SSH_OPTS = ["-o", "BatchMode=yes", "-o", "ConnectTimeout=10", "-o", "StrictHostKeyChecking=accept-new"]
 
@@ -700,6 +701,7 @@ export interface VerifySpec {
   publicFolder?: string // configured public folder — fallback when the pull's rels are unknown
   sourceWebrootRel?: string // DETECTED source layout from the pull ("" = files root)
   destWebrootRel?: string // the CLONE's WP dir from the pull (post-normalization)
+  phpVersion?: string | null // the site's configured PHP version — see wpCli.ts
 }
 
 // One round-trip per side: collect labeled wp-cli facts as `key=value` lines.
@@ -707,10 +709,14 @@ export interface VerifySpec {
 // stalled outbound call once ate the whole budget and cut the facts off mid-script) —
 // and the flags are identical on both sides, so every count stays comparable. The
 // trailing `eof` sentinel is how verifyClone tells "read got cut off" from "differs".
-async function wpFacts(ctx: SudoCtx, root: string, user: string): Promise<Record<string, string>> {
+// wp-cli is pinned to the site's OWN configured PHP-CLI (wpCliResolveScript) rather
+// than bare `wp` — see wpCli.ts for why (a server's system-default PHP can silently
+// differ from, and be missing extensions present in, the site's actual version).
+async function wpFacts(ctx: SudoCtx, root: string, user: string, phpVersion?: string | null): Promise<Record<string, string>> {
   const script = [
     `cd ${shq(root)} 2>/dev/null || exit 0`,
-    `u() { sudo -u ${shq(user)} -H wp --skip-plugins --skip-themes "$@" 2>/dev/null; }`,
+    wpCliResolveScript(phpVersion),
+    `u() { sudo -u ${shq(user)} -H "$PHP" "$WP" --skip-plugins --skip-themes "$@" 2>/dev/null; }`,
     `echo "core=$(u core version)"`,
     `echo "posts=$(u post list --post_type=any --format=count)"`,
     `echo "pages=$(u post list --post_type=page --format=count)"`,
@@ -753,8 +759,8 @@ export async function verifyClone(source: SudoCtx, dest: SudoCtx, spec: VerifySp
   const srcDir = dirFor(spec.sourceWebrootRel)
   const destDir = dirFor(spec.destWebrootRel)
   const [sf, cf, http] = await Promise.all([
-    wpFacts(source, srcDir, spec.sourceSiteUser),
-    wpFacts(dest, destDir, spec.destSiteUser),
+    wpFacts(source, srcDir, spec.sourceSiteUser, spec.phpVersion),
+    wpFacts(dest, destDir, spec.destSiteUser, spec.phpVersion),
     curlStatus(spec.domain, spec.destIp),
   ])
   // A missing tail sentinel means the facts script was cut off partway (timeout, a
@@ -764,6 +770,22 @@ export async function verifyClone(source: SudoCtx, dest: SudoCtx, spec: VerifySp
     const side = sf.eof !== "1" ? "source" : "clone"
     throw new Error(`couldn't read the ${side}'s WordPress facts (the wp-cli read was cut off) — press v to re-run`)
   }
+  // `core` succeeding (a file read, no DB) while EVERY database-backed fact comes
+  // back empty is a distinct signature from a real content difference (which shows
+  // differing NON-empty values, not blanks) — it means wp-cli's PHP-CLI couldn't
+  // reach the database on that side, commonly a missing `mysqli` extension for
+  // whatever PHP version it resolved to (see wpCli.ts). Surface that plainly
+  // instead of a wall of misleading ✕ rows implying the clone lost data.
+  const dbFields = ["posts", "pages", "users", "plugins", "siteurl", "home"] as const
+  const looksBroken = (f: Record<string, string>) => !!f.core && dbFields.every((k) => !f[k])
+  const srcBroken = looksBroken(sf)
+  const cloneBroken = looksBroken(cf)
+  if (srcBroken || cloneBroken) {
+    const side = srcBroken && cloneBroken ? "both the source and the clone" : srcBroken ? "the source" : "the clone"
+    throw new Error(
+      `wp-cli can't reach ${side}'s database over PHP (commonly a missing "mysqli" extension for whatever PHP-CLI it resolved to) — this looks like a server/PHP-CLI environment issue, not an actual data difference.`,
+    )
+  }
   const checks: VerifyCheck[] = []
   checks.push({ key: "http", label: "Clone serves (HTTP)", source: "—", clone: http, ok: /^[23]\d\d$/.test(http) })
   const cmp = (key: string, label: string) => {

package/src/lib/stack.ts

@@ -49,6 +49,29 @@ export function effectiveStack(site: Site, probeKind?: ProbeKind | null): Stack
   }
 }
 
+// Which pull the clone wizard runs for a site — the SAME effectiveStack a
+// probe corrects elsewhere (Stacks tab, Browser), so an API-mislabeled site
+// (is_wordpress=false but really WordPress — confirmed live against real
+// client sites, 2026-07-08) gets a real database pull once probed, instead
+// of silently defaulting to a files-only copy. git.repo still takes
+// precedence for Bedrock detection (the pull needs the repo URL, which a
+// probe alone can't supply) — is_wordpress is unreliable for git sites, so
+// absent a probe (or a WP-family one) git.repo remains the best available
+// signal. But git.repo alone only proves "deployed via git," not "is
+// Bedrock" — a git-deployed STATIC site (confirmed live, 2026-07-09: a
+// client's git-deployed static site, repo literally named
+// "*-static-site") would otherwise be routed through a Bedrock pull
+// (composer install, wp-cli) it can't survive. A CONCLUSIVE non-WordPress
+// probe (whmcs/laravel/static) overrides git.repo; a probe saying
+// "bedrock"/"wordpress", or no probe at all, still trusts git.repo.
+export function cloneStackFor(site: Site, probeKind?: ProbeKind | null): "wp" | "bedrock" | "files" {
+  if (site.git?.repo) {
+    if (probeKind === "whmcs" || probeKind === "laravel" || probeKind === "static") return "files"
+    return "bedrock"
+  }
+  return effectiveStack(site, probeKind) === "Standard WP" ? "wp" : "files"
+}
+
 // `onSelection` brightens the colors that read poorly on the focused
 // (bright-green) selection background (green-on-green Bedrock, the faint grey).
 export function stackColor(stack: Stack, onSelection = false): string {

package/src/lib/wpCli.ts

@@ -0,0 +1,30 @@
+// Resolve wp-cli through the SITE's own configured PHP-CLI, not the bare `wp`
+// command. wp-cli's installed binary shebangs `#!/usr/bin/env php`, which
+// resolves through PATH to the SERVER's system-DEFAULT PHP — which drifts
+// toward whatever version was installed most recently, independent of any
+// individual site's configured version, and can be missing extensions that
+// version's CLI SAPI never got configured with.
+//
+// Verified live 2026-07-09 on web4.wenmarkdigital.com: the system default had
+// drifted to 8.4, whose CLI lacked `mysqli` (its FPM pool likely never needed
+// it — no site there runs 8.4), while lp.anchoredconstructiontn.com's actual
+// configured version (8.1) has a fully working php8.1-cli. Bare `wp` silently
+// ran under 8.4 and failed on anything touching $wpdb (post/user/plugin list,
+// option get) — while `wp core version`, and `wp db export/import/check/size`
+// (they shell out to native mysql client tools, not through mysqli) were
+// unaffected. Confirmed the fix directly: `/usr/bin/php8.1 /usr/local/bin/wp
+// post list ...` returned correct data where bare `wp` errored.
+//
+// Only applies to REMOTE (SSH) wp-cli calls against SpinupWP-managed servers,
+// which have this specific multi-PHP-version-drift shape. Local dev-machine
+// wp-cli (e.g. dbSync.ts's prod→local pull) is a different environment with
+// its own PHP entirely and is not affected — don't apply this there.
+
+// Emits POSIX shell that resolves $WP (the wp-cli binary) and $PHP (the
+// version-pinned interpreter, falling back to the bare `php` on PATH if the
+// versioned binary isn't installed — never worse than today's behavior).
+// Callers invoke `"$PHP" "$WP" ...` in place of bare `wp ...`.
+export function wpCliResolveScript(phpVersion?: string | null): string {
+  const phpBin = phpVersion ? `php${phpVersion}` : "php"
+  return [`WP=$(command -v wp 2>/dev/null || echo /usr/local/bin/wp)`, `PHP=$(command -v ${phpBin} 2>/dev/null || command -v php)`].join("\n")
+}

package/src/lib/wpInventory.ts

@@ -11,6 +11,7 @@
 import type { Server, Site } from "../api/types.ts"
 import { SSH_OPTS, sshPort } from "./dbBackup.ts"
 import { detectWpDirScript } from "./serverClone.ts"
+import { wpCliResolveScript } from "./wpCli.ts"
 
 // One plugin or theme, mirroring `wp {plugin,theme} list` columns.
 export interface WpItem {
@@ -100,13 +101,16 @@ export async function fetchWpInventory(
   const remote = [
     detectWpDirScript(root, site.public_folder ?? undefined),
     `if [ -z "$W" ]; then echo ===NOTWP; echo ===END; exit 0; fi`,
-    `WP=$(command -v wp 2>/dev/null || echo /usr/local/bin/wp)`,
+    // Pinned to the site's OWN configured PHP-CLI — bare `wp` resolves through
+    // its shebang to the server's system-default PHP, which can differ from
+    // (and lack extensions present in) the site's actual version. See wpCli.ts.
+    wpCliResolveScript(site.php_version),
     `echo ===WPDIR; printf '%s\\n' "$W"`,
     // The trailing `echo` after each wp command is load-bearing: `wp --format=json`
     // emits NO trailing newline, so without it the next ===MARKER glues onto the end
     // of the JSON line — the marker never parses and JSON.parse chokes on it.
-    `echo ===PLUGINS; "$WP" --path="$W" plugin list --fields=${fields} --format=json 2>/dev/null || true; echo`,
-    `echo ===THEMES; "$WP" --path="$W" theme list --fields=${fields} --format=json 2>/dev/null || true; echo`,
+    `echo ===PLUGINS; "$PHP" "$WP" --path="$W" plugin list --fields=${fields} --format=json 2>/dev/null || true; echo`,
+    `echo ===THEMES; "$PHP" "$WP" --path="$W" theme list --fields=${fields} --format=json 2>/dev/null || true; echo`,
     `echo ===END`,
   ].join("\n")
 

package/src/ui/store.tsx

@@ -17,7 +17,7 @@ import { APP_VERSION } from "../version.ts"
 import { cachedUpdateInfo, refreshUpdateInfo, type UpdateInfo } from "../lib/appUpdate.ts"
 import { fetchReleaseNotes, type ReleaseNotesInfo } from "../lib/releaseNotes.ts"
 import { resolveLocalLink, expandPath, normalizeLink, type LocalLink } from "../lib/local.ts"
-import type { Stack } from "../lib/stack.ts"
+import { cloneStackFor, type Stack } from "../lib/stack.ts"
 import { openTerminalAt, openUrl, openSshSession } from "../lib/open.ts"
 import { gitDrift, type Drift } from "../lib/gitStatus.ts"
 import { probeSite } from "../lib/probe.ts"
@@ -344,12 +344,6 @@ export function cloneNeedsGitAccess(j: CloneJob): boolean {
 export function isCloneInFlight(j: CloneJob | null | undefined): boolean {
   return j != null && j.step !== "done" && j.step !== "error"
 }
-// Detect a site's stack the way the clone branches: a git repo → Bedrock
-// (is_wordpress is unreliable for git sites — see the API findings doc);
-// is_wordpress → Standard WP; anything else → files-only (no DB, no wp-cli).
-export function cloneStackFor(site: Site): "wp" | "bedrock" | "files" {
-  return site.git?.repo ? "bedrock" : site.is_wordpress ? "wp" : "files"
-}
 // Alphanumeric token for generated dest DB passwords (never printed/persisted).
 function randomToken(n: number): string {
   const a = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789"
@@ -3335,8 +3329,11 @@ export function StoreProvider({ children }: { children: ReactNode }) {
       }
       const srcSites = sitesForServer(server.id)
       const sites: CloneSiteState[] = srcSites.map((s) => {
-        const stack = cloneStackFor(s)
-        const isWordPress = s.is_wordpress
+        // Probe-corrected: an API-mislabeled site (is_wordpress=false but really
+        // WordPress) gets a real database pull once probed (`d`), instead of
+        // silently defaulting to a files-only copy — see cloneStackFor's comment.
+        const stack = cloneStackFor(s, probes.get(s.id)?.result.kind)
+        const isWordPress = stack !== "files"
         return {
           sourceSiteId: s.id,
           domain: s.domain,
@@ -3371,7 +3368,7 @@ export function StoreProvider({ children }: { children: ReactNode }) {
       setCloneServer(server)
       setCloneJob(draft)
     },
-    [cloneJob, sitesForServer, servers],
+    [cloneJob, sitesForServer, servers, probes],
   )
 
   // Background an in-flight clone: hide the wizard but KEEP the job running (the
@@ -3770,7 +3767,7 @@ export function StoreProvider({ children }: { children: ReactNode }) {
         try {
           const res = site.stack === "files"
             ? await verifyFilesClone(source, dest, { domain: site.domain, destIp })
-            : await verifyClone(source, dest, { domain: site.domain, sourceSiteUser: site.siteUser, destSiteUser: site.siteUser, destIp, publicFolder: site.stack === "wp" ? site.publicFolder : undefined, sourceWebrootRel: site.stack === "wp" ? site.sourceWebrootRel : undefined, destWebrootRel: site.stack === "wp" ? site.destWebrootRel : undefined })
+            : await verifyClone(source, dest, { domain: site.domain, sourceSiteUser: site.siteUser, destSiteUser: site.siteUser, destIp, publicFolder: site.stack === "wp" ? site.publicFolder : undefined, sourceWebrootRel: site.stack === "wp" ? site.sourceWebrootRel : undefined, destWebrootRel: site.stack === "wp" ? site.destWebrootRel : undefined, phpVersion: site.phpVersion })
           setCloneSite(siteId, (s) => ({ ...s, verifying: false, verify: res }))
         } catch (err) {
           setCloneSite(siteId, (s) => ({ ...s, verifying: false, verifyError: (err as Error).message }))

package/src/ui/views/CloneWizard.tsx

@@ -48,6 +48,7 @@ export function CloneWizard() {
     cloneServer: server,
     cloneJob: job,
     servers,
+    sitesForServer,
     accountSlug,
     toggleCloneSite,
     toggleCloneSiteUploads,
@@ -473,7 +474,8 @@ export function CloneWizard() {
           <box style={{ height: 1 }} />
           {eligibleDests.map((s, i) => {
             const sel = i === destIdx
-            const meta = `${s.provider_name || "—"} · ${s.region || "—"}${s.ip_address ? "  " + s.ip_address : ""}`
+            const n = sitesForServer(s.id).length
+            const meta = `${n} site${n === 1 ? "" : "s"} · ${s.provider_name || "—"} · ${s.region || "—"}${s.ip_address ? "  " + s.ip_address : ""}`
             return (
               <box key={s.id} style={{ flexDirection: "row", height: 1, backgroundColor: sel ? theme.bgAlt : undefined }}>
                 <text content={sel ? "❯ " : "  "} fg={theme.brand} style={{ flexShrink: 0 }} />