WordPress 7.1 testing includes more client-side media processing work. A strict Content Security Policy, blocked blob worker, unsupported codec, memory pressure, browser extension, or mobile backgrounding can stop processing before the normal WordPress upload path receives a file.
Use this for sites with strict CSP headers, security plugins, headless admin access, large HEIC or AVIF uploads, mobile editors, custom media workflows, or browser-specific upload complaints.
Quick answer
Test the same source file in a clean browser profile with console, network, and response headers recorded. If the worker cannot start or process the file, the interface should preserve the original, explain the fallback, and either upload safely to the server path or stop without creating a partial attachment.
What to check first
- Record the browser, operating system, device memory, source format, pixel dimensions, file size, CSP header, worker-src policy, and active browser extensions.
- Upload small JPEG, large JPEG, HEIC, AVIF, transparent PNG, rotated EXIF image, and a deliberately corrupt file while capturing console and network output.
- Repeat with report-only CSP, enforced CSP, blob workers allowed, blob workers blocked, and a clean browser profile.
- Background the mobile browser or trigger memory pressure during processing, then return and inspect retry, resume, duplicate, and partial attachment behavior.
- Confirm metadata policy, orientation, color, quality, filename, MIME type, attachment record, generated sizes, and server fallback match the site's expectations.
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 |
|---|
| Build a media fixture set | Record the browser, operating system, device memory, source format, pixel dimensions, file size, CSP header, worker-src policy, and active browser extensions. | Supported files complete with correct orientation, dimensions, quality, and attachment metadata. |
| Capture policy and browser evidence | Upload small JPEG, large JPEG, HEIC, AVIF, transparent PNG, rotated EXIF image, and a deliberately corrupt file while capturing console and network output. | Blocked workers produce a clear fallback or safe stop instead of a frozen editor. |
| Test worker allow and block | Repeat with report-only CSP, enforced CSP, blob workers allowed, blob workers blocked, and a clean browser profile. | Interrupted processing does not create duplicate or orphaned attachments. |
| Interrupt processing | Background the mobile browser or trigger memory pressure during processing, then return and inspect retry, resume, duplicate, and partial attachment behavior. | CSP remains as restrictive as intended and is not weakened with a broad wildcard to make one test pass. |
Why this usually happens
- Web Workers and blob URLs can require CSP directives that differ from ordinary scripts.
- Browser codec support and memory limits vary by platform and file type.
- A failed client task can leave an attachment shell before the binary upload completes.
- Fallback code may preserve different metadata or generate different image quality than the worker path.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
Content-Security-Policy: default-src 'self'; script-src 'self'; worker-src 'self' blob:; img-src 'self' data: blob:; connect-src 'self'
# Browser console evidence
worker_state: blocked_by_csp
source_type: image/heic
fallback_attempted: true
attachment_created: false
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.
- Build a media fixture set
- Capture policy and browser evidence
- Test worker allow and block
- Interrupt processing
- Compare fallback output
Decision rule
Allow the client path only when it works under the site's intended CSP and supported browsers. A fallback must preserve user intent, avoid duplicate attachments, and state clearly when the original cannot be processed.
What to tell the client or owner
Share the browser and device, source fixtures, CSP headers and reports, console errors, worker state, network trace, interruption step, attachment IDs, fallback output, metadata comparison, and server image libraries.
Production verification checklist
- Supported files complete with correct orientation, dimensions, quality, and attachment metadata.
- Blocked workers produce a clear fallback or safe stop instead of a frozen editor.
- Interrupted processing does not create duplicate or orphaned attachments.
- CSP remains as restrictive as intended and is not weakened with a broad wildcard to make one test pass.
Mistakes to avoid
- Do not disable CSP globally as the first fix.
- Do not test only Chrome on a desktop with abundant memory.
- Do not ignore EXIF location and color-profile differences between paths.
- Do not leave partial attachment records after a failed test.
Questions teams ask during testing
Should worker-src include blob for every WordPress site?
Only when the site's actual client media implementation requires it and the security owner accepts the policy. Test the exact build and avoid broad directives.
Can the server always process the original file instead?
Server support depends on PHP, ImageMagick or GD, codecs, memory, and host limits. A fallback needs its own fixture and resource tests.
When HandL WP should help
HandL WP can isolate client media failures across WordPress, CSP, browser workers, image codecs, server libraries, and attachment cleanup.
If this is active on a production site, test WordPress 7.1 media processing.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Reconcile the full media fallback path
Use the WordPress 7.1 media client-processing CSP worker fallback audit to connect browser policy, memory, upload tokens, attachments, derivatives, offload objects, retries, and cleanup.
Helpful references