Media: Make client-side supported MIME types configurable#76549
Closed
adamsilverstein wants to merge 8 commits intotrunkfrom
Closed
Media: Make client-side supported MIME types configurable#76549adamsilverstein wants to merge 8 commits intotrunkfrom
adamsilverstein wants to merge 8 commits intotrunkfrom
Conversation
The CLIENT_SIDE_SUPPORTED_MIME_TYPES constant is hardcoded, preventing plugins from adding support for additional image formats via client-side processing. This adds a clientSideSupportedMimeTypes setting that flows from a PHP filter through the REST API and settings pipeline, falling back to the existing constant when not set. This follows the same pattern used by imageOutputFormats.
adamsilverstein
requested review from
ellatrix,
nerrad and
spacedmonkey
as code owners
github-actions
Bot
added
[Package] Core data
|
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 If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
adamsilverstein
added
[Type] Bug
Cover the new configurable MIME types setting in the REST index: verify it is absent for unprivileged users, present with correct defaults for admins, and filterable via the client_side_supported_mime_types hook.
|
Size Change: +67 B (0%) Total Size: 8.75 MB
ℹ️ View Unchanged
|
github-actions
Bot
added
[Package] Core data
Verify that prepareItem respects a custom MIME types list from settings, can add normally-unsupported types to client-side processing, and falls back to the default constant when the setting is not provided.
Plugins that convert files client-side before upload need to swap the main attached file afterward (e.g. uploading a JPEG for processing then replacing it with the original HEIC). The new replace_file boolean parameter updates the attached file, MIME type, and metadata, and deletes the old file from disk.
The preload root fields must exactly match the fields requested in entities.js. Without this, the site editor makes an extra fetch for the root endpoint because the preloaded URL doesn't match the requested URL.
Resolves PHPCS warning about double arrow alignment in the sideload item endpoint args array.
|
Flaky tests detected in 7b03bc8. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/23204523654
|
adamsilverstein
added a commit
to adamsilverstein/wordpress-develop
that referenced
this pull request
Mar 17, 2026
Add a `client_side_supported_mime_types` filter and REST API index field so plugins can customize which image formats are processed client-side via WebAssembly-based vips. The default list includes JPEG, PNG, GIF, WebP, and AVIF. Also updates the preload paths in the post editor and site editor to include the new field, ensuring the preloaded URL matches the JavaScript request. Props adamsilverstein. See WordPress/gutenberg#76549.
Links Gutenberg PR #76549 to the corresponding wordpress-develop backport PR.
Member
Author
|
Core backport PR: WordPress/wordpress-develop#11277 |
adamsilverstein
added
[Status] In Progress
Member
Author
|
@andrewserong working on making client-side media more extensible here so it is possible add support for HEIC and other newer formats like UltraHDR in the experiments plugin. This will let us make them available and testable more quickly and also open up the system so other plugins could add support for additional types. With this PR and https://github.com/adamsilverstein/client-side-media-experiments/ HEIC uploads work without server support (which is not the case currently). |
Contributor
|
If this is for 7.1, is it worth holding off for now, until after 7.0 / after the RC period? Just to make sure backports can happen cleanly. Something I'm wondering about the API for this is whether we even need the PHP side? If there's a block editor setting, then plugins can already filter block editor settings, so that could simplify things. But the main question I had is: what does it mean for plugins to change the list of image types that can be converted with client-side media processing? I thought the code for converting files happens within Gutenberg / the existing JS logic, so how does a plugin extend this behaviour? (I.e. I'd assumed that hard-coding the list would be fine, because the client-side media processing is responsible for itself). I see in the linked plugin that the IMO I'd be pretty wary about supporting this as an extensibility API as it seems quite brittle. I guess another way of putting my comment here is: how valuable is it to support filtering the mime types if a plugin has to go to such lengths to add support for the mime types they're adding? It seems a bit tangled to me. But that's just my first impression! |
Member
Author
|
Since I have solved HEIC extensibility with a different approach, I'm going to close this. |
Contributor
|
Sounds good, thanks for the update 👍 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The
CLIENT_SIDE_SUPPORTED_MIME_TYPESconstant in theupload-mediapackage is hardcoded, preventing plugins from adding support for additional image formats via client-side processing.This adds a
clientSideSupportedMimeTypessetting that flows from a PHP filter (client_side_supported_mime_types) through the REST API and settings pipeline to theprepareItemfunction, falling back to the existing hardcoded constant when not provided.This follows the same pattern used by
imageOutputFormats:lib/media/load.php)core-data/entities.js)Settingstype (upload-media/store/types.ts)prepareItem()with fallback (upload-media/store/private-actions.ts)use-media-upload-settings.js,use-block-editor-settings.js)Use case
This is needed to to add client-side conversion for HEIC→JPEG via a JavaScript library and need to tell the upload pipeline that those MIME types should be processed client-side rather than sent to the server. Without this filter, such files bypass client-side processing entirely and get rejected by the server (unless supported there).
Test plan
Expected: HEIC is processed on the client, sub-sized jpegs are uploaded using the sideload endpoint along with the original heic file.