spinuptui 0.19.1 → 0.20.0

package/CHANGELOG.md

@@ -11,6 +11,56 @@ 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
@@ -929,7 +979,8 @@ 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.1...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

package/README.md

@@ -592,7 +592,8 @@ over SSH). The steps:
    `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.1",
+  "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 }} />