filepond: fix crash 'can't access property main, n.status is undefined'

Fixes three root causes of FilePond errors on TFE upload forms:

1. server.process.onerror accessed .status on a string (XHR response
   text body) — now extracts the body safely.

2. server.load was a bare URL string with no error handling — converted
   to object with onload/onerror to prevent FilePond internal _write
   crash when load.php returns HTTP errors.

3. destroyFilePondsIn now aborts in-flight processing before pond.destroy()
   to prevent stale XHR callbacks firing on a torn-down FilePond instance.

Server-side: FilepondHandler now emits Content-Type: text/plain on all
responses (PHP defaults to text/html on die(), confusing FilePond's
response parser).
This commit is contained in:
Pontoporeia
2026-06-09 21:53:08 +02:00
parent 38ef550397
commit 2829d13a16
4 changed files with 68 additions and 10 deletions

View File

@@ -13,3 +13,11 @@ Reference: `docs/autosave-system.md` → "HTMX v2 Migration Plan" section.
- [x] Fix backend `$isAjax` detection: also recognize `HX-Request` header (page.php, apropos.php, form-help.php)
- [x] Form-help inline editors: add OverType toolbar + HTMX auto-save + remove save buttons
- [x] Markdown cheatsheet modal: reusable dialog on all OverType editors
## FilePond error fixes
- [x] Fix `server.process.onerror`: don't access `response.status` on string (response is XHR text body)
- [x] Fix `server.load`: convert from string URL to object with proper `onload`/`onerror` handlers
- [x] Fix `server.process.onload`: guard against non-ID responses (e.g. HTML error pages disguised as 200)
- [x] Fix `destroyFilePondsIn`: abort in-flight uploads before destroying to prevent stale XHR callbacks crashing `_write`
- [x] Fix `FilepondHandler.php`: set `Content-Type: text/plain` header at top of `handleProcess`, `handleLoad`, `handleRevert`, `handleRemove` so PHP doesn't default to `text/html` on `die()`