Always send an admin password so a renamed admin user can't block site startup

[wojtekn]

Related issues

• N/A

How AI was used in this PR

Claude Code investigated the failure from a real broken site, traced it to the admin-credentials request builder, wrote the fix and the regression test, and verified it end-to-end by rebuilding the CLI and starting the affected site.

Proposed Changes

Changing a site's admin username in Settings — without also setting a password — left the site unable to start. Every start attempt failed with Failed to set admin credentials: Password is required to create a new admin user, and the server process was killed.

The cause was an inconsistent treatment of "no stored password" across the codebase. The settings screen displayed password as a default in the field, but that value was never persisted, and the startup path omitted the password from its request entirely when none was stored. WordPress can update an existing user without a password, but it cannot create one — so as soon as the username named a user that didn't exist yet, startup failed outright.

This makes the default a real value rather than field decoration: it now lives in @studio/common as a single source of truth and is actually sent to the CLI. A site in this state starts normally again and the renamed admin user is created, with the original user left intact (existing behavior). No action is needed from users whose sites already work.

Two related inconsistencies are fixed along the way:

• The site overview showed an empty password for sites with none stored, rather than the one the site actually uses.
• apps/local compared an unset password against '' while the desktop compared against the encoded default, so a settings save could behave differently in the browser UI than in the desktop app.

Known gap, not addressed here: when startup fails this way, Studio misreports it as a PHP error — isPhpUserError() treats any non-infrastructure error as user PHP, and parsePhpError() finds nothing quotable in a Node stack trace, so the user sees a bare "PHP error during startup" page and a file watcher waiting for a .php edit that can never fix it. That misclassification is what made this bug hard to diagnose, and is worth a follow-up.

Testing Instructions

Reproducing on trunk:

1. Create a site, then in Settings change the admin username to something that doesn't exist yet (e.g. admine) and save without touching the password field.
2. Stop and start the site — it fails to start, showing a "PHP Error Detected / PHP error during startup" page.
3. Confirm the real error in ~/.studio/daemon/logs/studio-site-<siteId>-error-*.log: Password is required to create a new admin user.

With this branch, step 2 starts normally and the new admin user is created.

Also worth checking:

• Settings → admin password field still shows and saves correctly; changing the password still applies.
• Site overview shows admin credentials for a site that has never had a password saved.
• Creating a new site still gets a randomly generated password (not the shared default).
• Verify in both the Desktop app and the browser UI (npm run cli:build:ui && node apps/cli/dist/cli/main.mjs ui --no-open), since both front ends are touched.

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

🤖 Generated with Claude Code

[wpmobilebot]

📊 Performance Test Results

Comparing 1e5fe59 vs trunk

app-size

Metric	trunk	1e5fe59	Diff	Change
App Size (Mac)	1458.88 MB	1458.21 MB	0.67 MB	⚪ 0.0%

site-editor

Metric	trunk	1e5fe59	Diff	Change
load	1193 ms	1214 ms	+21 ms	⚪ 0.0%

site-startup

Metric	trunk	1e5fe59	Diff	Change
siteCreation	7532 ms	7542 ms	+10 ms	⚪ 0.0%
siteStartup	3369 ms	3367 ms	2 ms	⚪ 0.0%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)