Webp image derivatives are not deleted when normal image derivatives are being flushed

Switching status to needs review, I provided the possible solution for this issue , as you can see into the Merge request , this provides a new submodule `imageapi_optimize_webp_crop`, so , to test this , go into the merge request, extract the patch from it , apply it into your code and enable the new submodule.

Why a submodule,? well when the core issues that it's related to this is done , you could easily remove this from the code base .

@rigoucr I would consider removing the reference to Drupal 8 compatibility in the module (if you choose to keep it). I am not sure if the submodule was intended to be kept permanently or if it was for easy testing but it seems like this one hook could be placed into the module itself? Looking at the code it looks like we have a "crop" module that has a "crop" entity and when the crop entity is updated the image style isn't flushed?

Hi @ccjjmartin thank you for your feedback, I did it in that way because I thought that in that will be easier to remove in the future (this is a tmp solution for the real issue ) , but you made me think about about it and I'm changing the approach , I'm moving the code into the main .module file , that will be easier for the maintainer to remove this code later when is not longer need it .

And to answer your question , yes , the image styles are not being flushed when the crop entity gets updated .

Hi @rigoucr, I got this error when I updated a focal point.

Looking at the image styles, I saw that one of them didn't use any image optimization pipeline. Logically, this shouldn't be a problem since it's optional as explained in the description under the field: "Optionally select an Image Optimization pipeline which will be applied after all effects in this image style".

So looking at the code I saw that it could be fixed quickly just by adding a validation to check if $pipeline is empty or not just before this line:
$processors = $pipeline->getProcessors();

What do you think?

Crop::postSave doesn't always flush image styles:

/**
 * {@inheritdoc}
 */
public function postSave(EntityStorageInterface $storage, $update = TRUE) {
  parent::postSave($storage, $update);
  // If you are manually generating your image derivatives instead of waiting
  // for them to be generated on the fly, because you are using a cloud
  // storage service (like S3), then you may not want your image derivatives
  // to be flushed. If they are you could end up serving 404s during the time
  // between the crop entity being saved and the image derivative being
  // manually generated and pushed to your cloud storage service. In that
  // case, set this configuration variable to false.
  $flush_derivative_images = \Drupal::config('crop.settings')->get('flush_derivative_images');
  if ($flush_derivative_images) {
    image_path_flush($this->uri->value);
  }
}

Instead of duplicating their logic I propose hooking into the general hook_image_style_flush instead. Doing it that way would also fix other potential issues when flushing image styles in other ways, like through drush image:flush. I'll try that out now.

Works perfectly! I also fixed the issue that was mentioned in #6.

This seems to be a duplicate of 🐛 WebP images are not regenerated when using image_widget_crop RTBC . To be honest, the fix there is a lot simpler and more performant, so I think we should close this in favour of that one.