Contrib.social

Provide global setting for conversion of all images in specific format

Open on Drupal.org →
Created on 19 February 2024, 4 months ago

Problem/Motivation

We have Convert effect available in each image style.

Using this effect we can force conversion of image to the one of available formats, like modern webp for instance.

However life shows that it becomes annoying to manually add this "Effect" to the every image style.

ls some_project1/config/sync/image.style.* | wc -l
287

Which means as a regular Drupal user i have to open 287 different image styles in browser to add specific format conversion on my project. This is just an example which illustrates that we still can waste our time in some places where we can avoid it.

Steps to reproduce

1. Drupal 10
2. Standard profile installation

Proposed resolution

I would like to have some global setting "Convert all images to: [format]" stored somewhere in Drupal (maybe on this page /admin/config/media/image-toolkit).

Today's needs are to have all images converted in webp. Tomorrow avif will replace webp in all browsers. So we have to have some simple procedure to control format conversion.

Now what i suggest:
1. First i would like to hear opinions if this feature will be useful or not (here we don't talk about UI and technical issues, but opinion only about this feature request itself).
2. In case of approve - we can discuss the implementation. Here i see several issues:
2.1. On which page we will have new setting
2.2. If global setting applied -> in every image style we have to add some message saying that on this web-site global format conversion for images is applied currently
2.3. We should be (or should not be) able to override conversion in specific image style of global setting. For instance if global setting format is webp, but for some reason for some image style we don't need conversion at all, or we need conversion to some other image format. (Here i'm not sure because i can't guess the situation when we need some other format since we already using modern format applied globally). So potentially only 2.2 will be enough with no ability to override global setting per image style.

✨ Feature request
Status

Active

Version

11.0 🔥

Component
Image system  →

Last updated 1 day ago

Created by

🇷🇺Russia kostyashupenko Omsk

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @kostyashupenko
  • Comment 4 months ago →
    🇷🇺Russia kostyashupenko Omsk
  • Comment 4 months ago →
    🇦🇺Australia mstrelan

    If we convert all images on the site to WEBP it means we won't have fallback images (JPG/PNG/GIF) via responsive images. That might be ok given WEBP is almost ubiquitous, but would need to be optional for those that need to support older browsers. AVIF is not quite there in terms of support, but getting much closer especially now it's supported in Edge 121.

    There is also the approach seen in various contrib modules to automatically add WEBP/AVIF conversions to responsive image formats and retain the original fallback versions. This requires all images on the site to be displayed using the responsive image formatter and requires ImageStyleDownloadController to be overridden or modified to find the derivatives.

    Finally there is the approach of manually replicating all the image styles with WEBP or AVIF equivalents and configuring the responsive image styles to include these image styles.

    I think in most cases the simplest approach would be a global option to convert older formats to WEBP, and we can add AVIF as an alternative when it's better supported. In the meantime sites wanting to support AVIF can use a contrib solution.

  • Comment 4 months ago →
    🇫🇷France andypost

    Main issue with AVIF ATM is write support in imagick/gmagick (libheif vs libavif)

    I think it could be contrib module to ensure each image-style or responsive set has specific convertion as the last effect

  • Comment 4 months ago →
    🇺🇸United States cilefen

    It will be very much faster to do this particular feature in a contributed module than in core, and it could be later brought into core.

contrib.social Blog FAQ Discussions
Production build 0.69.0 2024