WordPress 7.1 tightens media REST validation around dimensions and processing values. Media, offload, cropper, optimization, and mobile plugins may send missing, string, zero, negative, oversized, or stale width and height values. A request can fail before attachment metadata and remote storage agree.
Use this for media-heavy sites and plugin teams testing crop, resize, offload, optimization, mobile upload, and custom REST clients against WordPress 7.1.
Quick answer
Create synthetic JPEG, PNG, WebP, AVIF, HEIC, animated, portrait, and oversized fixtures. Send supported, omitted, numeric-string, zero, negative, decimal, extreme, and mismatched dimension payloads through every client. Record HTTP status, validation code, attachment ID, metadata, derivative files, offload keys, retry behavior, cleanup, and the visible editor result. Invalid dimensions must fail clearly without leaving a split local and remote record.
What to check first
- Record WordPress, media plugin, REST route, browser or app, PHP image library, offload provider, and processing settings.
- Create small, large, portrait, landscape, transparent, animated, HEIC, AVIF, and corrupted synthetic files.
- Test omitted, integer, numeric-string, zero, negative, decimal, excessive, and stale width and height values.
- Compare REST response, attachment row, metadata, generated sizes, temporary files, remote objects, retries, and editor preview.
- Define cleanup and fallback behavior for every validation failure before production rollout.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Freeze the request schema and exact plugin versions. | Record WordPress, media plugin, REST route, browser or app, PHP image library, offload provider, and processing settings. | Supported media fixtures upload and render with expected dimensions. |
| Normalize client values only where the documented REST contract allows it. | Create small, large, portrait, landscape, transparent, animated, HEIC, AVIF, and corrupted synthetic files. | Invalid values return stable errors and create no durable orphan. |
| Make validation failure cleanup idempotent across local and remote storage. | Test omitted, integer, numeric-string, zero, negative, decimal, excessive, and stale width and height values. | Retries produce one attachment and one remote object set. |
| Retry with a stable upload ID instead of creating a second attachment. | Compare REST response, attachment row, metadata, generated sizes, temporary files, remote objects, retries, and editor preview. | Editor, metadata, local files, offload, cache, and deletion agree. |
Why this usually happens
- Custom clients can serialize numeric values as strings.
- Plugin fallbacks may reuse stale dimensions from a previous transform.
- Validation can fail after a temporary file exists but before metadata completes.
- Offload and local cleanup can run on different clocks.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
case,width,height,http,attachment,sizes,remote,temp,result
D1,1600,900,201,801,5,5,clean,pass
D2,'1600','900',400,none,0,0,clean,contract
D3,-1,900,400,none,0,0,clean,pass
D4,1600,900,201,802,5,10,clean,fail
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 |
|---|
| Valid integers | 1600 by 900 | Attachment and sizes complete |
| Numeric strings | '1600' and '900' | Document accepted or rejected contract |
| Invalid range | zero, negative, extreme | Clear 4xx and no orphan |
| Retry after failure | corrected dimensions | One attachment, one object set |
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 the request schema and exact plugin versions.
- Normalize client values only where the documented REST contract allows it.
- Make validation failure cleanup idempotent across local and remote storage.
- Retry with a stable upload ID instead of creating a second attachment.
- Retest derivative counts, metadata, editor preview, and deletion.
Decision rule
Approve a media client only when valid dimensions complete one reconciled attachment and every invalid case fails visibly without orphaned files, duplicate records, or silent fallback distortion.
Production verification checklist
- Supported media fixtures upload and render with expected dimensions.
- Invalid values return stable errors and create no durable orphan.
- Retries produce one attachment and one remote object set.
- Editor, metadata, local files, offload, cache, and deletion agree.
Field notes
- Use non-customer images with known dimensions.
- Test both Imagick and GD where the fleet differs.
- Keep original-retention policy explicit.
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 change inventory. Perform destructive repairs, upgrades, cache changes, and schema work 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 customer data, credentials, tokens, addresses, and private infrastructure details.
When is the task complete?
Complete the task 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.
Mistakes to avoid
- Changing production before recording exact versions, UTC timestamps, stable fixture IDs, current settings, and a reproducible baseline.
- Treating one successful screen as proof that background jobs, APIs, caches, roles, reports, and downstream records agree.
- Deleting logs or identifiers before the failure boundary, business impact, rollback point, and accountable owner are known.
- Testing only an administrator session instead of the devices, roles, networks, data states, and failure paths real users have.
What to tell the client or owner
Give the site owner the affected versions, exact synthetic fixture, UTC timeline, before and after evidence, current 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 WordPress media compatibility.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references