Admin autosave is centralized so forms can protect in-progress edits without each addon creating its own draft table. The shared system stores draft payloads by surface, resource type, resource UUID, owner, and draft UUID.
Owners
- `admin/autosave/autosave.php` owns the `amv_admin_autosaves` table, draft UUID handling, token action naming, payload encoding, and save/delete helpers.
- Addon admin forms own which fields may be autosaved and how restored payloads are merged into the visible form.
- Core owns UUID validation and session/auth context used to associate drafts with users.
How To Call It
- Ensure autosave storage with `amv_admin_autosave_tables_ready($pdo)`.
- Create or preserve a draft UUID and use `amv_admin_autosave_token_action($surfaceKey, $draftUuid)` for CSRF scoping.
- Save allowed form fields with `amv_admin_autosave_save($pdo, $input, $authContext, ['surface_key' => 'wiki', 'resource_type' => 'page', 'allowed_fields' => ['title', 'body_text']])`.
- Load the latest draft for an existing record with `amv_admin_autosave_latest_for_resource()`.
- Delete consumed drafts with the shared delete helper after a successful final save.
Existing Usage
- Runtime bootstrap loads `admin/autosave/autosave.php`, making the helpers available to admin surfaces.
- The autosave schema creates `amv_admin_autosaves` with indexes for draft UUID, surface/resource, owner, and updated time.
- The helper accepts create and edit flows by leaving `resource_uuid` null for create drafts and setting it for existing records.
Do Not Duplicate
- Do not add addon-specific autosave tables unless the shared table cannot represent the workflow.
- Do not autosave every request field; pass a deliberate allow-list.
- Do not treat autosave rows as published content.
- Do not share one draft UUID across unrelated forms or surfaces.