During a recent migration to WordPress from another CMS, we struggled to work around the block converter's current behavior of sideloading all images that it encounters. It would be helpful to be able to tell the block converter to use an existing attachment for an image block, and it would be helpful to be able to create image blocks where the image comes from only a URL, not an attachment.
Use Case
We had two cases in which we didn't want sideloading to occur:
When we had already imported the images as part of other migration logic and wanted the block converter to reuse those attachments.
When the images were hosted on other sites, in which case we didn't want to sideload them at all, but instead migrate them as image blocks referencing the external URL.
As far as I can tell, there aren't filters or other means for controlling sideloading behavior that accommodates these cases. The wp_block_converter_sanitized_image_url filter runs after the converter has already committed to uploading the image to the site. We could have used a macro, but at the expense of having to recreate the rest of the block converter's logic for creating image blocks.
To me, the risk of inadvertently copying loads of images from third parties as part of using the block converter is reason enough to switch to an opt-in model, where all image blocks are created as "from URL" image blocks unless the developer specifies that the image should be sideloaded. But I can be persuaded in a different direction about that.
Description
During a recent migration to WordPress from another CMS, we struggled to work around the block converter's current behavior of sideloading all images that it encounters. It would be helpful to be able to tell the block converter to use an existing attachment for an image block, and it would be helpful to be able to create image blocks where the image comes from only a URL, not an attachment.
Use Case
We had two cases in which we didn't want sideloading to occur:
As far as I can tell, there aren't filters or other means for controlling sideloading behavior that accommodates these cases. The
wp_block_converter_sanitized_image_urlfilter runs after the converter has already committed to uploading the image to the site. We could have used a macro, but at the expense of having to recreate the rest of the block converter's logic for creating image blocks.To me, the risk of inadvertently copying loads of images from third parties as part of using the block converter is reason enough to switch to an opt-in model, where all image blocks are created as "from URL" image blocks unless the developer specifies that the image should be sideloaded. But I can be persuaded in a different direction about that.