WordPress 7.1 enables media library infinite scrolling by default with a per-user opt-out. A ticket that says images disappeared is not enough to separate a saved user preference, role restriction, filter state, failed REST or admin-ajax request, browser extension conflict, focus issue, memory growth, duplicate result, or attachment metadata problem.
Use this for WordPress support teams, agencies, plugin developers, accessibility testers, publishers, and sites with large or restricted media libraries.
Quick answer
Capture the affected user ID or safe fixture, role, saved infinite-scroll preference, view, search, date and type filters, browser, zoom, assistive technology, plugin set, theme, attachment IDs, and exact request sequence. Reproduce with a small known media fixture and a large production-like fixture. Include console and network errors, response paging fields, focus position, duplicate or missing IDs, memory, and a screen recording with personal information removed.
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 |
|---|
| Saved opt-out | Existing editor user | Pagination appears consistently |
| Default setting | New author user | Infinite scroll loads unique IDs |
| Filter change | Scroll then change month | Old cursor resets without duplicates |
| Media modal | Keyboard and screen reader | Focus and selection remain understandable |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Create a sanitized attachment and user fixture that reproduces the problem. | Record WordPress version, affected role, per-user media setting, browser, extensions, language, zoom, and assistive technology. | Every load returns unique expected attachment IDs for the active filter. |
| Reset filters and cursors when the query context changes. | Capture media view, search term, date and type filters, attachment IDs, total count, and expected page boundary. | Per-user opt-out and default behavior persist correctly. |
| Preserve unique attachment IDs, focus, selection, and announced result counts. | Export the request URL, paging arguments, status, response count, duplicate IDs, missing IDs, timing, and console errors. | Keyboard focus, announcements, and selection survive loading and filter changes. |
| Bound long-session memory and cancel stale requests safely. | Test grid and list views, keyboard-only navigation, screen reader flow, filter changes, modal insertion, and a long scrolling session. | The ticket includes enough sanitized evidence for another person to reproduce it. |
What to check first
- Record WordPress version, affected role, per-user media setting, browser, extensions, language, zoom, and assistive technology.
- Capture media view, search term, date and type filters, attachment IDs, total count, and expected page boundary.
- Export the request URL, paging arguments, status, response count, duplicate IDs, missing IDs, timing, and console errors.
- Test grid and list views, keyboard-only navigation, screen reader flow, filter changes, modal insertion, and a long scrolling session.
- Retest with a new user, default preference, minimal plugins, standard theme, and the same attachment fixture.
Field notes
- Use attachment IDs instead of filenames when duplicates or regenerated files exist.
- Redact private media URLs and user details from public tickets.
- Include a smallest fixture and a large-library fixture so maintainers can reproduce both logic and scale.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
ticket,wp,user_role,setting,view,filter,start_cursor,requests,unique_ids,missing,focus,memory_mb,result
MED-71,7.1-RC2,editor,infinite,grid,images,0,6,240,0,stable,188,pass
MED-72,7.1-RC2,author,infinite,grid,month-change,120,3,78,2,lost,244,fix
MED-73,7.1-RC2,editor,paged,list,all,0,4,160,0,stable,132,pass
Why this usually happens
- The behavior is per user, so two administrators can see different controls on the same site.
- A stale cursor after search or filter changes can repeat or omit attachment IDs.
- Focus and memory regressions emerge only after several loads or inside the editor modal.
Decision rule
Escalate a ticket when the same sanitized fixture reproduces with recorded user preference and request evidence, or when an accessibility failure is clear even if the attachment list eventually loads.
Production verification checklist
- Every load returns unique expected attachment IDs for the active filter.
- Per-user opt-out and default behavior persist correctly.
- Keyboard focus, announcements, and selection survive loading and filter changes.
- The ticket includes enough sanitized evidence for another person to reproduce it.
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.
- Create a sanitized attachment and user fixture that reproduces the problem.
- Reset filters and cursors when the query context changes.
- Preserve unique attachment IDs, focus, selection, and announced result counts.
- Bound long-session memory and cancel stale requests safely.
- Attach the exact evidence package and verify the fix in both media views and editor modals.
Mistakes to avoid
- Changing production before preserving a reproducible fixture, timestamps, and the current result.
- Treating one successful screen, request, or export as proof that every downstream system agrees.
- Removing logs, identifiers, or rollback evidence before the owner and failure boundary are known.
- Testing only an administrator session instead of the roles, devices, consent states, and failure paths users actually have.
Questions teams ask during testing
Can this be tested on production?
Use production for read-only confirmation and a narrow synthetic fixture. Perform destructive, version, cache-policy, queue, or schema changes on staging first, then promote the smallest proven change.
What evidence should be kept?
Keep versions, fixture IDs, UTC timestamps, request or export evidence, expected and actual results, the decision owner, rollback point, and the final clean verification. Redact personal data.
When is the work finished?
Finish when the canonical user path passes, downstream records reconcile, failure cases are understood, monitoring is in place, and an established page links to the new guide with useful context.
What to tell the client or owner
Give the owner the affected versions, exact fixture, stable IDs, UTC timeline, before and after evidence, decision, rollback point, unresolved risks, and next review date.
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, diagnose a WordPress media library issue.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Report duplicate and missing attachment IDs
When the ticket shows repeated or missing media, use the WordPress 7.1 media cursor duplicate-ID report to preserve query state, cursors, response order, mutations, focus, and the exact attachment set.
Helpful references