Feature request: SpawnWP Deploy — remember & pre-fill the blueprint capture form

[wpeasy]

Plugin: spawnwp-deploy · File: src/class-blueprint.php (render_panel() + step_prepare())

Summary
The "Create a SpawnWP blueprint from this site" form re-reads every field from scratch on each capture, with only static defaults (version = 1.0.0, all capture boxes checked, PHP boxes = current PHP). Nothing the user typed last time is remembered. Re-pushing an update to an existing blueprint therefore means re-entering the id, name, description, version and capture options identically — and if the id is mistyped, the ingest creates a new blueprint instead of replacing (replace only applies when the id matches an existing schema-v2 blueprint).

Why it matters
The documented workflow — update the source site, re-push to replace the same blueprint — is exactly the case where pre-fill helps most: the operator wants the same id/name and usually the same capture options, just a bumped version. Today that's manual re-entry every time, and an easy way to accidentally fork a new blueprint.

Proposed change (small, ~2 hooks)
Persist the validated fields on capture. In step_prepare(), right after $fields = self::capture_fields();:
update_option( 'spawnwp_deploy_last_blueprint', $fields, false );
capture_fields() already returns exactly id, name, description, version, php_default, php_allowed, capture — ideal to store.

Pre-fill in render_panel(). Read the option once and use it for each input's value / checked / selected, falling back to the existing defaults so a first-ever capture is unchanged:
$last = (array) get_option( 'spawnwp_deploy_last_blueprint', array() );
$last_capture = $last['capture'] ?? array( 'plugins'=>true,'themes'=>true,'uploads'=>true,'database'=>true );
$last_allowed = $last['php_allowed'] ?? array( $php_pin );
$last_default = $last['php_default'] ?? $php_pin;
// id/name/description → value="" etc.
// version → value=""
// capture boxes →
// PHP boxes →
// PHP default select →
Optional niceties (fall out of the above)
Scope per connection (spawnwp_deploy_last_blueprint_<connection_id>) if you support multiple SpawnWP servers with different blueprint sets — you already key other state (spawnwp_deploy_last_job_*) by connection.
Auto-select "replace" when the pre-filled id already exists — the preflight already returns existing_blueprint_ids + replaceable, so the form can tick "replace existing" automatically and reassure the user they're updating, not forking.
Auto-bump the patch (1.0.0 → 1.0.1) on pre-fill so each re-push is a new version by default.
Verification
Implemented as above on a live install; form now pre-fills from the previous capture, and a first-ever capture is unchanged (empty id/name/description, 1.0.0, all boxes checked, current-PHP selected). No JS changes required — the existing JS reads the same element values.

[tts-empire]

Shipped in 0.3.4-dev, essentially as you proposed: https://spawnwp.com/plugin/

The form now pre-fills from your previous capture — id, name, description, capture options and PHP set — with the patch version bumped (1.4.9 → 1.4.10). A first-ever capture is unchanged.

Three notes on where I went slightly differently, and one where you were ahead of me.

Scoped per connection, as your "optional nicety" suggested, rather than the single global option. You were right that the plugin already keys state that way (spawnwp_deploy_last_job_<connection_id>), and two SpawnWP servers holding different blueprint sets is exactly the case where a global memory would hand you the wrong id to re-push.

Saved before the package build, not after. remember_fields() runs immediately after capture_fields() validates — so the fields survive a capture that fails (an oversized payload, an unreachable server). That's precisely when retyping everything hurts, and it's verified: a capture forced to fail at the remote hop still leaves the form filled on reload.

The stored option is re-checked, never trusted. If PHP_CHOICES ever drops a version, a blueprint captured against it would otherwise render the PHP row with nothing ticked — and capture_fields() would then reject a form the user never touched ("Select at least one PHP version"). Same for a capture set that somehow came back all-false. Both now fall back to sane defaults.

And one small thing: the auto-select "replace" you suggested already exists. There's no replace checkbox to tick — capture() calls preflight, and when the id is already on the server it confirms with you and sets replace=1 itself (and refuses outright if the existing blueprint isn't replaceable). So that half was already covered; I mention it only so you know it wasn't skipped.

One thing pre-filling does change: it biases the form towards replacing the last blueprint, which makes starting a genuinely new one slightly harder. So there's now a Start a new blueprint button that clears the form.

Thanks — this was a well-argued request, and the "a typo'd id silently forks a new blueprint instead of replacing" framing is what made it obviously worth doing rather than just a convenience.