WordPress 7.1 makes infinite scrolling the default in the Media Library grid, with an option to disable it in the user profile. Large libraries, attachment filters, media offload plugins, custom columns, and accessibility workflows can expose problems that do not appear in a small demo library.
Use this for publishers, stores, universities, agencies, and media-heavy sites with tens of thousands of attachments or remote media storage.
Quick answer
WordPress 7.1 Media Library Infinite Scroll Memory and Query Test should be handled with a narrow evidence-first workflow: capture the library baseline, measure fixed depths, reset every filter, then verify the result before making broader changes.
What to check first
- Record attachment count, file types, offload state, search plugins, browser version, user preference, REST settings, and server limits.
- Scroll through fixed depths such as 100, 500, 1,000, and 2,000 items while capturing requests, returned IDs, browser memory, main-thread time, and visible item count.
- Change media type, date, author, search phrase, and list or grid view after a deep scroll and confirm pagination resets correctly.
- Use keyboard-only navigation and a screen reader to test focus order, newly loaded announcements, selected-item state, and return position after editing an attachment.
- Repeat with offload, image optimization, and media-folder plugins enabled one at a time to identify duplicate queries or missing rows.
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 |
|---|
| Capture the library baseline | Record attachment count, file types, offload state, search plugins, browser version, user preference, REST settings, and server limits. | Every loaded attachment ID is unique and belongs to the active filter. |
| Measure fixed depths | Scroll through fixed depths such as 100, 500, 1,000, and 2,000 items while capturing requests, returned IDs, browser memory, main-thread time, and visible item count. | Search and filter changes restart at the correct first page. |
| Reset every filter | Change media type, date, author, search phrase, and list or grid view after a deep scroll and confirm pagination resets correctly. | Browser memory and request time remain usable at the agreed scroll depth. |
| Test keyboard behavior | Use keyboard-only navigation and a screen reader to test focus order, newly loaded announcements, selected-item state, and return position after editing an attachment. | Keyboard and screen-reader users can find, select, edit, and return to attachments predictably. |
Why this usually happens
- Each loaded attachment can remain in browser memory after it leaves the viewport.
- A filter change can reuse a stale page cursor or append results from the previous query.
- Media plugins may modify REST responses, attachment queries, or client-side collections.
- Automatic loading can move focus or remove a clear stopping point for keyboard and assistive-technology users.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
scroll_sample:
loaded_items: 1000
request_count: 10
unique_attachment_ids: 1000
browser_memory_mb: 312
filter: all_media
keyboard_focus: attachment_1000
duplicate_ids: 0
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.
- Capture the library baseline
- Measure fixed depths
- Reset every filter
- Test keyboard behavior
- Isolate media plugins
Decision rule
Keep infinite scroll enabled only when memory growth, request latency, duplicate IDs, and accessibility behavior stay inside the site's agreed limits. The per-user disable option is a fallback, not a reason to ignore a repeatable regression.
What to tell the client or owner
Share the attachment count, plugin state, filter, scroll depth, request count, returned and unique IDs, memory samples, keyboard result, slow query evidence, and browser version.
Production verification checklist
- Every loaded attachment ID is unique and belongs to the active filter.
- Search and filter changes restart at the correct first page.
- Browser memory and request time remain usable at the agreed scroll depth.
- Keyboard and screen-reader users can find, select, edit, and return to attachments predictably.
Mistakes to avoid
- Do not test with a clean library of only a few hundred images.
- Do not judge browser memory from Task Manager alone without fixed scroll depths.
- Do not skip filter changes after deep scrolling.
- Do not assume the user-profile disable option fixes a server or plugin query problem.
Questions teams ask during testing
How many attachments should the test load?
Use the depth real staff reach and add a stress case. A publisher may need 2,000 loaded items, while another team can validate at 500 if search is the primary workflow.
Should list view be tested too?
Yes. The user may switch views after a deep grid session, and plugins can change both query paths. Confirm selected state and filters survive only where intended.
When HandL WP should help
HandL WP should help when the Media Library freezes, repeats items, loses filters, or becomes inaccessible after the WordPress 7.1 update. We can separate browser collection behavior from REST, database, and media-plugin costs.
If this is active on a production site, diagnose a slow WordPress Media Library.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references