How might we extend where the SVG mimetype is allowed in support of a new media library in WordPress

[andrewserong]

Is your enhancement related to a problem? Please describe.

Hi there! I'm working on an experimental media modal (and media editor) in the Gutenberg repo as part of Phase 3 of Gutenberg. It's early days for this work, but there's a media modal (powered by DataViews) that you can use in the Gutenberg plugin by activating the experiment:

Then, when you add an Image block (or use any other button to open the media library), you'll see this modal instead of the existing WordPress media library:

That's the general direction it's heading in. The problem I'm running into is that while testing with the Safe SVG plugin active, I see that the SVG mime type is only added on particular screens, and that doesn't appear to include REST API requests for fetching media items. The result is that if a user has this plugin activated for uploading SVGs, they won't appear in this new media library at all (even to select or in a read only state).

I know in the readme it's flagged that the SVG mime type is intentionally not added in all cases, in order to properly ensure SVGs are handled securely.

Is there a safe way to expand the SVG mime type support so that it can include the media REST API endpoints? From hacking it in locally, that seems to resolve the issue for the media modal experiment in Gutenberg, as it'll then allow the SVG image to be seen in the list:

If you'd like more context on this work, here are a couple of tracking issues over in the Gutenberg repo:

• Media interaction in modal WordPress/gutenberg#73085 (the one I'm working from for the media modal in particular)
• Phase 3: Collaboration > Media Library WordPress/gutenberg#55238 (the media library as part of Phase 3 of Gutenberg)

Please let me know if you'd like any further context on any of that work. It isn't slated to land in core any time soon, but I'd like to ensure that a new media library plays well with popular plugins, and this is indeed a very popular plugin!

Note: if we don't fix this, then I think the SVGs should still show up in the overall list of files (i.e. if someone adds a File block and wants to link to an SVG as a file download), it just wouldn't be available to add to an Image block, which seems pretty critical behaviour 🙂

Code of Conduct

• I agree to follow this project's Code of Conduct

[fabiankaegy]

Thanks so much for creating this detailed issue :)

[darylldoyle]

Hey @andrewserong, thanks for flagging this and for the detailed context on the Phase 3 media library work, it's really exciting to see that progressing!

You're right that we intentionally limit where the SVG MIME type is registered for security reasons, but supporting the REST API for querying attachments is definitely something we should address.

I've had a dig through the WordPress core code, and I think there's a clean way to handle this. Looking at the WP_REST_Attachments_Controller, the MIME type filtering happens in prepare_items_query via get_media_types() (line 87 here).

Since the attachments controller extends the posts controller, we should be able to hook into the rest_attachments_query filter, which fires just before prepare_items_query runs. We wouldn't need to modify anything in that filter itself, we'd just use it as a trigger to temporarily enable the SVG MIME type for that request context.

This keeps the change scoped specifically to REST attachment collection queries rather than enabling it globally.

If single attachment responses also prove problematic (though I suspect they pull the MIME type from the database), we could additionally hook into rest_prepare_attachment as a fallback.

This is untested so far, but the approach looks like it should work.

[andrewserong]

Good stuff! The new media library work is still a long way off (and isn't slated for any particular WP release just yet), so there'll be heaps of time to try out options. I like your instincts here to see about just exposing what's required to get it to work 👍