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>
m038andClaude Opus 4.8
525b684493