Media Library Infinite Scrolling Is On by Default in 7.1

Five years ago the accessibility team pulled a feature out of the Media Library because keyboard users could not reach the images that scrolled in, screen readers had no way to announce them, and the browser history broke silently on any page that opened one. That was WordPress 5.8, July 2021. The fix was to flip a filter default from true to false and leave the door open so anyone who wanted infinite scrolling back could add one line to a plugin. Almost nobody did.

WordPress 7.1 flips it the other way. Infinite scrolling in the Media Library grid returns as the default. What is different this time is the shape of the change — it is not a rollback of the 5.8 decision, it is a governance layer wrapped around it. The filter still wins. A new per-user preference sits under the filter. Existing sites that opted in stay opted in. New sites just get infinite scrolling and nobody has to think about it.

That is a small design change with a very WordPress shape — five-year loop, three levels of override, no theme breaks, no plugin breaks, and a checkbox on the profile screen for the editor who wants pagination back. Worth ten minutes of your Monday.

What is actually new

The dev note “Media Library infinite scrolling is now enabled by default, with a per-user opt-out” was published on Make/Core by Marin Atanasov on July 23, 2026, tracking ticket #65564. The change lands in WordPress 7.1, currently in beta, GA scheduled for August 19, 2026 per the release party schedule.

The mechanic is precise. The media_library_infinite_scrolling filter, introduced in WordPress 5.8 to disable infinite scrolling by default while leaving it toggleable, keeps the same name and the same signature. Only the default return value flips from false to true. Nothing else in the filter contract changes.

Layered under the filter is a new per-user preference. Any user with the upload_files capability sees a checkbox on their profile screen labelled “Disable infinite scrolling in the Media Library grid view” (unchecked by default). The preference stores as a string in the user meta key infinite_scrolling, values 'true' or 'false'. The resolution order runs highest to lowest: the media_library_infinite_scrolling filter callback first, the user’s opt-out preference second, the new default of true third. A site that explicitly returns false from the filter still gets pagination — the site owner’s call outranks the user’s, which outranks the core default.

Backwards compatibility is the whole story. Sites that never touched the filter now default to infinite scrolling. Sites that already added add_filter( 'media_library_infinite_scrolling', '__return_true' ); to opt in see no change. Sites that added __return_false also see no change. No user meta migration runs. Contributors named on the changeset include youknowriad, khokansardar, wildworks, davidbaumwald, joedolson, and sabernhardt — the accessibility-team names in that list are a signal in themselves.

Worth pausing on why the 5.8 decision existed at all. Tickets #50105 and #40330 collected the case: infinite scrolling made it functionally impossible for keyboard-only users to reach items appended after the initial page load, screen readers had no announcement pattern for the new content, the browser back button did not restore scroll position or query state, and loading hundreds of full-size thumbnails on a large-catalogue store spiked memory. Five years later the JavaScript surface has been rewritten enough that the current implementation addresses the mechanical parts of that list, but the accessibility trade is still real — hence the checkbox, not a silent flip.

Why it matters for WordPress and WooCommerce people

For an editorial team uploading a dozen images a day, this is invisible. Infinite scrolling was the assumption most editors already had when clicking through a large library. Five years of pagination felt like a bug most people worked around by narrowing filters or using the “load more” button until they reached what they wanted. Post-7.1 the grid just keeps going.

For a WooCommerce store with a five-figure image library — product photos, variation swatches, lifestyle shots, tax-invoice PDFs sitting in Media — the story is more mixed. Infinite scrolling on a catalogue that large means the browser can accumulate a serious memory footprint as it walks toward older uploads, especially on shop-manager laptops that were never chosen for their RAM. The per-user opt-out is the release valve. A store owner who works exclusively from the desktop grid probably wants it. A shop manager on a four-year-old MacBook who lives in the grid all day may not. Both are one profile-page checkbox away from their preferred behaviour, and that is the point.

For agencies managing many client sites, the risk surface is small and specific. Any plugin that assumed pagination — a custom Media Library filter panel, a bulk-operations UI that expects a fixed page size, an ancient DAM integration that scraped the paginated grid — needs a look. The filter is still respected, so a one-line fix is available where needed, but discovering the incompatibility three weeks after 7.1 GA because a client’s asset-approval workflow silently changed shape is not the ideal path.

The broader signal is the governance layer. This is the same pattern WordPress ships almost every release: change a default, keep the filter intact, add a per-user preference underneath, respect prior opt-ins. Nothing breaks. Nothing needs a migration script. The behaviour is different tomorrow and the code path is the same. That is not glamorous but it is why 20-year-old sites still upgrade cleanly.

What I would do (or not do) about it

Three things worth doing this week on staging with Gutenberg trunk or a WordPress 7.1 beta build. First, grep every managed site’s plugins and themes for the string media_library_infinite_scrolling. Anything you find is either an explicit opt-in that pre-dates 7.1 (safe to delete after August 19 if you want to fall through to the new default) or an explicit opt-out for a real reason (leave it). Anything that assumed pagination without touching the filter is invisible until you look.

Second, take one client site with a real Media Library — three thousand items or more — and open the grid in 7.1 beta. Scroll to the bottom. Watch memory usage in the browser task manager. Confirm the load pattern is what you want a shop manager to experience on a normal laptop. If the answer is no, decide whether the intervention is site-wide (filter returning false in a mu-plugin) or per-user (documented profile-page checkbox for that role). Do not decide by reflex — the answer is different for a photography portfolio and a warehouse catalogue.

Third, if you have any admin-side plugin that manipulates the grid — filter dropdowns, custom columns, bulk actions, a “select all on page” UI — regression test on 7.1 beta with the new default active. Bulk actions that assumed a page boundary need to be re-scoped or the UI needs to explain what “select all” means when the grid never ends.

Two things not to do. Do not build client comms warning about the Media Library “changing” — the change is invisible to almost every editor and the exceptions are the ones where you already know the workflow depends on pagination. Do not install a plugin that adds a UI toggle for the site-wide setting; the filter is one line and belongs in the site’s own mu-plugin folder, not in the plugin update queue for the next five years. And do not stack this on the WooCommerce 11.0 upgrade window today — WooCommerce 11.0 is a separate change window, WordPress 7.1 lands August 19, three weeks apart, run them sequentially.

Every release cycle has one of these — a small default flip wrapped in a filter, a user preference, and a preserved override chain. Nothing to write home about, and exactly the reason a WordPress site you built in 2015 still upgrades to 7.1 with no drama.