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

Improving accessibility of image alternative text in 4.7

WordPress 4.7 includes a change to the way image alt attribute values are generated. Formerly, any time WordPress created the markup for an image with an empty alt value, it would attempt to use either the caption text or the image title—in that order—as a fallback value.

In 4.7, we have removed this fallback behavior.

To ensure your images having meaningful alternative text, you should make sure to set a value for alt text in your media library.

How removing fallbacks improves accessibility

The intent of the fallbacks were to ensure each image included alternative text. In practice however, this fallback behavior often resulted in poor user experiences for people using screen readers. As counterintuitive as that may seem, let’s take a look at some common examples.

Consider a situation where we’ve uploaded an image named “edbc4ef7.jpg” without changing any additional information. WordPress will generate the image title from the file name as shown in the following screenshot of the insert media modal.

Attachment details for an image shown in the insert media modal.

Formerly, inserting this image in a post would result in HTML similar to this (simplified slightly for clarity):

<img src="https://example.wordpress.org/wp-content/uploads/2016/11/edbc4ef7-1024x683.jpg" alt="edbc4ef7" width="700" height="467" />

A person using a screenreader on this page would end up hearing the file name read to them, which is not the most helpful experience, and can be quite frustrating when the file name is lengthy.

For another example, setting a caption value but no alternative text would result in markup that looks something like this:

<figure id="attachment_1741" style="width: 660px" class="wp-caption alignright">
    <img src="https://example.wordpress.org/wp-content/uploads/2016/11/edbc4ef7-1024x683.jpeg" alt="This is a caption." width="660" height="440">
    <figcaption class="wp-caption-text">This is a caption.</figcaption>
</figure>

Notice that the alt value and the figcaption text are redundant? WebAIM describes two ways of presenting alternative text:

  • Within the alt attribute of the img element.
  • Within the context or surroundings of the image itself.

The same article goes on to explain that an alt attribute value may be omitted when an identical figcaption is present, to avoid redundancy; but best practice when using a figcaption is to provide a separate and different alt attribute to describe that image to users of screen readers.

In each case, omitting the alt attribute entirely may result in screen readers reading the file name from the src attribute, so WordPress includes an alt attribute with an empty value, i.e. alt="", whenever the alternative text hasn’t been explicitly set—a technique that is common when an image is decorative.

This change will not affect content already published, but will be the expected behavior for any new content published after upgrading to 4.7. For more background on this issue, see ticket #34635.

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

Media Weekly Update (Oct 14)

This post serves to jump-start discussion before the weekly check in, which takes place in #core-media on Slack. The next meeting is Friday, October 21 at 17:00 UTC and agenda for these meetings includes moving priority tasks forward, providing feedback on issues of interest, and reviewing media focused tickets on Trac.

Summary from last week

The last meeting was Friday, October 14 at 17:00 UTC. You can read the entire chat log in the #core-media channel on Slack.

Attendees: @mikeschroder, @karmatosed@adamsilverstein@paaljoachim, @mapk, @flixos90, and @azaozz.

  • Media organization improvements:
    • Last week, we chatted about starting up design for Media organization improvements. @paaljoachim and @flixos90 started sketching flows in GitHub.
    • @karmatosed mentioned focussing on documenting the current flows this week.
  • Add new core media widget (#32417) – No progress was made this week and it’s now too late for 4.7, but work should continue so it’s ready for a future release.
  • Rotate Full Size Images on Upload (#14459) – @mikeschroder planned to do additional profiling re: complete resize+rotate times for upload vs editing.
  • Better PDF Upload Management (#31050) – @mikeschroder is putting more attention on trying to get this in this release after chatting with @helen.
  • Drag/Drop Ordering of Media Does Not Work in Chrome on touch enabled devices (#31652) – @adamsilverstein noted that the patch to enable sortable on touch devices was ready to commit, which was handled in [38793] this week. Additional discussion about reducing reliance on `wp_is_mobile()` is happening on #33704.
  • Accents in attachment filenames should be sanitized (#22363) – @gitlost has been working on updates for this ticket, which is now closely related to fixing #24661 (`remove_accents()` is not removing combining accents”).
  • Usage of `image_size_names_choose` breaks JS attachment model attributes (#34981)@azaozz suggests using srcset in the media library to make sure full size images aren’t used if a smaller image is available (as described in the ticket description).
  • Responsive images (srcset) can include images larger than the full size (#36477) – The latest patch, which utilized `Imagick::getImageColors` adds a significant performance concerns. @mikeschroder punted this out of the current milestone for now.

Agenda for the next meeting

This week, discussion will continue on priority projects for the 4.7 release. If you have specific tickets that you want to have discussed, feel free to leave a comment on this post or reach out on Slack in the #core-media channel.

#4-7, #media

Media Weekly Update (Oct 7)

This post serves to jump-start discussion before the weekly check in, which takes place in #core-images on Slack. The next meeting is Friday, October 14 at 17:00 UTC and agenda for these meetings includes moving priority tasks forward, providing feedback on issues of interest, and reviewing media focused tickets on Trac.

Summary from last week

The last meeting was Friday, October 7 at 17:00 UTC. You can read the entire chat log in the #core-images channel on Slack.

Attendees: @karmatosed, @joemcgill, @mikeschroder, @swissspidy, @flixos90, @desrosj, @azaozz, @paaljoachim, @markoheijnen, @adamsilverstein, @jorbin, @designsimply

  • Media organization improvements:
    • @joemcgill opened up conversation about a feature project to start work on this, explaining that we have the chance to take a UI/UX first approach.
    • @karmatosed is going to head up the UI/UX side of things.
    • @joemcgill thinks the likely first step is exploration of base taxonomy support, and a review on how it is currently broken with media.
    • @karmatosed asked all those interested in working on this to create sketches of their ideal media categorization flow for review by next week.
  • Add new core media widget (#32417)@joemcgill noted that the runway for 4.7 is ending, but work can continue for a future release. @designsimply to refresh the current patch on the ticket by Monday (October 10), and may target images specifically as a first step (this is still missing a refreshed patch).
  • Rotate Full Size Images on Upload (#14459)@mikeschroder profiled this and found that while the clock time for checking and setting orientation is minimal, it took ~230ms for an iPhone 7-sized image to be rotated (total 5.6s resize time) on a shared test server. He thinks total resize time should be reduced before this is added, and that #37140 is a better step for 4.7. After discussion with @markoheijnen and @azaozz, consensus seems to be that benchmarking of upload vs manual rotation should be done to prove the UX case for #37140 over #14459.
  • Accents in attachment filenames should be sanitized (#22363)@joemcgill pointed out the new patch here from @gitlost, which looks promising. @swissspidy to take a look over the weekend (feedback is on ticket now, but could use more eyes).
  • Better PDF Upload Management (#31050) – Everyone likes this, but time running out for 4.6. @markoheijnen to target next patch by Wednesday (Oct 12) (this was moved out of the milestone, as it’s currently missing a refreshed patch).
  • Responsive images (srcset) can include images larger than the full size (#36477)@mikeschroder didn’t have time to performance test the patch. To do so shortly and post feedback on the ticket (feedback is on ticket now).

Agenda for the next meeting

This week, discussion will continue on priority projects for the 4.7 release. If you have specific tickets that you want to have discussed, feel free to leave a comment on this post or reach out on Slack in the #core-images channel.

Edit: Updated post per status on Wednesday, Oct 12.

#4-7, #images, #media

Media Weekly Update (Sept 30)

This post serves to jump-start discussion before the weekly check in, which takes place in #core-images on Slack. The next meeting is Friday, October 7 at 17:00 UTC and agenda for these meetings includes moving priority tasks forward, providing feedback on issues of interest, and reviewing media focused tickets on Trac.

Summary from last week

The last meeting was Friday, September 30 at 17:00 UTC. You can read the entire chat log in the #core-images channel on Slack.

Attendees: @joemcgill, @mikeschroder, @swissspidy, @flixos90, @azaozz

  • Unexpected change to media title behavior in WP 4.6.1 (#37989)@joemcgill noted that @sergey found a fix for the remaining UTF-8 issues and it has been committed to trunk, but needs to be backported still. @joemcgill working on getting this done. Test please!
  • Downscale to only smaller images with srcset (#36477) – It looks like a true fix is not likely to land in 4.7, since this would have likely been part of changing the way WordPress handles full size images. @mikeschroder and @joemcgill to test the current patch for performance and SSIM.
  • Better PDF thumbnails (#31050)@markoheijnen was not able to attend, but previously noted that he is continuing work on this for a week or two to try to make 4.7.
  • WordPress image’s title is not alt (#34635)@joemcgill chatted with the Accessibility team about this, and the suggestion is that WordPress should no longer guess at an appropriate alt if the user hasn’t explicitly added one. He notes that this shouldn’t be that difficult to patch, but the change will need to be well communicated.
  • image_send_to_editor filter is not fired when an Image is edited or replaced in TinyMCE (#34823) – Based on @adamsilverstein‘s feedback, it looks like the ticket should be closed, as there’s a different filter intended for this purpose.
  • Usage of image_size_names_choose breaks JS attachment model attributes (#34981) – Chatted about a bit of background. @azaozz took a look and posted a new patch for review.
  • Sanitize accents in attachment filenames (#22363) – From @gitlost’s comments, it looks like there are fixes in remove_accents() necessary that should happen first, and would likely fix the base bug here. His work on it is mostly in #24661. @mikeschroder to dig into the progress of Safari’s support of these filenames. Feedback from those who have strong knowledge in UTF/character encodings would be appreciated.
  • Rotate Full Size Images on Upload (#14459 and #37140) – Would rather not destroy EXIF/IPTC in full size images (with GD), so may be better to fix this in Imagick first. Needs performance testing. Comment left on ticket.
  • Add new core media widget (#32417) – No updates here. May not be 4.7 at this point, but @joemcgill reaching out to @designsimply for status.
  • Media organization improvements:
    • Make media library searchable by filename (#22744) – @joemcgill added a patch to fix a JOIN issue found by @flixos90. Please continue testing this, especially with large media libraries.
    • @flixos90 opened a GitHub repo to work on media taxonomies/UI, and is organizing a feature project around it. @joemcgill suggests an initial meeting with @karmatosed for high level direction, followed by changes in the plugin, or core directly where appropriate.

Agenda for the next meeting

This week, discussion will continue on priority projects for the 4.7 release. If you have specific tickets that you want to have discussed, feel free to leave a comment on this post or reach out on Slack in the #core-images channel.

#4-7, #images, #media

Media Weekly Update (Sept 22)

This post serves to jump-start discussion before our weekly check in, which takes place in #core-images on Slack. Our next meeting is Friday, September 23 at 17:00 UTC and the agenda for these meetings include moving priority tasks forward, providing feedback on issues of interest, and reviewing media focused tickets on Trac.

Summary from last week

Our last meeting was Friday, September 16 at 19:00 UTC. You can read the entire chat log in the #core-images channel on Slack.

Attendees: @joemcgill, @paaljoachim, @markoheijnen, @helen, @flixos90, @afercia

  • Unexpected change to media title behavior in WP 4.6.1 (#37989) – This is a regression, which has been partially fixed.
  • Sanitize accents in attachment filenames (#22363)@mike and @markoheijnen were planning to work on #22363 in person this past week and will decide on next steps.
  • Better PDF thumbnails (#31050)@markoheijnen tested out plugins that claim to handle this and found that all suffer from the same “corrupted image” issues that have blocked this ticket. The strategy is to see if we can detect which PDFs will fail and fall back to a default PDF icon when that is the case.
  • Media organization improvements:
    • Make media library searchable by filename (#22744) – This was fixed in [38625].
    • We had a lengthy discussion about the potential for adding a default taxonomy to attachments, including identifying some related tickets that would need to be addressed (e.g., #22938)
    • @paaljoachim shared the results of some research into how non-WP image applications handle media organization in the form of this Google doc.

Agenda for our next meeting

This week, we will continue discussion on our priority projects for the 4.7 release. If you have specific tickets that you want to have discussed, feel free to leave a comment on this post or reach out on Slack in the #core-images channel.

Priority Tickets:

HTTPS Update: @johnbillion recently posted a call for an HTTPS Working Group on the make/core blog. Meetings will be on Fridays (time TBA).

#4-7, #media