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

Proposal for enhancing LCP image performance with the fetchpriority attribute in WordPress core

This post proposes adding the fetchpriority=”high” attribute to LCP images in WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. to enhance LCP performance. The proposal was created as a collaboration between members of the Core Performance Team.

Context

The fetchpriority attribute is a standard HTML attribute that can be used to indicate to the browser that a given resource should have a particular priority for when it should be considered for loading. Most commonly, using the attribute is recommended with a value of “high”, only on the most important image on a page.

It is a performance best practice to provide fetchpriority=”high” on the single image that is the “Largest Contentful Paint element” in the HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. markup, to indicate to the browser that this image should be prioritized over other resources that would compete with it for networknetwork (versus site, blog) bandwidth.

Largest Contentful Paint (LCP) is one of the three Core Web Vitals metrics, and it represents how quickly the main content of a web page is loaded. Specifically, LCP measures the time from when the user initiates loading the page until the largest image or text 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. is rendered within the viewport.

Quoted from this article about optimizing LCP

As mentioned above, the Largest Contentful Paint element can take different forms, it may be an image, text, video, or other resource. However, most commonly the LCP element on WordPress sites is an image, concretely 42.4% on desktop and 38.2% on mobile based on HTTP Archive data from February 2023. Of those sites, less than 0.03% have fetchpriority=”high” on their LCP image, so it is safe to say that introducing support in WordPress core will benefit almost all of them.

You can learn more about the fetchpriority attribute and how it should be used to optimize image performance in this article.

Proposed solution

WordPress core already comes with a mechanism to detect which image(s) not to lazy-load because they are likely in the viewport, which includes the potential LCP image. Bringing fetchpriority=”high” to images in WordPress core should make use of that existing logic for the loading attribute, which was added in WordPress 5.9. However, the two attributes should still function independently of each other. Furthermore, a few additional aspects need to be taken into consideration and implemented as additional heuristics that only apply to the fetchpriority attribute, but not the loading attribute.

Initially, the two attributes may seem like they are opposites. An image that should be lazy-loaded should not have a high priority, and vice-versa. The usage of fetchpriority=”high” however needs to be a bit more nuanced: It should only be loaded on the single most important image on the page. This is different from loading=”lazy” which should be omitted on any image above the fold — which sometimes may be just the LCP image, while in other cases it may be multiple images.

In other words, fetchpriority=”high” should only ever appear on a single image at most.

Scope

While the fetchpriority attribute is available on a few different HTML elements, the scope of this proposal is only to use the attribute on images, specifically to add it to the likely LCP image of a page so that the browser knows to load it earlier than other resources that may be competing with it.

Performance impact

Based on benchmarks conducted by members of the Core Performance Team, adding fetchpriority=”high” to the LCP image typically improves LCP performance by 5-10%, which is a notable win for adding a simple attribute to an image tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.). In some instances the enhancements can even be close to 30%, like in an example from the aforementioned article.

Browser compatibility

While the fetchpriority attribute is a relatively new attribute first introduced in 2022, it was standardized in February 2023 and is supported by all Chromium based browsers, which make up for ~70% of browser usage based on caniuse.com. Support was recently added in WebKit, and is currently available in the Safari 167 Tech Preview. Firefox has expressed positive feedback on the feature, and a ticket to support it is available. Despite not every major browser supporting the attribute, it is a progressive enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature., i.e. fully backward compatible: A browser that does not understand the attribute will ignore it, and its presence won’t cause any adverse effects.

Effectively, this enhancement is only about adding the fetchpriority=”high” attribute to the LCP image, which does not pose any risk of breaking backward compatibility.

Default behavior and customization

Similar to how WordPress core handles omitting the loading attribute on specific images, it should add the fetchpriority attribute by default on the LCP image based on server-side heuristics. While the exact heuristics are still being defined, it should be noted that the two attributes will never be used on the same image as they should be mutually exclusive.

Developers will be able to customize where the attribute should be used, e.g. when using the functions wp_get_attachment_image() and get_the_post_thumbnail(), both of which should receive support for the attribute. The default addition of the attribute to in-content images will also be customizable using a new 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 will likely be similar to existing image attribute filters like wp_img_tag_add_loading_attr or wp_img_tag_add_width_and_height_attr.

Alternatives considered

Alternatively to fetchpriority=”high”, images can also be prioritized through other means, e.g. a link[rel=”preload”] tag in the head, or a Link response headerHeader The header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes.. While those two approaches in principle allow the browser to know about loading the image even earlier, in practice there isn’t a notable difference, especially when using the tag, as at that point the entire HTML will already be loaded.

Either of the alternative approaches would furthermore require WordPress core knowing about the image in the page load lifecycle before it is even included in the output, which makes them more complex to implement in a way that is not justifiable given the little benefits it would bring over using fetchpriority=”high” on the actual image tag.

Contributing and testing this enhancement

An early version of the proposed enhancement can already be tested through the Performance Lab plugin, by enabling its Fetchpriority module, or alternatively through the Fetchpriority standalone plugin which uses the same underlying logic. It should be noted that the implementation is still being refined with additional heuristics to detect the LCP image, and since it is part of 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 rather than within WordPress core, the customization options outlined above cannot be part of this early implementation. It should furthermore be noted that the plugin implementation relies heavily on WordPress core’s lazy-loading heuristics, whereas the plan for the eventual core implementation would be to decouple the two.

A WordPress Core TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. #58235 has been opened, and a pull request for WordPress core, including the aforementioned customization options will be worked on soon.
Your testing and feedback is much appreciated. Please share your ideas, questions and thoughts either in a comment on this post, in the plugin’s support forum on wordpress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/, or on the GitHub repository.

Props to @tweetythierry @adamsilverstein @addyosmani @joemcgill @thekt12 for review and proofreading.

#fetchpriority, #images, #media, #performance, #performance-lab

Plan for adding WebP & multiple MIME support for images

This post is a follow up to the “Enabling WebP by default” proposal post (and the follow up to that post). 

TL;DR – The Performance Team has reviewed feedback, conducted research, and reassessed the approach based on our findings. Our new approach – outlined below – aims to address the concerns raised on the original proposal.

Overview

The Performance Team takes community feedback very seriously. As a result of the concerns around our previously proposed approach to serving WebP, we took a step back to reassess and dig deeper into the specific issues raised in post comments, chat, and elsewhere. This work has included:

  • Reviewing comments from the original and follow-up posts
  • Engaging in research (as noted in #289 & #290) on the storage impact of additional WebP images being created on upload and WebP compatibility across browsers, email clients, etc.
  • Sharing a survey with hosting providers to gather information about their storage and disk space infrastructure

What we found

Our goal with this research and reassessment was to collect data and additional context about each of the concerns raised by the community. With this additional information, we were then able to better understand and prioritize concerns, as well as determine how and why our approach to adding WebP should be modified.

WebP Compatibility

The team did additional research on WebP compatibility to better understand where compatibility issues might cause issues for users. Our research indicated that most compatibility issues were very minor and/or addressable:

  • Web browser compatibility: Only Safari on Mac OS < 11 and iOSiOS The operating system used on iPhones and iPads. < 14 do not support WebP, which is < 3% of all browser usage. This small percentage of non-supporting browsers will be served JPEG images. 
  • Email clients: > 97% of clients support WebP.
  • Mobile apps (web views): iOS 14+ supports WebP (and otherwise will be served JPEG images with the new approach). Android supports WebP natively from Android 4.0.
  • RSS readers: Top RSS readers all support WebP, so RSS feeds can likely leverage WebP.
  • Other: Open Graph tagtag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.) consumers have mixed support, so OG tags should remain JPEGs for compatibility.

Storage

To assess the overall impact of generating WebP images on site storage, the team surveyed hosting providers. With a total of 17 responses, the results show that the number of stored files is generally not an issue for most hosts/sites, although storage space could become an issue for some users over time. Still, for large hosts (with 1,000 or more hosted sites), the vast majority of sites (> 86%) would be unaffected, even if their storage requirements doubled. We also learned that some lower-end hosting plans with limited storage also lack WebP support in their hosting stack, which means they won’t get extra image generation anyway.

The revised approach

Based on the results of the research outlined above, our new proposed approach addresses compatibility issues by:

  • Providing a tiny (355 bytes uncompressed) JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. snippet that detects browsers that lack WebP support and loads JPEGs instead [tracking issue]
  • Only using WebP for user-facing content in the front-end (template) context. Images in other contexts like Open Graph tags, RSS feeds, and REST endpoints would continue to use JPEGs [tracking issue]
  • Adding a new parameter to the `add_image_size()` function that lets developers control whether to generate additional MIME types for each size registered. For the vast majority of image sizes this should be set to `true`; the only exceptions are image sizes that are being used exclusively outside of user-facing front-end content, such as Open Graph tags. Only for those special cases should the parameter be set to `false` to not generate additional MIME types. Developers registering custom image sizes with `add_image_size` will need to specify if the size should generate secondary MIME types by version 6.2, when we plan to make this behavior the default in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

This new approach also addresses concerns around storage requirements by:

  • Automatically generating WebP versions of only core image sizes in 6.1 by default. Custom image sizes will initially have to opt in to receive automatically generated WebP versions, or opt out if they are exclusively used for special cases where WebP is not beneficial or supported.
  • Keeping secondary (WebP) sub-sizes only if they are smaller than the primary MIME type.
  • Only generating WebP images for image sizes that are intended for use in user-facing front-end content. This avoids wasting storage space for WebP images that will never be used.
  • Introducing a 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. to control the generation of additional MIME types based on image sub-sizes. This enables developers to exclude certain image sizes, such as those that are not used in front-end content. 

Next Steps

The approach in the core patch is being updated to reflect the revisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision. outlined above. The current plan is to merge this change early in the 6.1 release cycle so that it can be thoroughly tested. Additional feedback regarding this revised approach can be left on this post or the Trac ticket.

#core-images, #media, #performance

Media: storing file size as part of metadata

In #49412 a tweak was made to the upload process. When files are uploaded to the WordPress media library, the file’s size is now stored as part of the metadata. This means that when calling the wp_get_attachment_metadata function, developers will easily be able to receive the file size of a selected image without having to call the php function filesize. This change is especially useful in situations when media is being offloaded to a third party, such as cloud services like Amazon’s S3 and Google cloud storage or a networknetwork (versus site, blog) share like NFS; as a call to get the file’s size can result in slow calls to an external server. 

Along with saving the file size to the attachment’s metadata, a new function and 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. have been added. The new wp_filesize function is useful when storing attachments on a third party source. It means that value can be filtered, preventing a possibility of a slow call to an external server. 

It is recommended that authors and maintainers of plugins designed to offload attachments to external services review this change and check that it does not affect your 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.

Props to @milana_cap for review and proofreading.

#6-0, #dev-notes, #dev-notes-6-0, #media

Follow-up on WebP by default proposal

This post is a follow up to last month’s Enabling WebP by default, which proposed a feature that would generate both JPEG and WebP images and output WebP sub-sized images in WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. The post received quite a bit of feedback, primarily in regards to technical concerns questioning if this feature should be included in core in its current state.

TL;DR – The performance team has heard the feedback and takes the community’s concerns seriously. With the help of the community, we will work on conducting additional data-driven research. Based on our findings, we will reassess our proposed approach to enabling WebP by default.

The performance team wants to see WordPress continue to innovate and improve. The main goal of this feature is to set the foundation for WordPress to be able to process and deliver more performant formats in the same way other CMS like Duda, Wix, and Shopify are already doing.

To ensure that we’re implementing this feature as effectively as possible, we will investigate the main points of concern that have been raised within the community, including continuing our research and testing on image size & quality. We will continue to share updates about our work as part of the weekly chat summaries posted to the Make Core blogblog (versus network, site)

In addition, we’ve created two issues in the Performance Lab GitHub repository for tracking analysis related to the main concerns raised by the community:

  1. Research: Impact of additional WebP images on upload [Issue #289]
  2. Research: WebP compatibility [Issue #290]

Within these 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 be the repository owner. https://github.com/ issues, the performance team will track testing and investigation related to these concerns to ensure that we have a full and data-driven picture of this feature’s impact. Please feel free to share your own research in these GitHub issues, as well.

Once we’ve completed our investigation and determined next steps on these two issues, we will work with the community to reassess two other concerns that were raised:

  1. Having the feature on/off by default
  2. Having a UIUI User interface-based control to turn the feature on/off

Thank you all for your feedback so far. We look forward to continuing to collaborate to move this proposal forward.


Many thanks to @tweetythierry, @flixos90, @mitogh, @mxbclang, and @jjgrainger for their help with this post.

#core-images, #media, #performance

Enabling WebP by default

Note: A follow-up post has been published with next steps on this proposal.

Feature Overview

This proposal seeks to integrate WebP by default into WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. WordPress supports WebP since version 5.8 and users can already upload and place WebP images just like they can JPEG images.  This proposal enhances that support in two significant ways. First, WebP images are now generated by default for new JPEG uploads (in addition to the default format WordPress already generates). Second, these WebP images are now used by default for the website content.

Advantages of using WebP

WebP was developed as a modern image format that provides superior compression on the web. Images are often some of the largest resources used by websites, and using WebP creates websites that are lighter and faster. Compared to JPEG images, WebP images generated by WordPress are almost always smaller, with a ~30% file size reduction on average (with the same visual quality).  

WordPress websites can benefit from WebP today because WebP is supported in all browsers WordPress supports and by both the GD and Imagick image handling libraries WordPress relies on. With this new feature, users can continue uploading and using the same JPEG images they do today and behind the scenes WordPress will create the more performant WebP images and use them for the website. By switching from JPEG to WebP as our default output format, WordPress sites across the web will benefit from improved performance – the primary goal of the Performance team.

How will WordPress enable “WebP by default”?

When users upload JPEG images, WordPress will now create WebP versions of the image and its sub sizes in addition to the JPEG sub sizes it already creates (while keeping the original). When rendering the website, WordPress will use the WebP versions of images when they are available. 

The new support for multiple mime types in core media is designed to be flexible, enabling developers to customize which image formats to generate for a given source image format. The feature is completely customizable via filters, so hosts or developers can adjust the behavior for both image generation (for example only generating JPEG or WebP subsizes) and image display.

Finally, this feature is backwards compatible, extending existing behavior with additional types and data. JPEG images continue to be generated as usual, and stored in the same way as previous versions.

Testing this feature

Please test this feature to help catch and accommodate as many use cases as possible! You can test this feature out using the Performance Lab plugin “WebP Uploads” module.  Developers can review code and give technical feedback by testing the latest patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. on the Trac ticket or Pull Request

Next Steps

The TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticketticket Created for both bug reports and feature development on the bug tracker. targets WordPress 6.0 to land this feature, as long as image component and core maintainers agree the patch is ready. Landing this feature in core will provide significant benefits to WordPress users,  so please help us by testing the feature and leaving your feedback on the Trac ticket or Pull Request


Thanks to @mitogh, @flixos90, @tweetythierry, @addyosmani and @joemcgill for reviewing this proposal and to the many contributors who helped develop and test this feature.


Frequently Asked Questions

  • How can I disable or control the behavior of this feature?
    • Two new filters control mime type(s) output (`wp_upload_image_mime_transforms`) and output( `image_editor_output_format`). See Trac ticket for full details on using these filters. Non-developers can use plugins to adjust the behavior.
  • Can WordPress generate only WebP images? 
    • Yes! Output type(s) are completely controllable with code (filters) and non-developers can use plugins to adjust the behavior.
  • Will WordPress create sub-sized PNG or GIF animated, transparent or lossless images?
    • This feature currently only handles lossy JPEG or WebP images, although it can be expanded in the future.. The WebP format does support lossless, transparency and animation, however support in the GD and Imagick libraries that WordPress relies on for images are limited to only certain features. 
  • I’ve heard WebP images are sometimes larger than JPEGs, how does WordPress address that?
    • WordPress now tracks the size of images it creates, so WordPress can directly compare the sizes and potentially choose the smallest size. However, in the research so far on  issue: https://github.com/WordPress/performance/issues/7 indicates every lossy WebP winds up being smaller than the equivalent JPEG.  
    • When comparing image sizes it is important to use actual images generated by typical WordPress servers, which is different from what you can achieve using dedicated image tools. For example, most servers don’t support “MozJPEG” compression which is more efficient than standard JPEG compression.
  • What happens if I upload a WebP image to WordPress
    • WordPress will now generate both WebP and JPEG sub sizes when you upload a WebP. WebP will be used as the default for front end display and you will have JPEG versions available if you need them.
  • What if my server doesn’t support WebP
    • This feature requires server-side WebP support: if your server lacks support, images will continue to work as they always have.
  • What if my website visitor’s browsers don’t support WebP
    • If you know your website visitors commonly use one of the very few browsers that lack WebP support (for example Internet Explorer 11 or Safari on MacOS < v11 Big Sur) you can disable this feature using a few code lines or a simple mini 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 (more details before launch).
  • How will this affect server resource usage?
    • When users upload images, WordPress will have to work twice as hard to generate both WebP and JPEG images and will use an additional ~70% of the storage space to store both file types. On the other hand, bandwidth consumption from website visitor image loads will decrease by approximately 30%. Hosting environments with constrained resources may want to disable this feature, or generate only WebP images.
  • Does this feature work with existing plugins that generate WebP images?
    • Yes. Core will provide extension points so existing plugins can serve already generated WebP images, and/or use core’s new generation capabilities (work ongoing in this issue).

#core-images, #media, #performance

Media Meeting Recap – May 6, 2021

The following is a summary of the weekly Media component meeting that occurred on Thursday, May 6, 2021 at 14:00 UTC. Weekly media meetings are held every Thursday at 14:00 UTC. A full transcript can be found here in the #core-media room in the Make WordPress Slack.

Attendees: @antpb, @mista-flo, @chaion07, @adamsilverstein, @paaljoachim, @hellofromtonya, @sergeybiryukov, @desrosj

Media 5.8 tickets

This meeting’s discussion focused around WebP and 5.8 Media features.

#35725: Add WebP support – WebP support has been merged! Please test on all configurations possible to ensure there are no edge case issues. Big props to @adamsilverstein and all who helped make this happen! Adam mentioned that a post is in progress that will provide an overview to the new WebP supports.

#52876 Add capability to set default format for image sub-sizes. – This ticketticket Created for both bug reports and feature development on the bug tracker. is in progress and adds a new 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. where people can set a default image type such as WebP. @adamsilverstein has asked for some testing assistance to ensure everything works as intended. Testing instructions can be found here.

#50105: Remove infinite scrolling behavior from the Media grid – It was agreed during the meeting that for the button that moves focus to the first newly loaded media item, “Jump to first loaded item” is a great way to make this not focus on images or any other specific media type and still be clear. @hellofromtonya mentioned in the meeting on the pending count issue, “I think it would be a better experience for users if we could solve it before 5.8 betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process.. That said, it would be good to get the patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. committed and then work on that specific issue as a follow-up.” It was agreed by multiple participants in the meeting that landing this sooner and iterating is ideal.

#37255: Update attachment functions to accept a post object in addition to ID@hellofromtonya mentioned keeping this ticket focused on resolving the issues that were identified and moving any broader scope to a separate issue to avoid this being punted to a future release again.

Props @antpb for proofreading and final review.

#core, #media, #summary

Media Meeting Recap – January 28, 2021

The following is a summary of the weekly Media component meeting that occurred on Thursday, January 28, 2021 at 15:00 UTC. Weekly media meetings are held every Thursday at 15:00 UTC. A full transcript can be found here in the #core-media room in the Make WordPress Slack.

Attendees: @antpb, @paaljoachim, @hellofromtonya, @joedolson, @ricjcs, @audrasjb, @mista-flo, @mkaz, @chaion07

Open Floor

This meeting’s focus began with an open floor for discussion on outstanding tickets and issues members wanted to address.

#47839: Extended file management in Media Library – @ricjcs brought up this ticketticket Created for both bug reports and feature development on the bug tracker. containing design samples of what folders could look like in the media library. Discussion occurred around what this feature would entail from a backwards compatibility perspective.

#52372: Ability to Replace image on the “attachment details” screen – This feature has been explored and ultimately closed after this comment in #49096. Per @antpb, “This is another one where I don’t think it’s a bad idea, in fact, it’s great, but it’s very much in 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 territory to make the decisions for your individual site. What may be good for one site may not be good for all. Offering the ability to replace media by default offers folks ways to unintentionally break old content.”

5.7 Tickets

#52192: REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/.: Add batch image editing This ticket is currently in review with @antpb and is aiming to be committed before alpha. It was discussed that this endpoint is low risk as it does not impact any existing endpoints and adds new ones.

#50025: Media Library not showing new uploads when filtering by date – This ticket is currently in review after it was found to have issues with the classic 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. media flow. @antpb is testing and will be aiming to commit before alpha.

#39004: Alt attributes should be searchable in media library – This ticket was discussed as being close to ready for commit, but talks after the meeting indicate it may need further testing with larger media libraries.

#52387: adjacent_image_link returns a link with no accessible text@antpb has given an initial review and is aiming to commit soon after more testing.

Bug Scrub

There are a number of enhancement tickets that still need to be scrubbed. A 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 has been scheduled for Monday, February 1 at 16:00 UTC to go over these tickets. Please join us if you would like to contribute!

Props @antpb for proofreading and final review.

#core, #media, #summary

Media Meeting Recap – December 03, 2020

The following is a summary of the weekly Media component meeting that occurred on Thursday, November 3, 2020 at 15:00 UTC. Weekly media meetings are held every Thursday at 15:00 UTC. A full transcript can be found here in the #core-media room in the Make WordPress Slack.

Attendees: @antpb, @sergeybiryukov, @joedolson, @hellofromtonya, @joel-yoder, @mista-flo, @aristath, @alexdeborba

Media Focus for 5.7

The focus for 5.7 was discussed and it was mentioned that there were many outstanding 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) issues that should be considered. It was agreed these should be moved into the scope of the release.

#50105: Remove infinite scrolling behavior from the Media grid

#50273: Media modal uses incorrect ‘checkbox’ role for list items

#47120: Media modals: Upload errors and field information are not associated with their control

#39004: Alt attributes should be searchable in media library

There has been a bit of buzz in the Media 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/. channel around a desire for more modern media formats to be considered as a focus. @azaozz recommended prior to the meeting that the following is considered when modern image formats are considered for 5.7.

A Media Focus Lead for 5.7 would be good if everybody here thinks we’ll manage to add support for (at least) .webp . Currently this is still at the “exploratory” stage. Main questions that needs solid answers:

How to resize WebP images?

How to detect browsers that don’t support WebP and serve fallback images?

Would WP expect the users to upload WebP images or would it convert JPEGs, PNGs and GIFs to WebP?

Seems that ideally WP will convert uploaded images to WebP and serve them when the site visitor’s browser supports them. The originally uploaded images would serve as fallback. Determining browser support would be best by “Server-side content negotiation via Accept headers”. Replacing <img> with <picture> on the fly would bring a lot of side effects/compat problems. Frankly not sure if that would be ready by the cut-off time of early to mid February, even if work starts right now  On the other hand, this needs to be done, 5.7 or not.

@azaozz

After a bit of discussion from attendees, it was generally agreed that for modern media formats there is still discovery work that needs to happen, a proposal to scope the work, and an outline of risks and blockers. The questions asked by @azaozz above are a good starting point in thinking this through.

@joedolson asked “Is there any reason modern image types can’t be staged across multiple releases? E.g., add support for uploading & inserting modern image types, and expand usage later? There’s nothing about adding WebP and SVG that requires them to be globally used; just made available. The bigger problems seem to be in what happens if you start auto-switching existing images between img/picture, etc.”

We’ll leave these these notes on 5.7 with an invitation to comment below about further considerations.

Time of Meeting

For frequent attendees it was determined that the current time of 15:00 UTC is currently working for most people’s schedules. If there are any thoughts on this time, feel free to comment below!

Props @antpb for proofreading and final review.

#core, #media, #summary

Media Meeting Recap – November 12, 2020

The following is a summary of the weekly media component meeting that occurred on Thursday, November 5, 2020 at 15:00 UTC. Weekly media meetings are held every Thursday at 15:00 UTC. A full transcript can be found here in the #core-media room in the Make WordPress Slack.

Attendees: @antpb, @sageshilling, @johnbillion, @paaljoachim, @hellofromtonya, @mista-flo, @hongnizzle

5.6 Remaining Tickets

@mista-flo mentioned two tickets that were not included in the 5.6 milestone but should have. These have been committed as of today.

#39968Media Library: deleting all items on the last page loses the pagination/navigation buttons and shows message – The ticketticket Created for both bug reports and feature development on the bug tracker. is related to existing changes in 5.6 and wasn’t added to the milestone. This has been reviewed and committed.

#51396[Media upload.php] Switch back from grid to list mode reopen the modal – Consensus from those present in the media meeting was that this was a safe change to include in the 5.6 milestone. It has since been committed.

Because there wasn’t time to complete the agenda item to review new tickets that require attention, @antpb is proposing a 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 away from the regular meeting times. The list has grown quite a bit, so any assistance is appreciated! Please leave a comment below with a time that works for you.

Props @antpb for proofreading and final review.

#core, #media, #summary