Support for existing Media tabs

[mboynes]

Apologies if this has been discussed already and I missed it. Is there a plan to support other "tabs" from the current Media implementation? There are many plugins that use this area to integrate with digital asset management (DAM) systems and the like. Will those plugins' integrations be automatically supported, or will they all need to convert their integrations to be custom blocks?

Here's an example of one such plugin's integration, to ensure what I'm referencing is clear:

[karmatosed]

I can see adding in that tab 'if' there is a plugin that uses it. As we have blocks for everything else we don't need to bring the tab back for everything. I do wonder though, could we think a little differently and over adding a tab just add to the interface. For example in a drop down? Ideally they would be custom blocks but we have to work on a solution that solves this for the interim.

[danielbachhuber]

@mboynes Have you considered registering a block for DAM-based media? Or, taking a step back, do you see a continued need for a unified Media Library interface, or can it become more fragmented?

[mboynes]

Have you considered registering a block for DAM-based media?

For my purposes, certainly, and I can do that for my custom integrations if need be. I'm not sure that's realistic to ask of every plugin and theme that integrates with the media library to add its own "tab". That said, if that's the ask of them, I believe a strong effort must be made (and quickly!) to communicate that to the community, provide clear examples of how to make that update, and identify the plugins in the .org repo that would be affected and help them.

do you see a continued need for a unified Media Library interface, or can it become more fragmented?

It's a great question. I think a UX case could be made that, if a site uses images from multiple sources, it would be more intuitive to have one "Image" block than n "Image" blocks. Maybe a writer doesn't even know the source of the image when they go to insert the block, because they plan on searching a few -- in that case, should they insert a Getty block, open the modal, see what's there, cancel out, remove the block, insert a Shutterstock block, open the modal, ... ?

That being said, if a writer inserts an image block, I would contend that it would be a bad UX to see audio and video services. Therefore, I don't think a completely unified interface makes sense any longer. From my perspective, a more ideal interface might be a hybrid approach: the image block would show a unified interface for all image services, the video block a unified interface for all video services, and the audio block would show a unified interface for all audio services.

[danielbachhuber]

I've documented this issue in the Gutenberg migration guide.

From my perspective, a more ideal interface might be a hybrid approach: the image block would show a unified interface for all image services, the video block a unified interface for all video services, and the audio block would show a unified interface for all audio services.

I agree with this generally. We'd need to define a formal API to inject data that isn't stored in the database.

[joemcgill]

Hey @mboynes, I'm curious if you've had any time to explore an upgrade approach for your particular use case and, if so, any learnings you could share.

Providing direct backwards compatibility here is going to be tricky specifically because I expect that most integrators are overriding the default wp.media.view.MediaFrame.Post object in order to add a custom state to the media frame. However, Gutenberg is no longer using that object and is instead implementing specific extensions of the wp.media.view.MediaFrame.Select frame, which are targeted specifically to the type of media being inserted (e.g., image, gallery, video, audio, etc.).

It would be great to have some specific use cases documented so we can see if there is a way to provide compatibility directly, or document specific migration instructions.

[karmatosed]

From a design perspective I think we need to make this as simple as possible. I do agree having some specific use cases would help in determining this. I don't see the need in phase one to do anything beyond what the media library does today to support this.

[mboynes]

I'm curious if you've had any time to explore an upgrade approach for your particular use case and, if so, any learnings you could share.

@joemcgill I have not put any time into upgrading any of my media plugins and integrations. Most of my integrations leverage Automattic's Media Explorer plugin (relevant Gutenberg issue in that repo: Automattic/media-explorer#76). If other plugins we use (e.g. that Flight plugin in the screenshot) don't get fixed here or by the plugin maintainers, we'll have to upgrade them, but we won't embark on doing so until the last responsible moment.

I don't see the need in phase one to do anything beyond what the media library does today to support this.

@karmatosed if that's possible to do, I don't think anyone would expect anything more. Hopefully it will be possible to somehow maintain how it works today!

[maxhartshorn]

@joemcgill and @karmatosed, I may have missed this in the discussion but are there any Gutenberg-approved solutions for either A) adding tabs to the Media interface or B) exposing some interface for users to search, select, and embed other forms of media besides images?

Like @mboynes, we have custom tabs in Automattic's Media Explorer to let users search and embed video and audio content into posts. At them moment I'm not really grasping how to move this functionality over to Gutenberg.

Searching and embedding video and audio strike me as very common use cases for many large content-driven sites. It would seem quite surprising if this need were not taken into account by Gutenberg...but I could be missing something here..

[karmatosed]

@maxhartshorn playlist block adds tabs, that's a solid pattern to view.

[maxhartshorn]

Looks promising @karmatosed. Do you know when this will make it into a release?

[karmatosed]

Likely the next one.

[antpb]

A user can access this library flow through the classic block using the add media button in the toolbar. I'm going to remove this from the 5.0 milestone as this is going to be a big task that will need a considerable amount of decisions and work. This is better suited for a later version.

I tested using the plugin shown in the screenshot provided in this issue. I've confirmed that the media panel does have the options added by developers respected.

Documentation for respecting the add media flows should direct users to use the classic block until a different enhancement is available in a future version of WordPress.

[karamusluk]

@danielbachhuber Hi are there any improvements to support Media Tabs on Gutenberg?

Thanks

[hos-shams]

Would be great to see this feature soon.

[paaljoachim]

It would be helpful with a status update.
Thanks!

[lenasterg]

Hi.
Do you have any status update on this?

[youknowriad]

@ntsekouras now that we have media tabs in the inserter (and I believe we also an API for it, correct me if I'm wrong here), I believe we can close this issue.

[ntsekouras]

@ntsekouras now that we have media tabs in the inserter (and I believe we also an API for it, correct me if I'm wrong here), I believe we can close this issue.

We have an API, although is not public right now, and there are also plans on updating the media gallery. I'll close this one and feel free to open new tickets that are more specific to the current direction(since this issue is from 5 years ago).