WordPress 7.1 client-side media processing adds sideload and finalize REST behavior plus independent sub-size uploads. A timeout, offline transition, plugin exception, or failed finalize can leave an attachment, original, derivative, companion video, poster, or metadata record in a partial state.
Use this for media plugins, offload integrations, image optimizers, security tools, DAM connectors, backup tools, and sites testing large JPEG, HEIC, AVIF, WebP, or animated GIF uploads in WordPress 7.1 Beta 4.
Quick answer
Create uniquely named test assets and record attachment ID, original, every sub-size, companion file, poster, request ID, response, metadata version, and storage key. Interrupt each boundary, retry with the same fixture, then reconcile the database, filesystem, object storage, editor, frontend, and cleanup queue before deleting anything.
What to check first
- Record WordPress Beta 4 build, browser, device memory, file type, dimensions, client-processing state, media plugins, offload, CSP, object cache, REST authentication, and registered image sizes.
- Capture sideload request, attachment ID, original filename, sub-size names, companion video and poster, upload attempt, HTTP result, retry, finalize response, metadata, object keys, and checksums.
- Interrupt after sideload, during one sub-size upload, after all files but before finalize, inside a finalize plugin hook, while offline, after a timeout response, and during a duplicate retry.
- Compare attachment post, metadata, missing-image-size fields, origin files, object storage, responsive markup, editor preview, frontend image, backup manifest, and cleanup logs.
- Repair by verifying bytes first, retrying only missing operations with stable identity, finalizing once, regenerating only proven missing metadata, and quarantining orphans through a rollback window.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Create uniquely identified fixtures | Record WordPress Beta 4 build, browser, device memory, file type, dimensions, client-processing state, media plugins, offload, CSP, object cache, REST authentication, and registered image sizes. | The attachment ID, original, derivatives, companion files, metadata, and storage keys agree. |
| Capture every REST boundary | Capture sideload request, attachment ID, original filename, sub-size names, companion video and poster, upload attempt, HTTP result, retry, finalize response, metadata, object keys, and checksums. | A duplicate sideload or finalize retry creates no extra attachment, object, metadata pass, or external job. |
| Interrupt one operation at a time | Interrupt after sideload, during one sub-size upload, after all files but before finalize, inside a finalize plugin hook, while offline, after a timeout response, and during a duplicate retry. | Editor and frontend use existing verified files and show no broken responsive source. |
| Reconcile files and metadata | Compare attachment post, metadata, missing-image-size fields, origin files, object storage, responsive markup, editor preview, frontend image, backup manifest, and cleanup logs. | The orphan report distinguishes referenced, recoverable, quarantined, and safe-to-delete files with evidence. |
Why this usually happens
- The browser uploads the original and derivatives through independent requests.
- Finalize is best effort, so upload success does not prove every plugin side effect completed.
- An offload plugin can copy an object before attachment metadata commits.
- A retry can create a second file or side effect when request identity is not preserved.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
attachment_id: 48102
source: camera-heic-01.heic
sideload: 201
sub_sizes: [thumbnail=201, medium=timeout, large=201]
companion_poster: uploaded
finalize: not_started
retry_key: media:48102:medium
cleanup_hold_until: 2026-08-07
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Create uniquely identified fixtures
- Capture every REST boundary
- Interrupt one operation at a time
- Reconcile files and metadata
- Retry safely and quarantine orphans
Decision rule
Pass when every successful upload has one coherent attachment, intended files and metadata, duplicate retries create nothing extra, failed operations remain recoverable, and cleanup removes only proven unreferenced files.
What to tell the client or owner
Give the owner the affected versions, exact workflow, observed result, business impact, evidence location, temporary control, named owner, and next review time. Remove credentials and personal data from shared screenshots and logs.
Production verification checklist
- The attachment ID, original, derivatives, companion files, metadata, and storage keys agree.
- A duplicate sideload or finalize retry creates no extra attachment, object, metadata pass, or external job.
- Editor and frontend use existing verified files and show no broken responsive source.
- The orphan report distinguishes referenced, recoverable, quarantined, and safe-to-delete files with evidence.
Mistakes to avoid
- Do not change several plugins, cache rules, or infrastructure settings before preserving a baseline.
- Do not treat one successful test as proof for retries, alternate clients, background work, or mixed-version fleets.
- Do not paste secrets, personal data, complete production payloads, or customer files into tickets or screenshots.
- Do not close the test until the final user-visible state and the server-side evidence agree.
Questions teams ask during testing
Does upload success prove finalize completed?
No. Verify finalize response, attachment metadata, plugin logs, files, and user-visible output separately.
Should partial files be deleted immediately?
No. Quarantine them through a recovery window unless they expose sensitive or unsafe content.
When HandL WP should help
Bring in HandL WP when a production checkout, form, editor, security gate, media pipeline, or paid lead workflow is at risk. We can preserve evidence, isolate the failing layer, make the smallest corrective change, and verify the result across WordPress, connected services, logs, and the user journey.
If this is active on a production site, test WordPress 7.1 media workflows.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references