Open johnbillion opened 3 years ago
The infinite scrolling removal in WP 5.8 has broken AMF because the response format of the Ajax call has changed, although compatibility can be added. See https://core.trac.wordpress.org/ticket/50105 at comment 81 onwards.
Media library work has started as part of Gutenberg phase 3: https://github.com/WordPress/gutenberg/issues/55238
If the media modal or media grid get rebuilt in React (but continue to use the existing Ajax endpoint for fetching attachments) this would break the extend_toolbar() function which overrides the behaviour of the "Insert" or "Select" buttons in the Backbone view that triggers the creation of an attachment at the point where a media file gets used.
WP.com already replaced the media library in Calypso with a react implementation years ago so there's already prior art to draw on for gutenberg work if it's a straight up replacement of the modal
Of note, this is in the standard block editor, they've yanked the media modal out and put a new one in. It's possible they maintain a fork of Gutenberg in order to do this but it might be feasible to do this ourselves if the cost is worth it.
If the media modal or media grid get rebuilt using the REST API (or GraphQL) instead of the existing admin-ajax.php endpoint to fetch attachments then a real attachment would need to exist for each media item, because that's the response format that's expected.
To mitigate this it might be possible to override requests to the REST API for media when browsing the media manager in order to use a different endpoint which returns placeholder IDs for each "attachment". Not ideal, this sends us down the route of lying about attachment IDs which is what this library intended to get us away from.
This has sort of half happened already
There's an API tied to this that could remove the media library as a source and insert new providers, and already does so for OpenVerse out of the box.
Media library work has started as part of Gutenberg phase 3: https://github.com/WordPress/gutenberg/issues/55238
This looks like it's intended to replace the media admin menu using adjustments to standard data views and a new attachment edit screen, no designs for the backbone modal pop up yet though
This is how the wp.com react media modal implemented multiple sources:
Though google images is missing from the inserter implying they have separate sources:
The main reason AMF can work as intended is that the media library in WordPress gets its attachments populated via an admin-ajax.php request which uses a response format which is not a representation of
WP_Post
objects (see thewp_prepare_attachment_for_js()
function). This allows AMF to override what gets returned and displayed in the media library without an attachment having to exist for each media file.If this were to change in the future then AMF would cease to work. With that in mind I've collected some risks and potential mitigations.
The admin-ajax.php attachment requests in the media manager get replaced
If the media modal or media grid get rebuilt using the REST API (or GraphQL) instead of the existing admin-ajax.php endpoint to fetch attachments then a real attachment would need to exist for each media item, because that's the response format that's expected.
To mitigate this it might be possible to override requests to the REST API for media when browsing the media manager in order to use a different endpoint which returns placeholder IDs for each "attachment". Not ideal, this sends us down the route of lying about attachment IDs which is what this library intended to get us away from.
The Backbone JS for the media manager gets replaced
If the media modal or media grid get rebuilt in React (but continue to use the existing Ajax endpoint for fetching attachments) this would break the
extend_toolbar()
function which overrides the behaviour of the "Insert" or "Select" buttons in the Backbone view that triggers the creation of an attachment at the point where a media file gets used.To mitigate this we'd need to ensure AMF can still hook into the point where a media file gets "used" so it can be intercepted and an attachment created just as it does now.
Both of the above
A double hit, and to be honest if one happens it's likely the other will too.