Media Library infinite scrolling is now enabled by default, with a per-user opt-out

Background

The grid view of the Media Library (including the Media Modal) has supported infinite scrolling for a long time, where attachments load automatically as you scroll instead of behind a Load more button. That behavior was controlled by the media_library_infinite_scrolling filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output., which defaulted to false since WordPress 5.8 due to accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility), performance, and usability concerns (#50105 / r50829 / #40330). As a result, infinite scrolling was effectively off for everyone unless a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party. or theme opted in via the filter.

The Load more button has long been a friction point for users managing large media libraries, and the smoother infinite-scroll experience was hidden behind code that most sites never enabled.

What changed

In WordPress 7.1 (#65564):

  1. Infinite scrolling is now enabled by default. The media_library_infinite_scrolling filter now defaults to true, so the grid view auto-loads attachments on scroll out of the box. This applies to both the Grid view of the Media Library, and the Media Modal.
  2. Users can opt out individually. A new Infinite Scrolling personal option appears on the profile screen (Users > Profile), with a checkbox labeled “Disable infinite scrolling in the Media Library grid view” (unchecked by default). The option is only shown to users who have the upload_files capabilitycapability A capability is permission to perform one or more types of task. Checking if a user has a capability is performed by the current_user_can function. Each user of a WordPress site might have some permissions but not others, depending on their role. For example, users who have the Author role usually have permission to edit their own posts (the “edit_posts” capability), but not permission to edit other users’ posts (the “edit_others_posts” capability)., since the attachment grid is unreachable without it.

Precedence

The effective setting is resolved in this order, from highest priority to lowest:

  1. The media_library_infinite_scrolling filter: a hooked filter callback always wins.
  2. The user’s opt-out preference: applies when no filter is hooked.
  3. The default (true): applies when neither of the above is set.

In other words: filter > user preference > default.

Developer-facing details

The filter’s default changed

If your plugin or theme relies on the previous behavior (infinite scrolling off unless explicitly enabled), be aware that the default is now true. To force the previous behavior for all users regardless of their preference, you can use the filter, as it takes precedence over everything:

// Force infinite scrolling OFF for all users (restores to the behavior that was default between 5.8 and 7.1).

add_filter( 'media_library_infinite_scrolling', '__return_false' );

// Force infinite scrolling ON for all users, ignoring per-user opt-out.

add_filter( 'media_library_infinite_scrolling', '__return_true' );

Because the filter runs after the per-user preference is read, adding a callback overrides any individual user’s choice.

The new user option

The preference is stored as a user option under the metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. key infinite_scrolling, as the string 'true' or 'false', consistent with how existing options such as syntax_highlighting and rich_editing are persisted. It is also wired consistently through the profile form (user-edit.php), the save handler (edit_user()), and persistence in wp_insert_user() and _get_additional_user_keys().

You can read a user’s preference programmatically:

// The user setting is 'false' if the user has disabled infinite scrolling, 'true' (or empty) otherwise.

$infinite_scrolling_disabled = 'false' === get_user_option( 'infinite_scrolling', $user_id );

Note the direction of the stored value: 'false' means the user has disabled infinite scrolling. wp_enqueue_media() reads this option to determine the pre-filter default.

Backwards compatibility

  • The media_library_infinite_scrolling filter is unchanged in signature; only its default value changed (from false to true). Existing callbacks continue to work exactly as before and still take precedence.
  • Sites that had already opted in via __return_true see no change.
  • Sites that never touched the filter now get infinite scrolling by default; users who prefer the Load more button can opt out from their profile.

Props to @youknowriad, @khokansardar, @wildworks, @davidbaumwald, @joedolson, @sabernhardt for reviewing.

#7-1, #dev-notes, #dev-notes-7-1, #media, #media-library, #media-grid

Phase 3 Media Meeting: February 7, 2024

Date and time: February 7, 2024 at 24:00 UTC
Location: #core-media
Duration: 1:00 hr

The Media Component team is coordinating a meeting with the Editor team and other interested stakeholders to work on planning for the proposed Phase 3 Media Library. There are a few issues already open about the Media Library proposal, but this major development depends on close coordination between the Media and Editor teams to work effectively together.

In a recent Media Component meeting it was suggested that there should be a dedicated meeting time to kick off a round table discussion about some of the opportunities and challenges ahead in the development of Phase 3. The Media Component Maintainers hope to find areas of focus where contributors can lean in to align efforts with folks working on Phase 3.

In previous meetings the team has gone through the backlog of over 600 issues and categorized tickets as phase-3-media-triage for discussion around how Phase 3 could potentially solve these tickets alongside a rebuild of the Media Library. Some of these tickets are an opportunity to change lower level issues like db structure, but the redesign is a good time to address these possibilities.

Relevant Pull Requests, Issues, and Posts:

Phase 3: Collaboration > Media Library

PR Dataview: media view

Proposed meeting agenda:

  1. Introductions
  2. Brief presentation on the goals and vision of Phase 3 redesign for the Media Library
  3. Discussion on alignment of CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Media focus to help the process
  4. Agree on communication channels and checkpoints for regular updates
  5. Review of Phase-3-Triage Tickets

A more detailed agenda will be published prior to the meeting.

If you would like to join this meeting please join the #core-media channel February 7, 2024 at 24:00 UTC. This time seems to align with most of the world as a decent hour to meet for stakeholders and folks active in Media.


This meeting happens in the #core-media channel. To join the meeting, you’ll need an account on the Make WordPress Slack. Props @joedolson for helping prepare and proofread this post.

#agenda, #media, #media-library, #meeting, #phase-3

Media meeting recap – June 29, 2017

Overview

This post is a summary of the latest weekly Media component meeting, which took place in #core-media on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/, on Thursday, June 29 at 18:00 UTC. The purpose of these meetings are to move priority tasks forward, provide feedback on issues of interest, and review media focused tickets on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress..

Attendees:
@joemcgill, @sergeybiryukov, @mikeschroder, @adamsilverstein, @desrosj, @azaozz, @karmatosed, @matias, @youknowriad, @mkaz, @joen.

Transcript: https://wordpress.slack.com/archives/C02SX62S6/p1498759231771175

Media + GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/

Our agenda this week focussed on getting a better understanding of the current product vision for working with media in Gutenberg in order to coordinate priorities and ensure future improvements to the media component align with the needs of the new editor experience.

The major takeaway from this conversation was that Gutenberg intends to handle the UIUI User interface flows for editing media within post content inside the editor itself rather than relying on the wp.media.frame modal for these actions. The image gallery blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. in Gutenberg is a good example of this change.

Editing gallery settings in the current media modal

The current screen in the media modal for editing gallery settings

 

Editing gallery settings in the Gutenberg sidebar

A preview of editing image gallery settings in the Gutenberg sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme.

By handling post-level setting in the editor, people can immediately preview changes in the editor. This change reduces the burden of the current media modal to act primarily as media library, and as a way to manage media information that applies site-wide. This should also make it more clear when changes will affect a media item site-wide, which is a nice UXUX User experience win.

Some next steps

To prepare for this shift, we need to document the current flows that will need to be adjusted in order to support this separation between managing post-level data and site-wide media library data.

Additionally, the Gutenberg team asked for help creating blocks for additional media elements like video, audio, etc. The Gutenberg GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner. https://github.com/ repo now contains a “media” label for collecting issues that relate to the media component.

Other housekeeping items

Earlier this week, @desrosj ran a separate bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. scrub focussed on new tickets on the Media component. We plan on running separate scrubs throughout the 4.9 release cycle. If you’re interested in helping with that effort, please contact @desrosj or @joemcgill on Slack.

#gutenberg, #media, #media-library, #media-modal

Remember the Media Grid project It was original…

Remember the Media Grid project? It was original proposed back in the 3.7/3.8 cycle but never really took off — mainly due to our focus on The-Project-Formerly-Known-As-MP6 and the WidgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. team.

Since then, I’ve been working on a plugin in some spare time: https://wordpress.org/plugins/media-grid/

Its messy. Its basic. But I think there’s potential in the idea to bring the media modal’s layout to the Media Library. @helen created a GitHub repo for development: https://github.com/helenhousandi/wp-media-grid-view (Make sure you checkout the issues, especially: https://github.com/helenhousandi/wp-media-grid-view/issues/7)

I’m looking to form a team to work on this project. I think we could have something ready for 4.0, but 4.1 is a possibility as well. It all depends on you. 🙂

I’m looking for any-and-all help, but specifically 1-2 backbone-capable developers with familiarity with the Media Modal would be a huge help.

Maybe we can chat about this a bit during tomorrow’s Dev Chat. Outside of that, lets plan on meeting in #wordpress-ui this Friday, Apr 25 @ 16:00 UTC.

So, are you interested? Leave a comment below and/or join us on Friday. Thanks!

#media-library, #media-modal, #media-grid