Expose a JavaScript API to extend the Media Manager

[jonathanbardo]

After talking with @mikeschroder as Pressnomics about how hard it was to extend the media manager, I wanted to open the discussion here for ways we could improve that.

One way I made it work for the Stock Photo plugins at GoDaddy was to override core bindHandlers (see ​https://github.com/godaddy/wp-stock-photos/blob/master/assets/js/stock-photos.manifest.js#L13) and register my new view. One problem with that approach is that it makes it hard for anyone else to extend it for themselves.

I'm turning out to the community so we can discuss ways we could expose hooks that would let anyone extend any part of the media manager experience. This could pave the way for awesome new plugins.

[westonruter]

I'll comment here as well with some learnings from working with the media manager JS for the media widgets. We had to extend the media modal JS a few times to get it to behave the way we needed. I'll list out the reasons for extending here and perhaps they indicate areas where more configuration (options) are needed when invoking the media modal, or perhaps changes to the default behavior.

1. Allow calls to wp.media() to pass in the desired Library instead of having a fixed set in that large if/else statement. (​ref)
2. Disable syncing of attachment changes back to server. ​ref. See #40403.
3. Add CSS class to modal container element ​ref
4. Give keyboard focus on the first focusable element in the active state. ​ref
5. Allow the text of the “Insert into Post” button from the embed toolbar to be set by options. ​ref
6. Allow the “Link Text” field to be suppressed entirely in embedding. Refs ​1, ​2.
7. Allow the initial attachment display options to be set when opening the modal and let them persist across attachment selections. Refs ​1, ​2, ​3.
8. Allow the “Insert into Post” button text to be overridden by configuration in the main insert toolbar. ​ref
9. Allow embed frame to render embed previews properly when there is no post context available. ​ref. See #40450.

Some of these already have tickets, while others should get their own tickets.

[dglingren]

I am very excited to see this ticket and the prospect of a better way to work with and extend the Media Manager. My plugin (Media Library Assistant), like many others, adds features to the Media Manager and I have found it a very frustrating experience. My JavaScript skills lag well behind my PHP skills, but I know that a better API would be a big improvement.

Here are the kinds of changes I've made:

1. Add one or more controls to the toolbar. For example, a dropdown control to filter the attachments by taxonomy term (my plugin adds taxonomy support to attachments).
2. Modify or replace an existing toolbar control. For example, add more choices to the MIME Type "views" dropdown control.
3. Add elements to the "query attachments" action and submit a new query when an element's value has changed.
4. Add or replace elements in the ATTACHMENT DETAILS pane (some support exists). For example, replace the text box controls for taxonomies with true meta boxes like those in the full screen Media/Edit Media submenu.
5. Supply initial/default values for the Alignment, Link to and Size controls in the ATTACHMENT DETAILS pane.

Adding/changing the toolbar has been a real challenge because several plugins do it and there is no way to coordinate the results, especially in a "responsive" way that adapts to changing browser window width.

Here are changes I have not been able to make:

1. Change the sort order of the items in the attachments returned from the query and in the attachments browser window. The sort order is hard-coded in the script (or was the last time I checked).
2. Change the information displayed in the attachments browser window. I've had very well-reasoned support requests for this, proposing more of a "list view" with something other than thumbnail images to identify items.
3. Change the toolbar controls on the "Create Gallery" or "Set Featured Image" windows. Unlike the main "Add Media" window, toolbar controls for these windows are hard-coded.

I'm happy to help in any way I can and I look forward to the results of this important effort. Thanks for undertaking it!

[timmydcrawford]

One pain point I think is worth bringing up from the Media Widgets project was the inability to write qunit tests for any of the functionality we were building around the Media Manager. Since the Media Manager is a pretty key piece to the flow in the Media Widgets, we had attempted to simulate the flow of selecting an image via the Media Modal and asserting model attributes in the widget and previews were rendered as expected.

Seems if a new API was built to interface with the Media Manager, we could have likely structured our code in such a way that we wouldn't have to write tests that deal with the media modal interactions. Additionally a new API itself would ideally be written with its own test coverage.

[nimmolo]

Seconding this idea. If this is WordPress, the interface needs to be well documented, extensible and customizable.

As I see it there are three major dysfunctional aspects of Media Manager.

• Lack of documentation
• Lack of extensibility
• Dependency on an obscure, nearly-undocumented framework (backbone.js)

Although I'm no Gutenberg fan, and prefer Svelte, it seems like MM could be rebuilt in React and use similar code patterns, so developers would have a single framework to become proficient in. Unit tests could probably parallel some of the testing code for Gutenberg.