Open erikyo opened 2 years ago
Save the SVG. There are already tools for checking security in Gutenberg next time. Prohibit the use of SVG in other places. Maybe a separate library for SVG could solve image access control.
The problem is broader, I think. Existing solutions don't allow us to use SVG everywhere we use bitmaps. We use bitmaps very widely. Сonvenient library. Posts: unlimited number of blocks, featured images & post thumbnails, metadata and... Controlling how pictures should be displayed: sets of sizes, filters in blocks... I'm sure you can add other familiar features.
The breadth of use of the SVG is very limited now.
We cannot use the usual size sets, I think it's no hard to add.
A small draft of the SVG saving mechanism.
After checking the SVG, we must save the cleaned file and get the hash of the file, including the file size and modification date. The resulting hash is saved in the attachment metadata.
Next, we can intercept access to the file and check the hash of the file and the stored value for the cleaned file. If the hash is not equal, we can give away an fallback image.
It would be great to have additional fields in the library informing about the check and a tool for mass checking files. The idea can be borrowed from Regenerate Thumbnails plugin
One another way. Create a custom svg_post post type. SVG files created in Gutenberg are easy to save as a new Post for the appropriate post type. An archive of these entries can be used as a SVG library.
Obviously, files from such a library can not be used everywhere.
I'm working on this but with a core/image variation because the current plugin block only renders the svg markup, like when you inline the svg code inside the page.
And this has some pro and cons, for example a in this way you can keep the number of external resources very limited but on the other hand it doesn't store anything in the media library.
With the new block (that is a variation of the core/image) I hope to fill the gap and save the svg images as png or webp (js canvas?) inside the media library and then add the real svg markup inside a custom post meta of the image (that is a post type "media" of the wordpress database). The svg can then be used in the image src as a base64, but I have yet to fully understand how to create a React HigherOrderComponent that will allow me to override only the functions I want from the core block... I'm working on it 😅
I know svg's are extremely dangerous to handle with php and imagemagick so I want to allow any kind of filtering on "upload_mimes", actually the svg block is a react component with dompurify that filters svg's with each change applied, I think it's a simple and safe way
Ok got this! The core/image variation works and i'm able to base64 svg into core/image block. At this point I only need to save the svg image into the media library (as @vralle suggested i've also added all the possibile metadata stored into file like file size and modification date).
Starting from the fact that I don't want to enable uploading svg's to the media library but I want to make them appear there maybe the best way is to create a shadow copy in a raster format and then use the svg as a custom meta. The problem is then replacing svg's back when they are not handled by my plugin, i need to better check how media uploader / media gallery works
I've added a way to to convert the svg to webp (or to png if that function isn't available in your browser, like the older versions of safari)
What is missing now is to find a reasonable way to move svg's to the media library and in case an svg is selected from the media library to transform the container in the svg-as-image block.
as @SergeyBiryukov and @masteradhoc said, the normal expectation of a user is to find the svg's he uploaded in the media library... it would not be that difficult to create (with canvas for example) a png copy of the svg image and store it in the media library, but it would be tricky to find a way to replace the image on the fly in case it is selected from the media library to be added to the document.
This is perhaps one of the limitations of including svg's as an html fragment, although at the same time it is what gives the ability to edit them