WordPress 7.1 media changes increase the importance of tracing orientation, derivatives, and cache identity. After EXIF correction, image edit, replacement, or regeneration, origin and CDN may keep different bytes under one stable filename, while social providers cache a separate Open Graph URL.
Use this for publishing, ecommerce, real estate, restaurants, portfolios, and user-generated content where phone photos pass through optimization, object storage, CDN, SEO, and social preview plugins.
Quick answer
Create orientation fixtures and record every original and derivative URL, metadata row, ETag, Last-Modified, pixel hash, and social image tag. Compare stable-name replacement with a versioned filename on staging. Choose the strategy that gives reliable invalidation, attachment ownership, rollback, and external preview refresh without orphaning responsive sizes.
What to check first
- Create JPEG orientation fixtures 1, 3, 6, and 8, plus HEIC, stripped normalized copies, edited crops, replacements, and regenerated derivatives.
- Record attachment ID, operation, original file, derivative names, metadata URLs, dimensions, pixel hashes, origin validators, CDN validators, Open Graph URL, and provider scrape time.
- Test upload, edit, rotate, crop, scale, replace, regenerate, offload, restore, delete, and social metadata refresh with stable and versioned names.
- Purge origin and CDN in the documented order, then fetch bytes directly and through the public URL before asking providers to re-scrape.
- Check editor, frontend, srcset, lazy loading, CDN, feeds, email, Open Graph, rollback, backups, and object-storage cleanup.
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 orientation and edit fixtures | Create JPEG orientation fixtures 1, 3, 6, and 8, plus HEIC, stripped normalized copies, edited crops, replacements, and regenerated derivatives. | Origin and CDN return the same intended pixel hash and MIME type. |
| Capture filenames, hashes, and validators | Record attachment ID, operation, original file, derivative names, metadata URLs, dimensions, pixel hashes, origin validators, CDN validators, Open Graph URL, and provider scrape time. | Responsive and social metadata reference files that exist. |
| Compare stable and versioned strategies | Test upload, edit, rotate, crop, scale, replace, regenerate, offload, restore, delete, and social metadata refresh with stable and versioned names. | A replacement or rollback refreshes every required consumer predictably. |
| Verify every consumer and cache | Purge origin and CDN in the documented order, then fetch bytes directly and through the public URL before asking providers to re-scrape. | Old versions are retained or deleted according to policy without breaking live references. |
Why this usually happens
- A stable URL can retain old CDN or social bytes after attachment metadata changes.
- Versioned derivatives can be generated without updating every reference.
- Offload and optimization plugins may write different filename conventions.
- Rollback can restore metadata but not the old object version.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
attachment_id: 2841
operation: replace_and_normalize
stable_url: photo-1200x800.jpg
versioned_url: photo-v3-1200x800.jpg
origin_hash_changed: true
cdn_hash_matches_origin: true
og_url: photo-v3-1200x630.webp
social_preview: correct
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 orientation and edit fixtures
- Capture filenames, hashes, and validators
- Compare stable and versioned strategies
- Verify every consumer and cache
- Document rollback and cleanup
Decision rule
Pass when attachment metadata, origin bytes, CDN bytes, srcset, Open Graph tags, social preview, rollback, and cleanup all reference the intended image version with correct orientation.
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 CDN return the same intended pixel hash and MIME type.
- Responsive and social metadata reference files that exist.
- A replacement or rollback refreshes every required consumer predictably.
- Old versions are retained or deleted according to policy without breaking live references.
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
Are versioned filenames always better?
They simplify cache identity, but only if every reference updates and old files follow a controlled retention policy.
Can a CDN purge refresh social previews?
Not by itself. Social platforms maintain separate caches and may require a re-scrape or a new URL.
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, fix WordPress image cache problems.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references