Widget Improvements in WordPress 4.9

On the heels of adding TinyMCE rich editing to the Text widget and the media widgets in 4.8, there are another round of improvements coming to the Text widget and Video widget in 4.9, among other improvements to widgets.

Shortcodes in Text Widget

One very longstanding request—for over 8 years—has been to support shortcodes in the Text widget (#10457). This is finally implemented in WordPress 4.9. It is no longer required to have plugins and themes do add_filter( 'widget_text', 'do_shortcode' ). Core now will do_shortcode() at the widget_text_content filter (added in 4.8) in the same way it is applied in the_content at priority 11, after wpautop() and shortcode_unautop(). If a plugin has added do_shortcode() to widget_text then this filter will be suspended while the widget runs to prevent shortcodes from being applied twice. If a Text widget is in legacy mode then it will manually do_shortcode() as well.

One reason for the long delay with adding shortcode support in Text widgets was due to many shortcodes looking for a global $post when they run. Since the global $post varies depending on whatever the main query is, the shortcodes in a Text widget could render wildly different on different templates of a site. The solution worked out was to temporarily nullify the global $post before doing the shortcodes so that they will consistently have the same global state, with this global $post then restored after the shortcodes are done. So if you have shortcodes that depend on a global $post—or call get_post()—then you should make sure that they short-circuit when $post is null in order for them to behave properly if used in the Text widget.

As of [42185] this nullification of $post is only done for archive (non-singular) queries; for singular queries, the $post will instead be set to be the current main queried post via get_queried_object(). This ensures that the global $post is consistent and explicit. This setting of the $post global while applying filters (and shortcodes) is also now implemented for the Custom HTML widget. Additionally, to ensure that gallery shortcodes that lack ids do not end up listing out every attachment in the media library, a shortcode_atts_gallery filter has been added which makes sure the shortcode’s id attribute is set to -1 when the widget is rendered on archive templates. This allows you to embed the gallery for any currently queried post in the sidebar. You should make sure such a Text widget is not displayed on an archive template by either adding it exclusively to a sidebar that appears on singular templates, or by using a feature like Jetpack’s Widget Visibility to hide the widget on non-singular templates.

Media in Text Widget

One reason why shortcode support in the Text widget was needed in this release is because 4.9 also allows media to be embedded in the Text widget (#40854). There is now the same “Add Media” button in the rich Text widget as on the post editor, allowing you to add images, galleries, videos, audio, and other media. To support these, core also needed to support shortcodes like captionaudiovideo, and gallery. Note there are also dedicated widgets (Image, Audio, Video, and Gallery) for these media types as well.

Having separate media-specific widgets helps with discovery and allows us to provide streamlined interfaces for each media type. For example, the Image widget now has a field specifically for supplying the link URL (see #41274), and the Video widget now provides more guidance to users when supplying external URLs (#42039). The media-specific widgets are closely aligned with blocks in Gutenberg; the existence of media inside the Text widget will align with eventual nested blocks in Gutenberg, and would be treated as Classic Text blocks in any future migration from widgets to blocks.

Embeds in Text Widget and Video Widget

One shortcode not mentioned above is embed. This one was more difficult to support because oEmbeds have not been supported anywhere other than post content. This was because there were dependencies on having a post as context for the sake of caching, as the responses to oEmbed requests get stored in postmeta. However, as of #34115 if there is no post as context the oEmbeds will now get cached in an oembed_cache custom post type instead. Since a Text widget will explicitly nullify the global $post while shortcodes are processed, this means oEmbeds will get cached in this custom post type. Similarly to how do_shortcode() now applies in the widget_text_content filter like it applies on the_content, so too now WP_Embed::autoembed() and WP_Embed::run_shortcode() both also now run on widget_text_content.

In WordPress 4.8 the Video widget was introduced with support for displaying an uploaded video file, a YouTube video, or a video from Vimeo. Each of these were displayed using MediaElement.js. Just as oEmbeds are now able to be displayed in the Text widget, so too now the Video widget has been expanded to support any oEmbed provider for video. See #42039.

Theme Styling Changes

As with the previously-introduced media widgets (#32417) and the new Gallery widget (#41914), some themes will need to be updated to ensure the proper styling is applied to media and embeds that appear in the widget area context, since previously they would only appear in post content. Please follow #42203 and #41969 for style changes that are made to the core bundled themes, as you may need to make similar changes to your themes.

Improved Theme Switching

A longstanding difficulty with widgets has been where they end up when switching from one theme to another. With #39693 this experience is improved in 4.9 by having logic that is able to better map widgets between the themes’ widget areas. As noted by @obenland in [41555], there are three levels of mapping:

  1. If both themes have only one sidebar, they gets mapped.
  2. If both themes have sidebars with the same slug (e.g. sidebar-1), they get mapped.
  3. Sidebars that (even partially) match slugs from a similar kind of sidebar will get mapped. For example, if one theme as a widget area called “Primary” and another theme has “Main” then the widgets will be mapped between these widget areas. Similarly, widgets would get mapped from “Bottom” to “Footer”.

The names for the widget areas used for the mapping groups were obtained by gathering statistics from all the themes on WordPress.org.

Widget Saved State on Admin Screen

With #23120 there is now an indication for whether or not changes to a given widget has been saved on the widgets admin screen. (Widgets in the Customizer already had a saved state by virtue of being registered as regular settings.) When first opening a widget, the button will say “Saved” and appear disabled. Once a change is made to the widget (e.g. a change event triggered), then the button will become enabled and say “Save”. If you try leaving the admin screen at this point, an “Are you sure?” message will appear alerting that if you leave your changes will be lost. If you cancel, then the first widget with unsaved changes will be scrolled into view, expanded, and focused. Upon hitting “Save” the spinner will appear and then upon a successful save it will switch to “Saved” and become disabled. The “Close” link has been changed to “Done” and it only appears when the changes have been saved. Note that the HTML5 checkValidity method will now be called on the widget form prior to attempting to submit, and submitting will be blocked if it returns false. If you have JavaScript-based fields in the widget, make sure that you trigger change events whenever changes are written into any hidden inputs; this was already a requirement for widgets in the Customizer.

Related Tickets

  • #10457: Parse shortcodes in text widgets by default
  • #23120: There should be indication that widget settings have been saved
  • #34115: oEmbed not working on author page without posts
  • #38017: Add widget instance to remaining widget argument filters
  • #39693: Fix missing assignment of widgets on theme switch
  • #40442: Widgets: Rename “Custom Menu” widget to “Menu”
  • #40854: Allow media to be embedded in Text widget
  • #41274: Improve discoverability of link URL in Image widget.
  • #41610: Widgets: Change “close” to “done?”
  • #41914: Widgets: Add gallery widget
  • #41969: Ensure Gallery widget is styled properly across widget areas in bundled themes
  • #42039: Widgets: Enable oEmbed support for Video widget
  • #42203: Ensure media & embeds in Text widget are styled properly across widget areas in bundled themes

See full list of tickets in the Widgets component with the 4.9 milestone.

#4-9, #dev-notes, #feature-oembed, #media, #media-widgets, #widgets

Media meeting recap – October 5, 2017

Overview

This post is a summary of the latest weekly Media component meeting, which took place in the #core-media Slack channel, on Thursday, October 5, 2017, 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 Trac.

Attendees:
@joemcgill, @karmatosed, @blobfolio, @mikeschroder.

Transcript: Read on Slack

4.9 beta 1 review

First of all, I want to thank everyone who helped work on tickets the past few weeks. We were able to ship all of the enhancements that were still on the milestone before the deadline 🙌🏻.

Here are the relevant tickets with commits from this week:

  • #33981 – Default Captions Should Use max-width
  • #21819 – Reduce duplicated custom header crops int he Customizer
  • #35218 – Parse the creation date out of uploaded videos
  • #41629 – Default to “custom URL” in the image widget
  • #40894 – Use Webpack instead of Browserify for build process

Please continue testing these and provide feedback as you notice anything.

Priority tickets for the coming week (beta 2)

There are two MEJS issues, both which are close to commit:

  • #41787 – Media: JS error when removing a video/audio sourced
  • #42071 – MediaElement upgrade causing JS errors when certain languages are in use

Other high priority tickets for this week:

  • #21819 – Use an image size for custom headers instead of duplicating an attachment – @joemcgill to continue iterating here, feedback and testing welcome.
  • #37750 – Cropping custom logo should preserve attachment properties – This is closely related to #21819.
  • #41973 – HTTP Error when uploading images on PHP 7.1.9 (needs confirmation) – @mikeschroder tested and left a comment. Seems like a configuration issue but we’ll continue tracking throughout beta to see if we can help resolve on our end.
  • #40175 – Upload Validation / MIME Handling – @blobfolio refreshed the patch, which needs further testing and review.

Tickets with no owner in the 4.9 milestone:

  • #40921 – Inconsistent Handling of mp4 by Audio Widget – @toddhalfpenny since volunteered to continue working on it, just needs review.
  • #41844 – Media: audio players overflow playlist containers – @celloexpressions and @melchoyce have been working on this one.

Our next meeting is scheduled for Thursday, October 12, 2017, 18:00 UTC and will be lead by @karmatosed.

#core-media, #media

Media meeting recap – Sept 14, 2017

Overview

This post is a summary of the latest weekly Media component meeting, which took place in #core-media on Slack, on Thursday, September 14, 2017, 18:00 PM UTC. The purpose of these meetings are to move priority tasks forward, provide feedback on issues of interest, and review media focused tickets on Trac.

Attendees:
@joemcgill, @desrosj, @brainfork, @blobfolio, @jdub233, @tokyobiyori, @presskopp, @nosilver4u.

Transcript: Read on Slack

Tickets Reviewed

  • #41629: Widgets: Default to “custom URL” in the image widget – @desrosj to investigate.
  • #21819: Use an image size for custom headers instead of duplicating an attachment – The main challenge is deciding on how data should be handled so that custom crops of images are associated with the original image but do not clutter up the main media library. @joemcgill to continue working on an approach.
  • #35218: Parse the creation date out of uploaded videos – @mikeschroder did some initial testing and found some concerns with creation date parsing. Needs further investigation.
  • #33981: Default Captions Should Use max-width – Patch is ready, needs second opinion. @desrosj to look.
  • #40921: Inconsistent Handling of mp4 by Audio Widget – MP4 is not in the list of extensions returned by wp_get_audio_extensions(). Patch looks good.
  • #41844: Media: audio players overflow playlist containers – Patch looks good. Needs review.
  • #38264: Tests: Uploads aren’t deleted after running individual tests – Initial approach is on the ticket. Needs review.
  • #41704: Use a consistent title for “Add Media” button and “Insert Media” window – Assigned to @sergeybiryukov for a decision.
  • #41787: Media: JS error when removing a video/audio sourced – There’s a PR for this on GitHub which needs to be reviewed.
  • #40175: Upload Validation / MIME Handling – Added to the milestone for review/commit.
  • #40774: Refine error message when embedding invalid Video (URL) – Patch on the ticket updates the error string with a more accurate message.

Next Meeting

Next meeting will take place on Thursday, September, 21 in #core-media on Slack. The agenda will once again focus on reviewing priority tickets for 4.9.

#core-media, #media

Media meeting recap – Aug 3, 2017

Overview

This post is a summary of the latest weekly Media component meeting, which took place in #core-media on Slack, on Thursday, Aug 3 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 Trac.

Attendees:
@joemcgill, @mikeschroder, @adamsilverstein, @desrosj, @karmatosed, @blobfolio, @flixos90, @paaljoachim.

Transcript: Read on Slack

Media + Gutenberg

@karmatosed shared the need for more help on media related tickets in the Gutenberg project. She’s prioritized high priority items, which can be viewed in this report. We discussed a few specific issues:

WordPress 4.9 Release

Now that the 4.9 release schedule is announced, we can better plan priorities for the release. While helping Gutenberg is certainly a high priority, we plan to review tickets to add to the milestone during the meeting next week.

Bug Scrubs + Call for volunteers

Over the past few weeks, @desrosj has run separate bug scrubs focussed on unanswered tickets for the Media component. The next media scrub is planned for Thursday, Aug 10 at 16:00 UTC. We’d like to alternate times of these extra scrubs so it’s easier for people in different timezones to participate. If you’re interested in contributing, look out for a survey in the #core-media room to give feedback on times that work for you for bug scrubs.

We also are looking for volunteers who are willing to help type up recap notes from these scrubs and our weekly meetings, which is a great way to get involved and learn more about the Media component. If you’re interested in helping with any of these efforts, please contact @desrosj or @joemcgill on Slack.

#media, #weekly-update

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 Slack, 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 Trac.

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

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

Media + 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 UI 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 block 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 sidebar

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 UX 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 GitHub 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 bug 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

Media Weekly Meeting Recap (March 2, 2017)

This post is a summary of the latest weekly Media component meeting, which took place in #core-media on Slack, on March 2, 2017 19: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 Trac.

Attendees: @joemcgill, @sergeybiryukov, @blobfolio, @adamsilverstein, @mikeschroder, @melchoyce, @karmatosed, @desrosj, @azaozz.

Prioritizing 4.8 tickets

With all Media tickets for 4.7.3 clear, we spent this meeting looking forward at our priorities for 4.8, which already included 12 tickets at the time of the meeting. With the focus for 4.8 being on the editor, customization, and the REST API, we discussed additional tickets that contribute to the goals of those projects or which may prepare for future enhancements in those areas. Here are a list of tickets mentioned during the meeting:

  • #39647: Make media upload “HTTP error.” more user-helpful
  • #15311 and #21295: Which are related to the previous ticket, in that decoupling the intermediate size generation from the upload process will probably be necessary.
  • #36191, #36442, and #21455: all relate to improving responsive/retina image support in the customizer.
  • #39993, #39994, and #39995: Splitting the media widget project into three separate widgets for image, video, and audio. @melchoyce mentioned that image is the priority.
  • #36581: Customizer Header Image Control should extend the cropped image control
  • #21819: Use an image size for custom headers instead of duplicating an attachment
  • #37840: Optimize full size images
  • #24251: Reconsider SVG inclusion to `get_allowed_mime_types` – @blobfolio and @enshrined have renewed interest in working on this. If you’re interested, take a look at this repo and provide testing/feedback.
  • #39963: MIME Alias Handling
  • #39883: Code hooking on `image_downsize` can no longer assume the file is an image (related: #39980). This one is a priority for the next minor release.

In the upcoming weeks, we plan to prioritize these and assign ownership to contributors in order to help people focus efforts and to help new contributors know where to get involved. This list is large, so if you’re interested in helping out, please feel free to jump in on the tickets themselves, ping in #core-media, or leave a comment below.

If there is something you feel should be prioritized that is not included on this list or already on the 4.8 milestone, please leave a comment on this post or bring it up in the #core-media channel on Slack. As always, important bug fixes will be considered as they are presented.

Next Meeting

Due to conference travel, we’ll be skipping next week’s meeting, with the next one scheduled for March 16, 2017 19:00 UTC.

#core-media, #media, #weekly-update

Media Weekly Meeting Recap (Feb 17, 2017)

This post is a summary of the latest weekly Media component meeting, which took place in #core-media on Slack, on February 17, 2017 2000 UTC. The purpose of these meetings are to move priority tasks forward, provide feedback on issues of interest, and review media focused tickets on Trac.

Attendees: @joemcgill, @sergeybiryukov, @dnavarrojr, @adamsilverstein, @pputzer, @mikeschroder, @desrosj, @gitlost.

Meeting Time Change

The group decided to move the weekly meeting to Thursdays at 1900 UTC, which is more convenient for participants.

Tickets discussed

We spent this meeting doing a bug scrub for tickets on the 4.7.3 milestone.
Start: [https://wordpress.slack.com/archives/core-media/p1487361876001149]

  • #39883 image_downsize assumption changes: Added to 4.7.3 milestone for prioritized discussion.
  • #39774: PHP 7.1 warning during upload of file with the same name: 
Approved for merge from 4.8 to 4.7.3. @sergeybiryukov to handle it.
  • #37140: Reset of rotation orientation when image is rotated:
 @mikeschroder tested, found fix for issue in tests. Reached out to @sanchothefat re: whether the current number of images being tested can be reduced to not slow down the tests. Otherwise, this looks ready.
  • #39516: Media grid upload errors display below the grid:
 Still needs testing. @joemcgill would appreciate additional eyes here.
  • #39550/#39552: Some Non-image files fail to upload after 4.7.1: 
@joemcgill to write up two possible solutions for the problem to address image files not properly validated with GD so that we can profile appropriately. There are performance concerns around adding ⁠⁠⁠⁠finfo_file() to all files uploaded.
  • #39875: PDF previews overwrite existing images with the same name:
 Worked through this in chat. @gitlost uploaded one approach to the ticket, with @desroj writing up another one based on our conversation in the meeting. Decision being that the filename saves should be handled in the same way that saves happen in the Media Gallery’s image editor. The problem is in https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/image.php#L254, with pre-existing method in https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/image-edit.php#L779.

Our next meeting is scheduled at the new day/time of February 23, 2017 at 1900 UTC.

#media, #weekly-update

Idea: Uniform Resource Identifiers as an Alternative to Shortcodes

The idea is that any objects embedded in a post’s content have their own home and should be seen as separate resources. Data would be stored elsewhere.

Examples

  • https://example.com/resources/contact-forms/email-ella/
  • https://example.com/resources/charts/php-versions-wordpress/
  • https://example.com/author/iseulde/
  • https://example.com/galleries/yummy-chocolates/
  • https://example.com/surveys/wordpress-editor-2016/
  • https://external.com/some-map-or-form/

Object Types

This approach could be good for:

  • Forms such as contact forms, surveys and polls.
  • Visualised data such as diagrams, charts, graphs and tables.
  • Lists of items such as a galleries, playlists and lists of posts.
  • Albums or manually composed collections of items where the presentation is uniquely different from a normal list.
  • Any content that needs to be reused or organised separately. Anything that can be re-sourced. 😉
  • Any external resources.

This is not good for:

  • Layout.
  • Text conversions.

Inspiration

  • External embeds work similarly in WordPress through oEmbed.
  • Images, audio and video are embedded by their URL in HTML.
  • Media have their own “attachment” post type in WordPress.
  • Many plugins already have a separate post type to store their data.
  • I’ve seen some news media do this already for things for like graphs (post, resource).

Benefits

  • A URL (or “link”) is a concept that is already familiar to many users.
  • URIs are designed for these sort of things. Think about images — it would follow the same paradigm.
  • The content is treated as a separate resource, and can be reused, just like shortcodes, but it forces separation.
  • WordPress allows you to create “pretty” semantic URIs, so the resource can be described for a better experience.
  • A cool side effect is that others could embed these easily on their site through oEmbed. WordPress already supports this.
  • If there’s a problem, the URL will act as a fallback.

Implementation

A quick way to implement this for WordPress 4.4 and higher is registering a new post type. This will handle most things, you just need to provide a custom embed template with the template_include filter. An external resource can be filtered with the Embed API and TinyMCE View API, even if it doesn’t support oEmbed.

Challenge: Variants and Settings

Either each variant of an resource needs its own ID, or settings could be passed with a query string. I think the use of settings should be minimised — for example, columns for a gallery object may be better set per ID. Settings can certainly be useful for things like autoplay, for example YouTube allows you to set the start time.

Challenge: Alignment

This is great if the URL is added on a separate line, but aligning the object is not evident. This is a challenge for shortcodes too. At the moment the core galery shortcode does not allow you to allign it, and the caption shortcode has an attribute for it. Similarly the URl could have a query parameter for alignment, but that doesn’t sound ideal. Alternatively the paragraph could be floated, or it needs to be wrapped in a `div` element to float mid-text. Another approach is to always wrap the URLs in a (custom) tag that can have display information. Again, think about how images are embedded in HTML.

Possible solution:

<figure class="alignright">
 https://example.com/galleries/yummy-chocolates/
 <figcaption>Chocolates.</figcaption>
</figure>

Challenge: Namespace

Shortcodes would have a similar problem, though slug clashes are probably more likely. Ideally plugins should use their own prefix, but this may be seen as ugly. Another way to avoid clashes with other post types is a sub type for “attachments” or “resources”.

Challenge: Extra Queries

I don’t see this exactly as a challenge, as it’s the nature of the concept, but it may be used as an argument against it. Many shortcodes already make use of custom post types to store data and embedding media (or anything else) also requires extra queries. If and how this should be cached is another problem.


I would love to hear your thoughts on this alternative, especially from those who use shortcodes for this type of objects in the post content. If you already use a custom post type, why not take advantage of embedding instead of creating shortcodes? If you want to embed external resources, why wrap it in a shortcode?

If you have other alternatives, I’d love to hear about those too!

#editor, #media, #plugins, #shortcodes

Media Changes in 4.7

This post provides an overview of the changes to the Media component in WordPress 4.7. See a list of all the 4.7 media tickets.

Two notable changes, enhanced PDF support in the media library and changes to the default fallbacks for alt attributes, are explained in separate posts.

https://make.wordpress.org/core/2016/11/15/enhanced-pdf-support-4-7/

https://make.wordpress.org/core/2016/11/11/improving-accessibility-of-image-alternative-text-in-4-7/

Make media library searchable by file name (#22744)

Before 4.7, if you uploaded a file to the media library and changed the title, it wasn’t possible to find that file again by searching for the file name. Now, attachment search queries will also include matches to the _wp_attached_file post meta value.

Other enhancements and bug fixes

  • Added a $wp_error parameter to wp_insert_attachment() (#37813)
  • Fix Drag/Drop Ordering of Media in Chrome on touch enabled devices (#31652)
  • Avoid undefined offset notice in wp_prepare_attachment_for_js() when image_downsize filter in used in (#34437).
  • Improve docs for image_send_to_editor filter (#34823).
  • Use wp_get_attachment_metadata() instead of get_post_meta() where appropriate (#36246).
  • Ensure wp_get_attachment_link() output text for non-images (#37343).
  • Avoid undefined index notices when pathinfo() is used (#37608).
  • Improve alignment of inputs and button heights in media edit screens (#37806).
  • Set focus when closing the media modal (#38142).

#4-7, #dev-notes, #media

Enhanced PDF Support in WordPress 4.7

WordPress 4.7 makes it easier to preview PDFs in the media library by generating image representations of the first page, which are now used throughout the media library and media attachment screens.

If a WP_Image_Editor is available that supports PDF, the following sizes are generated:

  • Full size representation, rendered at 128dpi.
  • Thumbnail (without cropping)
  • Medium
  • Large

The sizes generated can be modified, or the feature disabled entirely via the new fallback_intermediate_image_sizes filter, and are all stored in the sizes array in attachment meta.

The preview images generated are used within the Media screen, Gallery, Attachment Details, and on the Attachment page for PDFs.

Core support is provided through WP_Image_Editor_Imagick and requires Imagick, ImageMagick, and Ghostscript support. When not supported, or if the generation fails, WordPress falls back to previous behavior and saves the attachment without adding image previews to meta.

For more context, see #31050 for the primary ticket and #38594 for the filter.

Updated:

Since this change requires having Imagick load only the first page of a PDF for performance reasons, this means that if you rely on core loading the entire PDF for your extension of WP_Image_Editor_Imagick, this will no longer function as expected (See: #38832).

As a result, in [39303], the PDF setup code was moved to WP_Image_Editor_Imagick->pdf_setup(), which can be overridden to restore the previous behavior if needed.

#4-7, #dev-notes, #media