Cropped images are not shown / generated

Yes, If I upload a new image to the Media library with a simple filename like 'Naamloos.png' and use that, still the same problem.
Broken image src = https://mywebsite.com/sites/default/files/contextual/styles/crop_hero/public/uploads/Naamloos.png?itok=zbqO4E0b
manually opening that in browser redirects to: https://mywebsite.com/nl/sites/default/files/contextual/styles/crop_hero/public/uploads?itok=zbqO4E0b but thats a 404 page not found. No image is generated. There is a sites/default/files/contextual folder now (from the previous test where I forced the parameters inside the Controller) but its empty.

Yes, it is a multilingual website.

I can confirm that the Image URLs I pasted here are real and unmodified exept for the 'mywebsite.com' part.
If you check to proposed resolution part of the issue, you will see that I already noticed that 'file' and 'contextual_crop' query parameters are missing inside the process() function, and that if I manually set something there for those parameters, then everything works.
So the problem is that the 'file' and 'contextual_crop' parameters are missing inside the process() function. They are available inside the processInbound() function, but they are missing from the process() function of the Controller.

I think images might make it clearer.

Extra screenshots.

Here you go.

More info from that first request object if you need it.

Here you go.

I refreshed the page, and then you see the expected number of output / dpms. That is probably less confusing.

Here you go.

Yes, looks the same to me. Where might the URL generation be wrong ? any way to trouble shoot that further ?

Testing around, I find this. Will try to investigate more.

It seems that inside generateContextualizedImage() function, $plugin->saveCrop returns NULL.

I will in a moment. I am now debugging media_contextual_crop_iwc_adapter/src/Plugin/MediaContextualCrop/ImageWidgetCrop.php.
I can see there that $croptype gets the value 'hero' (which is indeed the applied crop style).
But inside $crop_settings['crop_wrapper'], there is only the '16_9' crop type, which is the first of the available crop types, but not the correct one.
So the code never passes this part:

      if ($croptype != $crop_type) {
        continue;
      }

because 'hero' is never equal to '16_9'.
That causes the code to never retrieve or create a crop, and thus returning NULL instead of a crop ID.

EDIT: I see now that we were looking at the same code at the same time, I just didn't realise it.

added screenshot with arrow in image 1 for the part that we want to reach but never reach.

No problem at all, I am actually glad I can be of assistance and that you are willing to help troubleshoot this.

And here is the more detailed output from dpm($variables['item']->image_crop);
So yes, that has the wrong crop type inside crop_wrapper or its at least missing the correct one

Here you go. I had to adjust the crop then resave my node to trigger that function.

I offer you my apologies, It seems that I have in all that testing switched from applying a hero crop to actually applying a 16_9 crop.
So the crop_applied = 1 is correct for the 16_9 crop at the moment. Still no working image unfortunatly.

I can edit the image, set a crop, save the page.
The image is not shown as we already saw in numerous previous screenshots.
I can then edit the page and the image again, and I can see while editing that the crop is in exactly the same place as when I previously saved it. So on the Edit side, eveything works ?

But on the page itself, the image is not working because in media_contextual_crop_iwc_adapter/src/Plugin/MediaContextualCrop/ImageWidgetCrop.php in saveCrop it compare $croptype ('hero') to $crop_type (16_9);
Maybe because of some old crop data or something ? Can I clear all existing crops somehow to test this ?

I found the reason why it did not work, where the 'hero' comes from and so also how to fix it.
I am sorry for your time. The frustrating thing about current implementation of cropping is that while you can select multiple possible cropping types on the Form Display, you are still required to set a single crop image style in the Manage display settings of the 'Contextual Crop Image' widget.
And apparently the crop I was trying to apply did not match the crop image style of the Manage display settings of the 'Contextual Crop Image' widget.
So everything works now, cropped image is generated and visible. A thousand times thank you for your time.

I have a way around this problem in other projects, I just removed it because it did no longer apply for Drupal 10. But I will try to refactor it for D10.
- Create a new 'Automatic crop' image style. It is empty without any operations.
- use preprocessing for this image style, get the crop type and hardwire a corresponding crop image style for each crop type
- apply that image style. this means that applying 'automatic_crop' image style for a 16_9 crop will actually apply the '16_9_crop' image style, while applying 'automatic_crop' image style for a 'hero' crop will actually apply the 'hero_crop' image style.

Hi DrDam: Please look at the screenshot about what the use case is:
- User can apply a 16:9 crop
- OR user can apply a 16:9 small image crop
- OR user can apply a 80:39 crop
- OR user can apply a Hero crop
- OR user can apply a square crop
BUT
only when he applies the 16:9 crop it will work, because that is the image style that is selected for the Contextual Crop Image in Manage Display. It is that fact that you have to choose an image style there that screws up the possibility of giving the user the choice of what crop type he applies to the image. It would be better if there was no image style setting there and that the code would automatically figure it out, like: Is the applied crop a 16_9 crop, then get image style that uses 16_9 crop. If the applied crop is a hero crop, then get the image style that uses the hero crop. The manual option to set a fixed image style there should be removed in favor of code that auto detects and selects the correct image style based on the selected crop.

Hi, what I mean is: make the screenshot 'multiple possible crops.png' work, so user can choose any of the crops on the left side of that screenshot. But thats not possible because of screenshot 'manage display - set contextual crop image style.png' because we are forced to set a crop image style there. In this example, the 'Crop 16:9' image style is selected.

Only if the user chooses to use the 16:9 crop it will work because of that image style.
But if the user chooses to use any other crop (see the left side with possible crop options available to him), the image will be broken because it does not match that 'Crop 16:9' image style.

Therefor, I would like that that the manage display - Contextual Crop Image - Image style option is removed completely. So we dont need to set it. Instead the code from the Contextual Crop Image widget could figer out which image style to apply based on the selected crop type.

Yes, I think thats what I mean :-). So If the user crops a Media with a 1:1 crop or a 16:9 crop or a 4:3 crop, It will work and the crop will be generated and displayed without me having to bother to set an image style in the Manage Display.
Of course, If I have a 1:1 crop type, a 1:1 crop image style needs to exist. And if I have a 16:9 crop type, a 16:9 image style needs to exist. But I should not have to explicitly set a crop image style in Manage Display. It should automatically choose the correct one.

Sorry to bother again, Its not working on a fresh try :-(

I tried to crop from a clean start, So I deleted all existing crops:
drush php-eval '$crops = \Drupal::entityTypeManager()->getStorage("crop")->loadMultiple(); foreach ($crops as $crop) { $crop->delete(); }'

I went to sites/default/files and deleted all cropped and crop duplicate images I could find.

I deleted the existing image blocks. I added 2 image blocks next to each other, both showing the same Media image, no cropping applied.
See 01 - before cropping.png

I then edited image 1 and added cropping to that image, see:
02 - cropping only 1 image.png

The cropped image is broken unfortunatly, see image:
03 - broken image after cropping.png

But, the image src now does contain a contextual id I think (289): https://mywebsite.com/sites/default/files/contextual/styles/crop_16_9/28...

Also, it passes the if ($croptype != $crop_type) { statement (because '16_9' == '16_9') which is also good.
A Crop entity is created and the function does return a valid crop ID.

I can DPM the Crop entity, see 04 - crop entity.png

So I think more is working than at the beginning of this issue, but somehow still no working image on this fresh try. Like in the description of this issue, 'file' and 'contextual_crop' parameters are still missing from the $request->query inside media_contextual_crop/src/Controller/ContextualImageStyleDownloadController.php

I will look further into this tomorrow if I find the time, new urgent stuff for other clients have came up.

But in the meantime I created a fix for the process function for when the necessary request query parameters are missing:

  public function process(Request $request, $context, ImageStyleInterface $image_style, $scheme) {

    // Set 'contextual_crop' parameter if its missing.
    if (is_null($request->query->get('contextual_crop')) && is_numeric($context)) {
      $request->query->set('contextual_crop', $context);
    }

    // Set 'file' parameter if its missing.
    if (is_null($request->query->get('file')) && is_numeric($context)) {
      // Load Crop entity.
      $crop = \Drupal::service('entity_type.manager')->getStorage('crop')->load($context);
      // Get value for the file parameter.
      $crop_uri = $crop->uri->value;
      $crop_uri = str_replace($scheme . '://', '', $crop_uri);
      $request->query->set('file', $crop_uri);
    }
    
    $target = $request->query->get('file');
    ...

It might not be pretty code but it's working for now with this code so I can focus on other urgent assignments.
I do hope to find the actual cause and I do hope I find the time to check MediaContextualCropService::createContextualizedDerivativePath for you.
Will report back if I do.