How WordPress 5.8 added infinite scroll to the media library

WordPress 5.8 changed infinite scrolling in the Media Library in a way that is easy to remember incorrectly.

WordPress did not introduce infinite scrolling to the Media Library in version 5.8. Infinite scrolling already existed.

What WordPress 5.8 actually did was remove infinite scrolling as the default behavior in the Media Library grid and replace it with a user-controlled Load more button.

At the same time, WordPress introduced the media_library_infinite_scrolling filter so developers could restore the previous infinite-scroll behavior when they deliberately wanted it.

That remained the default model for several years.

Then WordPress 7.1 changed direction again. Infinite scrolling became enabled by default in the Media Library grid, while individual users gained an option to turn it off and return to the Load more behavior.

This history matters because modern WordPress media browsing is the result of an ongoing tradeoff between convenience, accessibility, performance and control over large Media Libraries.

This guide explains what changed in WordPress 5.8, why infinite scrolling was removed from the default experience, how the media_library_infinite_scrolling filter works, what WordPress 7.1 changed again and how TheOneWP Media Infinite Scroll fits into that evolution.

First: what is infinite scrolling?

Infinite scrolling is a browsing pattern in which additional content loads automatically as the user approaches the end of the currently displayed results.

Conceptually:

Initial attachments
        ↓
User scrolls
        ↓
Near bottom of results
        ↓
Request next batch
        ↓
Append attachments
        ↓
Continue scrolling

The user does not need to explicitly navigate to:

Page 2
Page 3
Page 4

or repeatedly click a button to continue browsing.

Why infinite scroll feels natural in a Media Library

Media browsing is highly visual.

An editor searching for an old photograph often does not know:

• the exact filename;
• the upload month;
• the attachment title;
• which numbered page contains it.

They may simply recognize the image when they see it.

A continuous visual grid therefore feels natural:

scroll
↓
scan
↓
scroll
↓
scan
↓
find image

instead of:

scan
↓
click next
↓
wait
↓
scan
↓
click next
↓
wait

WordPress had infinite scrolling before version 5.8

This is the historical detail that frequently gets reversed.

Before WordPress 5.8, the Media Library grid already used infinite scrolling.

Users could continue moving through attachments and WordPress would load more media automatically.

WordPress 5.8 removed infinite scroll from the default Media Library

WordPress 5.8 changed that behavior.

The official WordPress 5.8 Field Guide describes the Media Library change as replacing infinite scrolling with an AJAX-based loading interface.

Core development discussions were even more explicit: infinite scrolling was removed from the Media Library and replaced with a:

Load more

button.

The WordPress Core development chat summary from May 2021 documents the decision around ticket #50105.

The WordPress 5.8 flow became user-controlled

Instead of:

Scroll
↓
automatic request
↓
more attachments

the normal grid flow became:

Browse current attachments
↓
Reach end
↓
Load more
↓
Request more attachments
↓
Continue browsing

Why did WordPress remove infinite scrolling?

The change was motivated primarily by concerns around:

• accessibility;
• keyboard navigation;
• screen-reader behavior;
• user control;
• performance;
• usability.

Infinite scrolling looks simple visually, but interfaces that continuously inject new content can create difficult interaction problems.

Infinite scrolling can make keyboard navigation difficult

A keyboard user may move through a page using:

Tab
Shift + Tab
Arrow keys
other navigation commands

If new elements continuously appear near the end of the interface, maintaining a predictable position can become harder.

Focus management becomes important

When a user deliberately activates:

Load more

the interface knows:

The user requested additional results.

It can then provide appropriate focus behavior and information about the newly loaded content.

With automatic loading, the request can happen simply because the viewport happened to reach a threshold.

Screen readers need understandable state changes

When new attachments are inserted dynamically, users of assistive technology need a usable way to understand:

• that more items appeared;
• where those items appeared;
• whether their current position changed;
• how many results remain;
• how to continue navigating.

An interface that merely appends DOM elements is not automatically accessible because the mouse user finds it convenient.

The footer problem also matters

Infinite scrolling can make content below a continuously growing list difficult to reach.

This is a classic infinite-scroll problem:

User approaches footer
↓
More content loads
↓
Footer moves down
↓
User approaches footer again
↓
More content loads

For the WordPress Media Library specifically, the problem is contained inside an administration browsing interface, but the same usability principle remains relevant.

Large libraries can also increase browser workload

Suppose a site contains:

50,000 attachments

Infinite scrolling should not mean:

Render all 50,000 attachments immediately.

A sensible implementation progressively requests batches.

Progressive loading is different from loading everything

A good pattern looks like:

Initial batch:
40 attachments

Scroll

Next batch:
40 attachments

Scroll

Next batch:
40 attachments

The server and browser process manageable groups instead of attempting to transfer the complete library at once.

But the DOM still grows during a long session

Even progressive loading can eventually produce:

40 items
80 items
120 items
400 items
800 items
...

in the current document.

Large numbers of rendered thumbnails can increase:

• memory use;
• layout work;
• image decoding;
• DOM complexity;
• browser rendering cost.

Pagination creates a natural boundary

Traditional pagination limits the current interface to a known group:

Page 1:
40 items

Page 2:
40 items

Page 3:
40 items

The browser does not need to retain every previously displayed attachment in the same rendered view.

The Load more model sits between pagination and infinite scroll

The WordPress 5.8 approach kept progressive loading while requiring explicit user action.

It was therefore closer to:

Initial results
↓
User decides whether to continue
↓
Load more
↓
Append next results

rather than traditional page navigation.

WordPress 5.8 did not completely delete infinite-scroll support

This is the second important part of the story.

Although automatic infinite scrolling stopped being the default, WordPress retained a mechanism for enabling it.

The relevant filter is:

media_library_infinite_scrolling

The filter let developers restore infinite scrolling

After WordPress 5.8, a plugin or theme could enable the old behavior conceptually with:

add_filter(
    'media_library_infinite_scrolling',
    '__return_true'
);

This meant:

WordPress default:
Load more

Site customization:
Infinite scroll

The filter created an explicit opt-in architecture

This was a meaningful design decision.

Core no longer assumed:

Infinite scrolling is right for everyone.

Instead:

Default to explicit loading
+
allow developers to enable continuous loading

The filter applied to the Media Library grid mechanism

The grid view is the JavaScript-heavy visual Media Library interface.

If you are comparing the different WordPress media browsing experiences, see WordPress Media Library: grid view vs. list view.

Grid view and List view are not the same implementation

The two Media Library views look like alternate presentations of the same content, but their technical behavior differs.

Grid view behaves like an application-style media browser.

List view behaves more like a traditional WordPress administration table.

Grid view is optimized for visual browsing

A typical grid contains:

[ image ] [ image ] [ PDF ]
[ image ] [ video ] [ image ]
[ image ] [ image ] [ image ]

It is well suited to:

• photographs;
• graphics;
• visual selection;
• rapid scanning.

List view emphasizes attachment data

List view can expose structured information such as:

• filename;
• author;
• upload context;
• date;
• attachment details;
• bulk actions.

This often makes it useful for administrative cleanup and systematic media management.

The 5.8 infinite-scroll filter did not magically turn every WordPress list into infinite scroll

The core:

media_library_infinite_scrolling

mechanism concerns the Media Library’s grid-style loading behavior.

Custom interfaces require their own implementations.

This matters when building plugins

A plugin should not assume:

WordPress has an infinite-scroll filter
therefore my custom attachment table
automatically supports it.

It does not.

TheOneWP Media Infinite Scroll extends the concept

TheOneWP Media Infinite Scroll provides continuous media loading for WordPress Media Library workflows.

The module can apply the experience to:

• Grid view;
• List view.

The two modes use different mechanisms because WordPress itself does not implement those interfaces identically.

The Grid view can build on the native WordPress mechanism

For Grid view, TheOneWP can use WordPress’s existing infinite-scrolling support rather than inventing another incompatible media endpoint.

This is important because the native Media Library already knows how to:

• query attachments;
• apply media filters;
• respect authentication;
• render attachment models;
• load additional batches.

The List view requires a different approach

The standard List view is a paginated administration table.

To create continuous loading there, additional pages can be requested and their attachment rows appended to the current table.

Conceptually:

Current list page
        ↓
Approach bottom
        ↓
Request next Media Library page
        ↓
Extract attachment rows
        ↓
Append rows
        ↓
Continue browsing

This does not require creating a new media database

A sensible implementation can continue using WordPress’s existing Media Library pages and queries.

The enhancement changes the browsing interaction rather than creating a parallel attachment-management system.

Existing authentication still applies

A request for additional admin-side attachment results occurs in the same authenticated WordPress context.

Infinite scrolling changes:

how more results appear

not:

who is allowed to access the Media Library

Infinite scroll is not an access-control feature

This distinction matters particularly when a site also uses role-based media visibility.

TheOneWP Media Visibility controls which attachments selected roles can discover in supported Media Library interfaces.

Infinite scroll merely changes how additional allowed results are loaded.

Visibility filters should continue applying to later batches

Suppose an Author may see only:

120 attachments

from a library containing:

20,000 attachments

The first infinite-scroll batch should respect that restriction.

So should:

batch 2
batch 3
batch 4
...

Pagination behavior must not become a back door around the underlying query restrictions.

Search should continue applying when additional items load

Suppose the user searches:

product

The first results might include:

product-front.jpg
product-side.jpg
product-guide.pdf

If more results load automatically, they should continue belonging to the same search query.

Infinite scrolling must preserve query state

The current browsing state may include:

• search text;
• media type;
• date;
• category;
• author;
• role-based visibility;
• other plugin filters.

A loader that simply requests:

next 40 attachments globally

would produce incorrect results.

Media categories become increasingly useful on large libraries

Continuous scrolling helps browse more results.

It does not solve the problem of having too many irrelevant results.

TheOneWP Media Categories provides an organizational layer for grouping attachments.

A better large-library workflow can therefore combine:

Categories
+
Search
+
Filters
+
Progressive loading

Infinite scroll should complement search, not replace it

Scrolling through:

18,000 images

is not a sophisticated information-retrieval strategy merely because the browser loads them smoothly.

If you know what you are looking for, search and filtering should narrow the candidate set first.

Organization still matters

For broader strategies, see both:

Organizing a large WordPress media library and Keeping a WordPress media library organized at scale.

Continuous loading improves navigation through the results you have. It does not magically repair ten years of filenames called IMG_8427.jpg.

Why did some users prefer the old infinite scroll?

The Load more model introduced in WordPress 5.8 gave users explicit control, but it also interrupted fast visual browsing.

Imagine reviewing hundreds of uploads.

The workflow becomes:

Scroll
↓
Load more
↓
Scroll
↓
Load more
↓
Scroll
↓
Load more

Each manual action is small.

Repeated hundreds of times, it becomes friction.

This tradeoff became more visible as Media Libraries grew

WordPress sites increasingly contain:

• large editorial archives;
• ecommerce photography;
• marketing assets;
• client libraries;
• downloadable documents;
• years of historical uploads.

A design that feels perfectly acceptable with 80 attachments can feel quite different with 80,000.

The WordPress 5.8 behavior lasted for years

From WordPress 5.8 onward, infinite scrolling was effectively off by default unless a plugin or theme explicitly enabled it through the filter.

This is confirmed by the current WordPress Core documentation around the later 7.1 change.

Then WordPress 7.1 reversed the default again

In WordPress 7.1, infinite scrolling became enabled by default in the Media Library grid.

The official WordPress 7.1 Media Library developer note explains the change.

The history now looks like this

Before WordPress 5.8
→ Infinite scrolling used by default

WordPress 5.8
→ Infinite scrolling disabled by default
→ Load more becomes default
→ media_library_infinite_scrolling
  can opt back in

WordPress 5.8 through 7.0
→ Load more remains default

WordPress 7.1
→ Infinite scrolling enabled by default again
→ Users can individually opt out

That timeline is the important takeaway

WordPress 5.8 did not invent infinite scrolling.

It created the explicit switch that allowed infinite scrolling to become an optional behavior after Core stopped enabling it by default.

WordPress 7.1 later used the same underlying concept while changing the default back to automatic loading.

The filter remained important in WordPress 7.1

The:

media_library_infinite_scrolling

filter still exists.

What changed in WordPress 7.1 was its default behavior.

Before WordPress 7.1

Conceptually:

default:
false

meaning infinite scrolling was disabled unless explicitly enabled.

From WordPress 7.1

The default becomes conceptually:

default:
true

so infinite scrolling is enabled unless configuration or the relevant user preference disables it.

Developers can still force it off

For example:

add_filter(
    'media_library_infinite_scrolling',
    '__return_false'
);

can force the Load more behavior instead.

Developers can also force it on

Conceptually:

add_filter(
    'media_library_infinite_scrolling',
    '__return_true'
);

ensures infinite scrolling remains active through the filter.

WordPress 7.1 also added a per-user preference

A major difference from the older implementation is that users can opt out individually.

WordPress exposes a profile preference for users who can access the Media Library.

This acknowledges that the preferred browsing model can genuinely vary between people.

One administrator may prefer continuous browsing

For example:

Designer
→ infinite scrolling

Reason:
rapid visual scanning

Another administrator may prefer explicit loading

Keyboard-heavy editor
→ Load more

Reason:
more predictable navigation

Neither preference is inherently absurd. A rare outbreak of nuance in software settings.

WordPress 7.1 has a precedence model

The Core developer note describes the effective preference in this order:

1. media_library_infinite_scrolling filter
2. user preference
3. WordPress default

The filter has the highest priority

If a plugin explicitly forces:

false

through the filter, a user preference cannot override that decision.

Likewise, a forced:

true

can override an individual opt-out.

This matters for plugins like Media Infinite Scroll

Any plugin implementing its own browsing preference needs to understand the current WordPress version and the precedence of Core behavior.

A plugin developed during the WordPress 5.8–7.0 period might have assumed:

Core default = false

That assumption is no longer universally valid from WordPress 7.1 onward.

Do not blindly add __return_true on modern WordPress

On WordPress 7.1, Core already defaults the grid to infinite scrolling.

A plugin that always forces:

__return_true

may unintentionally prevent a user’s Core opt-out from working.

Compatibility logic should respect intent

There is a difference between:

Enable infinite scroll because
Core does not provide it by default

and:

Force infinite scroll even when
the user explicitly disabled it

Modern implementations should distinguish those cases.

The List view remains a separate question

WordPress 7.1’s Core default change concerns the Media Library grid and Media Modal behavior.

It does not turn the traditional List view into a native infinite-scrolling table.

This means TheOneWP Media Infinite Scroll can still provide additional value when continuous loading is wanted in List view.

Why might you want infinite scroll in List view?

List view can be useful when auditing:

• filenames;
• dates;
• attachment ownership;
• media categories;
• administrative metadata.

Continuous loading allows users to inspect successive rows without navigating manually between pages.

But List view performance should remain bounded

If each row contains:

• thumbnail;
• metadata;
• actions;
• taxonomy information;
• plugin columns;

appending thousands of rows into one table eventually becomes expensive.

Infinite scrolling should load in batches

A reasonable system loads:

Page 1
↓
Page 2
↓
Page 3

incrementally rather than issuing requests for the entire library.

IntersectionObserver is useful for automatic loading

Modern browser JavaScript provides the Intersection Observer API.

It allows code to detect when a sentinel element approaches or enters the viewport.

Conceptually:

Attachment rows
Attachment rows
Attachment rows

[ loading sentinel ]
        ↑
IntersectionObserver watches this

When the sentinel becomes visible, request the next batch

Instead of continuously running expensive calculations on every scroll event, the browser can notify the application when the observed element crosses the configured threshold.

This is usually cleaner than raw scroll listeners

A naive implementation might run:

window.addEventListener(
    'scroll',
    checkPosition
);

which can fire extremely frequently while the user scrolls.

IntersectionObserver gives the browser more freedom to optimize visibility detection.

A loading lock is still necessary

Suppose the user reaches the threshold and the next page request begins.

Before it finishes, the observer could trigger again.

Without protection:

Request page 2
Request page 2
Request page 2

can occur.

Use explicit loading state

Conceptually:

if ( loading ) {
    return;
}

loading = true;

loadNextPage();

loading = false;

The implementation details vary, but duplicate concurrent loads should be prevented.

Stop observing when there are no more results

Once:

current results = total results

the loader should stop requesting additional pages.

Otherwise the browser can continue generating useless requests for content that does not exist.

Automatic loading needs visible progress

Users should be able to understand when additional attachments are being fetched.

A loading state might display:

Loading more attachments...

with a progress indicator.

Loading failures should fail gracefully

A network request may fail because of:

• expired authentication;
• network interruption;
• server error;
• plugin conflict;
• invalid response.

An infinite-scroll implementation should not simply leave an eternal spinner contemplating its existence.

Search and filters should reset pagination state

Suppose the user has loaded:

pages 1–6

and then changes the filter from:

All media

to:

Images

The infinite-scroll state must now reflect the filtered query.

Do not continue from page 7 of the previous query

A filter change should conceptually reset:

current query
current page
total count
loading state

to match the new result set.

The same applies to Media Categories

If the user changes:

All Categories

to:

Client A

additional infinite-scroll requests must remain within:

Client A

Large Media Libraries need more than infinite scrolling

Infinite scrolling helps when:

You know the asset visually
but need to browse for it.

It is less useful when:

You have 100,000 attachments
and no organizational system.

Use multiple retrieval tools together

A scalable Media Library benefits from:

• search;
• dates;
• media types;
• categories;
• role visibility;
• sensible filenames;
• progressive browsing.

Infinite scroll changes UX, not attachment data

Activating continuous loading should not modify:

• attachment IDs;
• file URLs;
• attachment metadata;
• image sizes;
• alt text;
• media taxonomy relationships.

It changes how existing attachment results are presented and loaded.

It does not regenerate images

Infinite scrolling has nothing to do with image sub-size creation.

If that is the issue you are solving, see What happens when WordPress regenerates thumbnails.

It does not replace media files

Continuous browsing does not change attachment files either.

For that workflow, see Replacing vs. re-uploading WordPress media.

It does not control direct file access

Loading an attachment in the Media Library and allowing a visitor to retrieve its direct file URL are separate concerns.

See Hiding vs. restricting access to WordPress media for that distinction.

It does not make every third-party media picker continuous

Page builders and plugins may implement their own media interfaces.

A feature targeting WordPress’s Media Library does not automatically modify:

• custom React media pickers;
• plugin-specific asset managers;
• external DAM interfaces;
• custom frontend upload systems.

Test the interface your editors actually use

Do not assume:

Infinite scroll works in Media → Library
therefore it works everywhere.

Test:

• Media Library Grid view;
• Media Library List view;
• Add Media modal;
• featured-image picker;
• plugin-specific media interfaces where relevant.

Accessibility still matters in WordPress 7.1

Re-enabling infinite scrolling by default did not make the accessibility concerns that motivated WordPress 5.8 disappear.

WordPress 7.1 therefore includes an individual opt-out.

The official WordPress 7.1 accessibility developer note explicitly discusses infinite scrolling as an accessibility concern and explains the available alternatives.

Automatic loading should be treated as a preference, not a moral achievement

Some users find it faster.

Some find explicit loading more predictable.

The best administrative UX recognizes that both workflows can be valid.

Infinite scroll vs. Load more

INFINITE SCROLL

Trigger:
Viewport position

Advantages:
Fast visual browsing
Less repetitive clicking
Smooth exploration

Tradeoffs:
Less explicit control
Accessibility complexity
Growing DOM
Harder position management


LOAD MORE

Trigger:
Explicit user action

Advantages:
Predictable
User-controlled
Clear loading boundary
Often easier for accessibility

Tradeoffs:
Repeated interaction
Interrupts visual browsing
Slower for very large libraries

Infinite scroll vs. traditional pagination

TRADITIONAL PAGINATION

Page 1
Page 2
Page 3

Advantages:
Stable URLs/state
Fixed result boundaries
Smaller rendered result sets

Tradeoffs:
Navigation interruption


INFINITE SCROLL

One continuous session

Advantages:
Faster browsing flow

Tradeoffs:
Growing interface state
Harder navigation restoration

Position restoration can be harder with infinite scrolling

Suppose a user scrolls through:

500 attachments

opens one item, navigates elsewhere and later returns.

Restoring exactly where they were can require more state than simply returning to:

page=12

in a paginated interface.

This matters for administrative workflows

If users frequently:

browse
→ edit attachment
→ return
→ continue browsing

the application should preserve their position as reliably as possible.

Infinite scroll can make URL-based navigation less expressive

Traditional pagination can expose:

upload.php?paged=8

which directly represents a location in the result set.

An infinite-scrolling interface may instead maintain that state only inside JavaScript and the DOM.

Neither model is universally superior

For visual asset discovery:

infinite scroll

can feel excellent.

For systematic administration where users need repeatable locations:

pagination or explicit loading

may be preferable.

A practical decision tree

How do users browse the Media Library?
│
├── Mostly visual exploration
│   └── Infinite scroll may help
│
├── Precise administrative review
│   └── List/pagination may be clearer
│
├── Accessibility requires
│   predictable explicit navigation
│   └── Prefer Load more / pagination
│
└── Different users want
    different behavior
    └── Respect per-user choice

When infinite scroll is especially useful

It can work well for:

• photography-heavy sites;
• design teams;
• large editorial archives;
• agencies with many media assets;
• product-image libraries;
• users who recognize assets visually.

When explicit loading may be better

Consider retaining Load more or pagination when:

• keyboard navigation is central;
• users prefer predictable boundaries;
• the browser struggles with large DOMs;
• the library contains extremely large result sets;
• users need stable page positions;
• accessibility testing reveals problems.

Performance depends on more than the number of attachments

A Media Library request may be affected by:

• attachment metadata;
• custom columns;
• taxonomy filters;
• role restrictions;
• storage configuration;
• thumbnail loading;
• plugin query filters.

A library containing 5,000 simple images can behave better than another containing fewer attachments but several expensive custom query modifications.

Infinite scrolling does not fix slow database queries

If every next-page request takes:

5 seconds

automatically triggering that slow request does not make it faster.

It merely saves the user from clicking before waiting five seconds.

Optimize the underlying media query separately

When browsing is slow, inspect:

• database query time;
• attachment counts;
• metadata joins;
• taxonomy filters;
• plugin hooks;
• thumbnail delivery;
• server response time.

Thumbnail size also affects perceived speed

A Media Library may request many preview images.

If inappropriate full-resolution files are being loaded for thumbnails, the network cost can become much larger than necessary.

TheOneWP Image Sizes List can help inspect the image-size landscape on a WordPress installation.

Media optimization can help network delivery

TheOneWP Image Optimizer addresses image file efficiency, which is distinct from how the Media Library paginates those attachments.

Again:

Infinite scroll
→ navigation behavior

Image optimization
→ file delivery efficiency

Common misunderstandings about WordPress 5.8 and infinite scrolling

“WordPress 5.8 introduced infinite scroll”

Incorrect.

Infinite scrolling existed before WordPress 5.8.

Version 5.8 disabled it by default and introduced Load more.

“WordPress 5.8 permanently removed infinite scrolling”

Also incorrect.

The media_library_infinite_scrolling filter allowed it to be enabled again.

“The filter means infinite scrolling was enabled by default”

No.

Between WordPress 5.8 and WordPress 7.0, the filter default was effectively false.

“WordPress 7.1 invented Media Library infinite scrolling”

No.

WordPress 7.1 changed the default back to enabled and added a per-user opt-out.

“Infinite scroll affects both Grid and List view identically”

No.

The native Core mechanism relates primarily to the grid/media-modal experience. List view has a different architecture.

“Infinite scrolling loads the entire library immediately”

A proper implementation loads results progressively in batches.

“Infinite scroll makes a large Media Library organized”

It makes browsing continuous. Organization still requires search, naming, filtering and categories.

“Infinite scroll changes attachment data”

It should not. It is a presentation and retrieval behavior.

“Everyone should prefer infinite scrolling”

WordPress’s own history demonstrates why that assumption is too simplistic.

A WordPress Media Library infinite-scroll checklist

• Understand whether the site is running WordPress 5.8–7.0 or WordPress 7.1+.
• Know the current default behavior for that WordPress version.
• Check whether media_library_infinite_scrolling is filtered.
• On WordPress 7.1+, consider the individual user’s preference.
• Do not force infinite scrolling unnecessarily when Core already provides it.
• Test Grid view separately from List view.
• Test the Media Modal separately.
• Preserve search state between loads.
• Preserve date filters between loads.
• Preserve category filters between loads.
• Preserve role-based media restrictions.
• Prevent duplicate concurrent requests.
• Stop loading when no results remain.
• Show a clear loading state.
• Handle failed requests gracefully.
• Test keyboard navigation.
• Test with assistive technology where appropriate.
• Watch browser memory on very large result sets.
• Do not mistake continuous browsing for Media Library organization.
• Test custom third-party media interfaces separately.

Related WordPress Media Library guides

For the broader Media Library browsing, organization and media-management cluster, continue with:

• WordPress Media Library: grid view vs. list view
• Organizing a large WordPress media library
• Keeping a WordPress media library organized at scale
• Hiding vs. restricting access to WordPress media
• Replacing vs. re-uploading WordPress media
• What happens when WordPress regenerates thumbnails
• WordPress image cache-busting, explained
• Media Infinite Scroll
• Media Categories
• Media Visibility
• Media Replace
• Image Sizes List
• Image Optimizer

Final thoughts

The history of infinite scrolling in the WordPress Media Library is almost the opposite of what the original guide title suggests.

Infinite scrolling existed before WordPress 5.8.

WordPress 5.8 removed it from the default Media Library experience and replaced it with an explicit Load more interaction because Core contributors were concerned about accessibility, usability and performance. At the same time, the media_library_infinite_scrolling filter preserved a way for plugins and themes to opt back into automatic loading.

That architecture remained in place for years.

Then WordPress 7.1 changed the default again. Infinite scrolling returned as the standard Grid view behavior, while individual users gained the ability to disable it when they prefer the more explicit loading model.

TheOneWP Media Infinite Scroll fits into this history by providing configurable continuous browsing and extending the idea beyond the native grid mechanism to workflows such as List view, where WordPress uses a different pagination model.

The useful lesson is not that infinite scrolling is inherently better or worse.

It is that media browsing involves competing requirements:

Speed
Accessibility
User control
Performance
Discoverability
Navigation continuity

WordPress has changed its default more than once because there is no single interaction that is perfect for every administrator and every Media Library.

Which is also why documenting the history accurately helps. WordPress already changes enough on its own without us assigning features to the release that removed them.