Media Meeting Recap – October 4

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 4, 2018 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 issues.

Attendees:
@joemcgill @danielbachhuber @mikeschroder @sergeybiryukov @pfiled @antpb

Transcript: Read on Slack

WordPress 5.0

This meeting focused entirely on the WordPress 5.0 milestone Gutenberg Issues. We reviewed each of the 18 remaining issues to determine:

  • is the issue a must have for 5.0?
  • what are next steps to getting the issue solved?

Things are looking good! This meeting resulted in remaining 5.0 issues being brought from 18 down to 11. We will focus work in the next week on Gallery backwards compatibility and Media Tabs which will help solve out more of the 5.0 milestone issues. Let’s get right into the issues discussed!

Featured Image dialogue missing “Mine”, “Uploaded to this post”, “Unattached” filters

It was agreed that this was a nice-to-have bugfix.


Consider feature parity for “Image Details” TinyMCE functionality

`attachment_fields_to_edit` filter is not respected in the image fields in the media modal in GB. Which means if you need to add in a required field to an image, it won’t show up in the Gutenblock sidebar. Since this ticket is focused around everything missing from Image Details, it would be great to get someone with agency/build experience to help. Any feedback would be much appreciated. 


Insert Link to image needs “open in new tab” option

There is already a fix ready to go. Just needs a refresh and we can merge. @antpb has tested the PR and all is working well. Currently getting Design final feedback and will get a second review on the code : https://github.com/WordPress/gutenberg/pull/9520


Support for existing Media tabs

Crucial to 5.0. There are some challenges…

As @joemcgill stated in the meeting: “The old media button opened a modal using the `wp.media.view.MediaFrame.Post` frame, which provided workflows for any kind of media you wanted to embed from a single modal. In Gutenberg, we are opening specific frames using `wp.media.view.MediaFrame.Select` which are optimized to the type of block you’re inserting. So it wouldn’t make any sense to include an extra menu item for an image source within the video block, for example. The `Select` frame doesn’t include the same menu area by default anyway. IMO, this is all a good thing, but what we need to do is provide either

a) a way for third parties to register their content area based on media type, which we then display in the modals for the correct blocks.

b) assume that integrators will provide their own block interfaces that are specific to the media source.

The former would be my preference.”


Uploading messages for media shouldn’t stack

@joemcgill said “I agree with the approach on the ticket. Nice to have, not a blocker.”
We are removing the 5.0 milestone so we can stay focused on the major blockers. We can circle back to these as we finish the merge critical tasks.


Gallery Block doesn’t apply the ‘post_gallery’ filter, causing incompatibility with WP Gallery Custom Links

Gallery: figure out way to fallback to shortcode

Both of the above issues could be solved with ServerSideRender. We could have a theme support option that can fallback to ServerSideRender. This would ensure that we hit the post_gallery filter. We could communicate out to developers that the option is available and their way to get Gutenberg ready would be to set the option. We can keep gallery as is and depend on the theme support to set the type.

@danielbachhuber mentioned “Just to drop another idea: we could fall back to `ServerSideRender` _only_ if a `post_gallery` callback was detected.”

Daniel’s suggestion seems to be the best path forward. @antpb will be working on these in the coming week.


Media Library doesn’t update after dragging image onto Image block

This seems high priority for 5.0 as the drag and drop feature breaks after first use. I’d need to do some digging into drag/drop events to really understand how to fix this. Any thoughts around?

@joemcgill said “Yup. So, this is a result of the main drag/drop interface using totally different plumbing that the media modal.
The dropzone and file uploader use the REST API, whereas the media modal uses the old ajax-action.
When you upload a new file through the media library, the attachment gets added to the backbone collection that the library uses and the library persists. We need to either always fetch a fresh collection when opening the media modal or listen for other upload events and refresh the collection passively.”

Agreed all around that this is a need to be fixed.


Images → Gallery transform fails for ID-less images

This will be moved out of the 5.0 milestone as it is not a blocker.
@joemcgill mentioned “I don’t think that the gallery block supports external images at all, unless I’m wrong. So that would be an enhancement (IMO). In the mean time, I wonder if we can add some logic that only supports that transform _if_ all selected images include IDs. That would at least eliminate the bad UX” We can circle back to this issues after merge critical issues are cleared.


“upload_files” capability and Image relative blocks

This is a must have: Seems the bulk of the work is being done here: https://github.com/WordPress/gutenberg/pull/9301. This PR is in need of a refresh. @antpb will finish this one out


Image Block: when using a small image enlarged pixelated version is flashed on page load/refresh

This issue was no longer valid. Closed.


Image block needs to handle variety of sources

This was recently given the low priority tag, so we should remove it from the 5.0 milestone as it is not a blocker. We can circle back later.


<img/> tags missing attribute filter

@joemcgill stated “Gutenberg uses a different markup structure entirely with a different filtering process. I think we would be better off writing upgrade notes that explains how to do this correctly going forward, but am open to solutions that allow back-compat of the previous filter if we can come up with an approach.” It was agreed that this was the best path forward. We are certainly open to discussion around the decision.


Insert from URL missing when adding an image

@joemcgill said “I didn’t realize that both cases were being addressed (this and the upload_files caps check) in the same PR.
Not sure about the approach there, but I do think we should try and support inserting from URL if we can.” We’ll need to see if this can be split in two tasks.


Images alt attribute in an editing context

This seems pretty important. It should be fairly simple to set a default alt if none is passed back from the media modal.

@joemcgill said “Yup. Let’s keep it as a must have. I’m happy to work on that one.”


Gallery: choosing thumbnail size

@joemcgill said “This is similar to the other image enhancements we were looking into. It’s quite important for responsive images that we’re selecting the best image size for the layout. If the gallery block is still inserting “full” size images, then this is really bad for page speed performance and should be addressed.
I’m less concerned about choosing explicit intermediate sizes (e.g., medium, large, etc) but we shouldn’t be using full unnecessarily.
Related: I think we need to go through https://github.com/WordPress/gutenberg/issues/6177 and break it into distinct actionable issues and see what could be milestoned. That issue contains too many items, IMO.”


Next Meeting

The next #core-media meeting is set for Thursday, October 11, 2018 at 18:00 UTC See you there!

#core-media, #media, #summary

#core-media