WordPress 7.1 Beta 3 corrects EXIF orientation behavior, but a CDN can retain transforms generated from the earlier pixel layout or cache under a URL that does not change when attachment metadata changes. Mobile srcset and Open Graph consumers may therefore keep a rotated copy after wp-admin looks fixed.
Use this for image CDNs, optimization services, object storage, social previews, ecommerce galleries, real-estate photos, and phone-upload workflows with multiple responsive sizes.
Quick answer
Upload labeled EXIF fixtures, inventory every origin and CDN URL, and record pixel dimensions plus orientation for each candidate. Purge the exact keys, fetch with cache-busting diagnostics only for comparison, and confirm browsers and social preview tools select corrected derivatives.
What to check first
- Record source hash, EXIF value, expected displayed dimensions, attachment metadata, generated sizes, srcset, CDN transform parameters, cache key policy, and purge API result.
- Fetch the origin original, WordPress sizes, WebP or AVIF variants, CDN transforms, featured image, and Open Graph image before and after correction.
- Use desktop and mobile viewports to record the actual currentSrc URL rather than assuming which srcset candidate loaded.
- Purge by URL, tag, or asset identifier as supported, then compare Age, ETag, Last-Modified, content length, checksum, dimensions, and visible corner labels.
- Test a metadata regeneration and an image replacement to learn whether the CDN key changes or requires explicit invalidation.
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 fixture and URL inventory | Record source hash, EXIF value, expected displayed dimensions, attachment metadata, generated sizes, srcset, CDN transform parameters, cache key policy, and purge API result. | Origin and all WordPress derivatives agree on orientation and dimensions. |
| Measure origin and edge outputs | Fetch the origin original, WordPress sizes, WebP or AVIF variants, CDN transforms, featured image, and Open Graph image before and after correction. | CDN objects change after the documented purge action. |
| Identify the derivative cache key | Use desktop and mobile viewports to record the actual currentSrc URL rather than assuming which srcset candidate loaded. | Desktop and mobile currentSrc URLs are corrected. |
| Purge targeted keys and social previews | Purge by URL, tag, or asset identifier as supported, then compare Age, ETag, Last-Modified, content length, checksum, dimensions, and visible corner labels. | Featured, gallery, and Open Graph images agree. |
Why this usually happens
- The CDN transform can be cached from pre-correction source pixels.
- Attachment metadata can change without changing the public image URL.
- A mobile browser may select a stale candidate that desktop never requests.
- Social crawlers can cache Open Graph images independently from the site CDN.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
fixture: orientation-6-corners.jpg
attachment_id: 9440
origin_display: 3024x4032
cdn_candidate: /cdn-cgi/image/w=768/...
cdn_before: 4032x3024
purge_status: accepted
cdn_after: 3024x4032
mobile_current_src: corrected
open_graph_preview: corrected
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 fixture and URL inventory
- Measure origin and edge outputs
- Identify the derivative cache key
- Purge targeted keys and social previews
- Retest actual browser selections
Decision rule
Pass when every production candidate reports corrected dimensions and visible orientation, currentSrc is correct at each viewport, cache headers prove refreshed objects, and Open Graph consumers no longer serve the stale image.
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
- Origin and all WordPress derivatives agree on orientation and dimensions.
- CDN objects change after the documented purge action.
- Desktop and mobile currentSrc URLs are corrected.
- Featured, gallery, and Open Graph images agree.
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, or delayed background work.
- Do not paste secrets, personal data, or complete production payloads into tickets or screenshots.
- Do not close the test until the final user-visible state and server-side evidence agree.
Questions teams ask during testing
Why does wp-admin look right while mobile is rotated?
The browser may select a different cached srcset candidate. Capture currentSrc and inspect that exact object.
Is a query-string cache buster the fix?
It is useful for diagnosis, but the durable fix is a correct cache-key and invalidation strategy tied to media changes.
When HandL WP should help
Bring in HandL WP when this affects a production site, paid lead flow, checkout, email delivery, or a managed fleet. We can preserve evidence, isolate the failing layer, make the smallest corrective change, and verify the result across WordPress, the external service, logs, and the user journey.
If this is active on a production site, fix a WordPress CDN image regression.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references