WordPress 7.1 media work can involve client-side processing before the upload reaches the server. A strict Content Security Policy, browser limit, extension, network condition, or worker startup error can change the path. The dangerous result is a silent partial upload, duplicate attachment, missing derivative, or mobile tab crash that looks like a normal retry.
Use this for sites with custom CSP headers, security plugins, CDNs, media offload, optimization plugins, mobile editors, or large image workflows on WordPress 7.1.
Quick answer
Create controlled image fixtures and test the normal worker path, an intentionally blocked worker, low-memory mobile emulation, offline interruption, retry, and server fallback. Capture browser console, CSP report, network request, upload token, attachment ID, metadata, generated sizes, temporary files, remote objects, and visible editor state. A fallback passes only when the user gets one clear outcome and storage reconciles to one attachment.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Worker starts | Desktop JPEG | One attachment and expected sizes |
| CSP blocks worker | Report and enforce modes | Clear fallback or actionable error |
| Mobile pressure | Large portrait HEIC | No tab crash or duplicate |
| Interrupted retry | Same upload token | One final object set |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Freeze headers, versions, browser evidence, and a stable synthetic upload fixture. | Record the exact CSP header, browser, device memory, WordPress version, media plugins, offload provider, and image library. | CSP report-only and enforce tests match the documented worker policy. |
| Make the supported worker sources explicit in CSP or keep a tested server fallback. | Use known JPEG, PNG, WebP, AVIF, HEIC, animated, oversized, portrait, and corrupted fixtures. | Blocked and low-memory paths do not create duplicate attachments or remote objects. |
| Use one idempotent upload token across client, server, offload, and retry paths. | Block the relevant worker path in staging and capture console, CSP report-only, network, memory, and user-facing behavior. | Retries preserve one upload token and finish or clean up completely. |
| Clean temporary and remote artifacts when validation or processing fails. | Compare normal, blocked, offline, retry, and server-fallback paths by stable upload token and attachment ID. | Editor preview, metadata, local storage, offload, cache, and deletion agree. |
What to check first
- Record the exact CSP header, browser, device memory, WordPress version, media plugins, offload provider, and image library.
- Use known JPEG, PNG, WebP, AVIF, HEIC, animated, oversized, portrait, and corrupted fixtures.
- Block the relevant worker path in staging and capture console, CSP report-only, network, memory, and user-facing behavior.
- Compare normal, blocked, offline, retry, and server-fallback paths by stable upload token and attachment ID.
- Reconcile database rows, metadata, derivatives, temporary files, remote objects, cache keys, and deletion behavior.
Field notes
- Use synthetic IDs and examples that can be traced from the first request to the final record.
- Keep a before and after result for every changed setting or deployed version.
- Review the evidence again after caches, queues, and scheduled work have had time to settle.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
case,browser,csp,worker,http,attachment,local,remote,user_result
M1,chrome,allow,started,201,901,6,6,complete
M2,chrome,block,denied,201,902,6,6,fallback
M3,safari,block,denied,0,none,0,0,clear_error
M4,mobile,allow,crash_retry,201,903,6,12,fail
Why this usually happens
- A CSP can permit the editor script but block blob or worker execution.
- Browser memory limits differ sharply from desktop staging tests.
- Client and server retry logic can each believe they own cleanup.
- Offload, metadata, and derivative jobs can finish on different schedules.
Decision rule
Approve the media path only when worker success and every supported fallback produce one understandable user outcome, one attachment, and one reconciled derivative set.
Production verification checklist
- CSP report-only and enforce tests match the documented worker policy.
- Blocked and low-memory paths do not create duplicate attachments or remote objects.
- Retries preserve one upload token and finish or clean up completely.
- Editor preview, metadata, local storage, offload, cache, and deletion agree.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Freeze headers, versions, browser evidence, and a stable synthetic upload fixture.
- Make the supported worker sources explicit in CSP or keep a tested server fallback.
- Use one idempotent upload token across client, server, offload, and retry paths.
- Clean temporary and remote artifacts when validation or processing fails.
- Retest the editor preview, metadata, derivatives, deletion, and mobile memory budget.
Mistakes to avoid
- Changing production before recording exact versions, UTC timestamps, stable fixture IDs, settings, and a reproducible baseline.
- Treating one successful screen as proof that APIs, caches, jobs, roles, reports, and downstream records agree.
- Testing only an administrator session instead of the devices, roles, networks, data states, and failure branches customers use.
- Closing the task without a named owner, rollback point, observation window, and contextual incoming link from an established guide.
Questions teams ask during testing
Can this be tested on production?
Use production for read-only confirmation and one narrow synthetic fixture that cannot charge a card, email a real customer, expose personal data, or alter inventory. Run upgrades, schema changes, cache changes, and destructive repairs on staging first.
What evidence should the report keep?
Keep exact versions, UTC timestamps, stable synthetic IDs, expected and actual results, the decision owner, rollback point, and final verification. Redact credentials, tokens, customer data, addresses, and private infrastructure details.
When is the task complete?
Complete it when the primary user path passes, downstream records reconcile, failure branches are understood, monitoring is active, and an established owner page links to the new guide in context.
What to tell the client or owner
Give the site owner the affected versions, exact synthetic fixture, UTC timeline, before and after evidence, cause class, decision, rollback point, unresolved risks, and next review date. State which measurements prove success and which observation window remains open.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, audit a WordPress media upload failure.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references