🇫🇷France @DrDam

We are hosting on Pantheon which sits behind the Fastly CDN. Sounds like disabling flush_derivative_images is recommended with this setup?

that's what I would recommend. The "derivative cache" are supported by the CDN, so no need to "force drupal" to handle it.

I've read this a couple of times and I think that you are missing the word "no" in the above sentence, that "... there is no way to detect...". Can you clarify ?

You are right, I fix my message. There is no way

Fix in release 2.0.7

I have create a second merge-request for 2.x branch

Fixed in release 2.0.6

drdam → changed the visibility of the branch 3270150-can-media-library-2x to hidden.

drdam → changed the visibility of the branch 3270150- to hidden.

In Drupal 10.3+ , we have a new static method to do that

$converted_original_uri = ImageStyleDownloadController::getUriWithoutConvertedExtension($original_uri);

I'm open a merge request to add this

As a note, I think it's necessary to question the need to have 250 different image styles in the project, just for the issue of storage space consumption (green-it / eco-design / cost / greenwashing...).

Did you use sort of CDN or S3-like storage services ? In this case, the disabling of the flush_derivative_images, in settings are the way to fix the issue.

In crop entity perspective, there is way to detect if the newly created crop is created from a "new uploaded image" or because someone change the ImageStyle configuration to adding crop in it (and a derivative image already exist for the source and must be flushed).

I have made the MR on 1.x branch

You can check : https://www.drupal.org/project/crop/issues/2617818 ✨ Support multiple crop variants per URI and crop type Needs work

or the media_contextual_crop → collection

I agreed for breaking the loop for performance issues.
If the style have 5 effects and if the crop are the first, there are no use to check all others.

Seems like https://www.drupal.org/project/crop/issues/3293782 🐛 Crop API is not appending a hash when the image styles are converted to WEBP Needs review

Check https://www.drupal.org/project/crop/issues/3228376 🐛 Can't delete a crop type Needs review in order to purge and delete all crop entities

[replace patch by a cleaner one]

Some update here and a "redo" of the patch for Drupal 11

Fixed in 1.1.4

Waiting ImageWidgetCrop Drupal 11 release

Released in 2.0.2

Released in 2.0.5

Released in 2.0.4

Released in 2.0.4

Released in 2.0.4

Fixed in release 2.1.3

Fixed in release 2.1.3

In release 2.1.3

Fix in release 2.1.3

@oskar_calvo : 

- on your host entity (node), you add an "reference field" => 'media with contextual modifications" field and in the form_mode choose "media library extra"

- on the media entity, select IWC as the widget of image field.

I have update documentation that's way

add an illustration about to choose Media Library Media Modify field

Hi,

I propose a more "generic" approach here 📌 Remove the cases specific to the crop_crop effect plugin and replace them with general management of effect plugins. Needs review

DrDam → created an issue.

Did you reproduice the bug with the 2.4 or 2.x version ?

Hi,

I attache a patch which add a "flush action".

Hi,

I think I've found a solution that I think is ‘simpler’ (less intrusive and based on what the core does in generating thumbnails).

The main idea is to retrieve the code from the ImageStyleDownloadController::deliver :

    // Don't try to generate file if source is missing.
    if (!$this->sourceImageExists($image_uri, $token_is_valid)) {
      // If the image style converted the extension, it has been added to the
      // original file, resulting in filenames like image.png.jpeg. So to find
      // the actual source image, we remove the extension and check if that
      // image exists.
      $path_info = pathinfo(StreamWrapperManager::getTarget($image_uri));
      $converted_image_uri = sprintf('%s://%s%s%s', $this->streamWrapperManager->getScheme($derivative_uri), $path_info['dirname'], DIRECTORY_SEPARATOR, $path_info['filename']);
      if (!$this->sourceImageExists($converted_image_uri, $token_is_valid)) {

and inject this controle in the crop::getCropFromImageStyleId method

All right, we'll proceed as it.

DrDam → created an issue. See original summary → .

DrDam → created an issue.

@sickness29 :
In fact, it's a limitation of the Crop Entity it self.

I actually have a real use case for this type (particularly when you want to render several versions of the image via responsive).

- You can define 2 distinct image styles: "16-9-large" and "16-9-thumbnail" (both using the same "16-9" CROP-TYPE). The difference is in the dimensions displayed (one 1k px wide, the other x00 px wide).
- You can render the image in the 2 styles separately (using the image formatter or using responsives images).
- For ALL the other styles, you can choose an area of interest different to that of 16-9 CROP-TYPE (That's main adventage in frontof focal-point).
- But if your 2 images use the same type of CROP, you can no longer have 2 different aera of interest (one for each style).

The "classic method" for handling this case consists of creating a CROP-TYPE for each variant of the "same CROP-TYPE" (on for the "16-9-large" and another for "16-9-thumbnail"), and finally have a CROP-TYPE for each image style that uses a CROP.

What is the point of distinguishing the CROP-TYPE from the image style if the global solution are to have a 1-1 relation ?

DrDam → created an issue.

I understand the use-case, but I think it will be the subjet of another module, because the goal of the solution are really a "field-located-control" and all the design are made this way.

DrDam → created an issue.

fgm → credited DrDam → .

DrDam → made their first commit to this issue’s fork.

DrDam → made their first commit to this issue’s fork.