feat(post-form): M2 photo edit — load, remove & reorder from the edit form
Editing an entry now loads its existing photos into FilePond so the owner can remove and reorder them; the first photo is the cover. Adding NEW photos on edit is intentionally suppressed (see below). post-form.js (U7): - On ?edit=, load the entry's current images into FilePond as LOCAL items (via the session media API, gpx-manager pattern). They display for remove/reorder and ride the existing photo_order manifest on submit, but are never re-uploaded. - Exclude the FilePond field from the D1 prefill disable-sweep — FilePond reads its input's disabled state at init and never re-enables, which had removed its controls in edit mode. - Suppress the add affordance in edit mode (allowBrowse/allowDrop off): a new upload on edit hits add-page-by-form's Grav-2.0 edit-merge fatal ((array)$page->header() yields mangled protected keys → array_merge(null,…)). That plugin is stock/GPM/git-ignored (no fork), so adding photos on edit is deferred to the form-to-page/image-upload rework. cache-on-save.php (U8): - reconcilePhotos(): on edit, resolve the entry folder via the shared scope guard (not the fuzzy create-path finder), delete any image dropped from the manifest, then renumber survivors photo-1..N in the submitted order (cover = first). - Run reconciliation ONCE per submit: onFormProcessed fires per process action (4×); a 2nd pass deleted the just-renamed photo-N files as "unlisted". - Empty manifest reconciles nothing (fail-safe: never wipes photos on a missing photo_order). Verified on the container: existing photos load (V9); remove + reorder persist to disk with cover=first (V10); reconcile helpers covered by a reflection unit test. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
File diff suppressed because one or more lines are too long
Reference in New Issue
Block a user