[Media Upload Modal]: Add MIME type filtering to support text/vtt tracks

[yogeshbhutkar]

What, Why, and How?

Closes #77515

There’s an existing use case where a specific MIME type (e.g. text/vtt) is passed to the MediaUpload modal to restrict selectable files for text tracks. Consumers may also choose to rely on this behaviour to limit selection/uploads to certain file types.

Ref:

gutenberg/packages/block-library/src/video/tracks-editor.js

Line 39 in a98f133

const ALLOWED_TYPES = [ 'text/vtt' ];

In the current experimental implementation, the MediaUpload modal uses the media_type REST parameter to pass values like "text/vtt". However, this results in a 400 error in Trunk, because the REST API only accepts a fixed set of values for media_type (image, video, text, application, audio). As a result, when "text/vtt" is passed, the request fails, and the media modal always shows “No results” for Text Tracks.

Ref:

File types such as "text/vtt" are expected to be passed as a MIME type to the REST API (Ref). This PR updates the filter logic to use mime_type and media_type in conjunction to cover such cases.

Testing Instructions

1. Make sure to enable Media Upload Modal from Experiments.
2. Insert a Video block.
3. Upload or select a video.
4. In the block toolbar, click Text Tracks.
5. Under Add Tracks, click Open Media Library.
6. Verify all the tracks are displayed as expected in the media modal.

Screenshots

Before	After

Use of AI Tools

Claude Opus 4.6 to review the changes and research on REST params.

[Copilot]

Pull request overview

Updates the experimental DataViews-based Media Upload Modal to correctly filter media library results when allowedTypes includes full MIME types (e.g. text/vtt), aligning with REST API expectations and fixing “No results” for Video Text Tracks selection.

Changes:

• Derive REST query filters from allowedTypes by splitting values into media_type (top-level types like image) and mime_type (full MIME types like text/vtt).
• Avoid sending invalid media_type values (e.g. text/vtt) that cause REST 400 responses.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: yogeshbhutkar <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[ramonjd]

This is generally working well for me, thanks for the PR. I can't spot any API errors.

I'd lean on @andrewserong's assessment.

[andrewserong]

Thanks for the ping! I was actually in the middle of testing it out, I'll leave a proper comment shortly 😄

[andrewserong]

Thanks for this fix! It's testing well for me:

✅ Mime-type based filtering for text/vtt works as expected
✅ File block's accepting of all types continues to work
✅ Gallery block filters for images as expected
✅ Video block filters for videos as expected

vtt view works nicely:

Something for us to keep in mind further down the track is how we'll handle the available filters when we make the file type field support filtering in DataViews. This is currently blocked by an issue in core where paginated results when a filter is active can result in duplicate items across pages. If/when this is resolved by WordPress/wordpress-develop#10262 we'll be able to revisit it.

In any case, the reason I mention it is that we'll need to make sure that the filters are a subset of allowedTypes set on the modal itself, and don't allow broadening beyond their scope. Not anything to worry about this PR, but I just wanted to capture the thought. I've added a to-do list item to the Media interaction in modal issue (#73085) to keep track.

LGTM! 🚀