WordPress 7.1 enables media library infinite scrolling by default with a per-user opt-out. Repeated thumbnails, missing attachments, stale searches, and lost focus can be caused by a cursor that survives a changed query, a concurrent upload or deletion, an out-of-order response, role restrictions, cached results, or duplicate filenames. Screenshots alone do not identify the failing boundary.
Use this for WordPress support teams, publishers, accessibility testers, plugin developers, and sites with large or restricted media libraries.
Quick answer
Create a sanitized media fixture with known attachment IDs, dates, MIME types, authors, and permissions. Capture the affected user's infinite-scroll preference, role, view, filters, search, cursor, request sequence, response IDs, total count, focus, and mutations. Compare each response to the ordered expected set. Reset the cursor whenever query context changes, ignore stale responses, and report duplicate and missing attachment IDs rather than filenames.
What to check first
- Record WordPress build, role, per-user setting, grid or list view, browser, extensions, zoom, language, and assistive technology.
- Define expected attachment IDs for each author, date, MIME type, search term, permission, and result order.
- Capture request number, query, cursor, status, response IDs, duplicates, missing IDs, total count, latency, and completion order.
- Insert uploads and deletions between pages, then change filters and search while an earlier request is still pending.
- Track keyboard focus, announcements, selected attachment, memory, and whether the media modal behaves like the standalone library.
Why this usually happens
- The behavior is saved per user, so two administrators can have different controls.
- A stale cursor can be reused after search, filter, date, or view changes.
- Out-of-order responses can append an older page into a newer result set.
- Filenames and thumbnails can repeat even when attachment IDs differ.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
request,query,cursor,mutation,response_ids,duplicates,missing,focus,result
1,images,0,none,101-140,0,0,stable,pass
2,images,140,upload-181,141-180,0,0,stable,pass
3,pdfs,reset,old-response,141-160,20,12,lost,fail
4,pdfs,0,none,201-232,0,0,stable,pass
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Freeze a sanitized attachment, user, permission, and query fixture. | Record WordPress build, role, per-user setting, grid or list view, browser, extensions, zoom, language, and assistive technology. | Each query returns the complete expected attachment-ID set exactly once. |
| Reset cursors and result identity whenever the query context changes. | Define expected attachment IDs for each author, date, MIME type, search term, permission, and result order. | Search, filter, date, view, upload, and deletion changes reset state correctly. |
| Cancel or ignore stale responses and deduplicate by attachment ID. | Capture request number, query, cursor, status, response IDs, duplicates, missing IDs, total count, latency, and completion order. | Keyboard focus, announcements, and selection remain understandable. |
| Preserve focus, selection, announced counts, and role restrictions. | Insert uploads and deletions between pages, then change filters and search while an earlier request is still pending. | Another support engineer can reproduce the result from the sanitized report. |
Decision rule
Escalate when the same fixture repeats or omits IDs, appends a stale response, leaks restricted metadata, or loses keyboard context even if the library eventually displays some results.
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 |
|---|
| Stable query | Six sequential responses | Every expected ID appears once |
| Filter change | Pending old response then new month | Old cursor and response are rejected |
| Concurrent upload | New attachment enters the result set | Documented ordering without duplicates |
| Role restriction | Author cannot view another user's private media | No leaked ID or misleading total |
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 a sanitized attachment, user, permission, and query fixture.
- Reset cursors and result identity whenever the query context changes.
- Cancel or ignore stale responses and deduplicate by attachment ID.
- Preserve focus, selection, announced counts, and role restrictions.
- Attach the ordered evidence package and retest grid, list, and editor modal flows.
Production verification checklist
- Each query returns the complete expected attachment-ID set exactly once.
- Search, filter, date, view, upload, and deletion changes reset state correctly.
- Keyboard focus, announcements, and selection remain understandable.
- Another support engineer can reproduce the result from the sanitized report.
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. State which measurements prove success and which observation window still remains.
Mistakes to avoid
- Changing production before preserving the current result, exact versions, timestamps, and a reproducible fixture.
- Treating one successful screen or request as proof that every queue, provider, report, browser, and customer path agrees.
- Removing logs, identifiers, or rollback evidence before the failure boundary and accountable owner are known.
- Testing only an administrator session instead of the roles, devices, consent states, networks, and failure paths users actually have.
Questions teams ask during testing
Can this be tested on production?
Use production for read-only confirmation and one narrow synthetic fixture. Perform destructive changes, upgrades, queue repairs, cache-policy changes, and schema changes on staging first. Promote only the smallest change that has a measured rollback point.
What evidence should be kept?
Keep component versions, stable fixture IDs, UTC timestamps, request or export evidence, expected and actual outcomes, the decision owner, rollback point, and final clean verification. Remove or redact personal data before sharing.
When is the work finished?
Finish when the canonical user path passes, downstream records reconcile, failure cases are understood, monitoring is active, and an established page links to the new guide with useful context.
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.
Validate media REST dimensions and cleanup
Extend the Media Library evidence with the WordPress 7.1 media REST dimension validation test for integer contracts, retries, derivatives, offload objects, temporary files, and orphan prevention.
Helpful references