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, @shetheliving, 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

Media Meeting Recap – October 29, 2020

The following is a summary of the weekly media component meeting that occurred on Thursday, October 29, 2020 at 14:00 UTC. Weekly media meetings are now 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, @mista-flo, @hongnizzle, @johnbillion 

Upcoming Meeting Schedule

The team discussed moving the regular meeting time to adjust for daylight savings time. It was agreed moving forward, the meeting will be taking place on Thursdays 15:00 UTC time as opposed to the current 14:00 UTC time. 

5.6 Remaining Tickets

#50972media_handle_sideload() does not allow $post_data to override – Currently owned by @sergey and set to reviewing, this ticketticket Created for both bug reports and feature development on the bug tracker. needs unit tests at the moment. @johnbillion mentioned that the functions aren’t very testable without refactoring, so the group agreed this ticket is a candidate to move to 5.7.

#41648Alignment issue on media-new.php when browse uploader screen is activePatchpatch 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. is ready to go and @antpb will review and commit. 

#39968Media Library deleting all items on the last page loses pagination/navigation buttons – This has been addressed by @mista-floand is ready for review. It was agreed that this was related to existing changes in 5.6 so it is safe to test and commit before the next 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. cycle.

#51396[Media upload.php] Switch back from grid to list mode reopen the modal. – This is a quick fix for an existing 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.. @mista-flo mentioned that this is not a critical bug so please chime in in the comments below if you have any thoughts on this fix being implemented in 5.6 or if it should wait for 5.7.

Props @antpb for proofreading and final review.

#media, #summary

Accessibility improvements to Media component in WordPress 5.5

WordPress 5.5 introduced several improvements in the 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) of the Media component.

Improvements in the accessibility of the status and error messages in the Image Editor

On previous WordPress versions on the Edit Media page, when activating the “Restore Image” button, a message was shown above the image while the Restore button itself disappears.

Since the button would have been focused at the time when activated by keyboard, this causes the keyboard focus position to be lost and reset to the top of the page.

The message itself is also not announced by screen readers, and may not be visible to screen magnification users if it appears outside their current view.

WordPress 5.5 improved the behavior of notices inside the Edit Media page with the followings:

  • Improves the focus management by moving focus to the notices, if any, or to the first “tabbable” element: this avoids a focus loss and helps Braille-only and screen magnification users to be aware of the messages.
  • Adds an ARIA role alert to all the notices.
  • Uses wp.a11y.speak() to announce messages to assistive technologyAssistive technology Assistive technology is an umbrella term that includes assistive, adaptive, and rehabilitative devices for people with disabilities and also includes the process used in selecting, locating, and using them. Assistive technology promotes greater independence by enabling people to perform tasks that they were formerly unable to accomplish, or had great difficulty accomplishing, by providing enhancements to, or changing methods of interacting with, the technology needed to accomplish such tasks. https://en.wikipedia.org/wiki/Assistive_technology: this leads to all visual users seeing the messages while assistive technology users will get an audible message.
  • Uses wp.i18n for translatable strings in wp-admin/js/image-edit.js

Related 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.: #47147.

Fix the Image Editor mismatching keyboard focus order and visual reading order

On the Edit Media page, the keyboard focus order and the visual reading
order were presented in a zig-zag pattern.

This was causing some accessibility issues for users who have a cognitive disability as they may be confused by an unexpected or illogical focus order.

WordPress 5.5 fixed that by swaping the DOM order of the two main columns within the adminadmin (and super admin) Image Editor.

See more details in the Trac ticket #47136 and the attached changeset.

Improve the appearance of image editor on small and medium screens

WordPress 5.5 added new CSS rules to improve the appearance of image editor on small and medium screens. The new rules prevent the main area of Edit Media screen from being pushed down too far.

See the related ticket on Trac: #47136.

Props to @afercia for proofreading.

#5-5, #accessibility, #dev-notes, #media