Future risks for this library

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 the `wp_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.