🇫🇷France @DrDam

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.

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

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

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

Replace drupal_get_path to make it 9.3.x competent →

But it seems there is something "stange", $block["layout_builder_browser_data"]->image_path don't take the change...

@woprr, @miro_dietiker :

Stop me if I say something stupid. It seems, the subject of the issue concerns two different aspects.

1- The "re-usage" of image (I.E. using media entities reference fields instead of image fields.
In reality, the point should cover all cases where the image file is carried by an "intermediate entity", not just media.
This case have it's own issue #2983622 → , and the media_contextual_crop suite → address only the "media case".

2- The couple "Image-Crop Type" which are more restrictive than the "core Image-style" couple (in the image-styling process).
This case (I think it's the original subject of the issue) are if you use a CropType (ex : 16:9) in multiple styles ( large_16_9 , tiny_16_9), the implementation of the CROP Entity DOES NOT ALLOW to define two "crop settings" for the same image (one for each style). Maybe this is a "non-use-case", so nothing to say about.

PS :In order to keep this debate cleaner, I propose to move my comments about the media_contextual_crop suite to #2983622 (if @woprr re-open it)

DrDam → created an issue.

maybe wait maybe wait the #2061377 ✨ Allow image style to be selected in Text Editor's image dialog Needs work

maybe wait the #2061377 ✨ Allow image style to be selected in Text Editor's image dialog Needs work

Sources :

Migration of manualCrop : https://www.drupal.org/project/manualcrop/issues/3383416 📌 Migration Needs review

Hi,

just an tiny proposal : the drush command may take a parameter/option as a key-map to manage style_name changes

Hi,

What's wrong with #8 proposal ?

I'm agreed with the fact we don't need to have tabs in the modal. Those will be independent operation, so with a correct title on the modal you can check what you are doing

off-topic : You can now use standard image_formater in the media

You are right

Not exactly your proposal, but it will work as well

It appears that Image Widget Crop does not offer this feature natively.

I move the Feature Request to them.

The field "field_imatge_media" must be a "Media with contextual modifications" not a "Entity reference" in order to make "media_library_extra" widget working well.

The issue you mention is mine in order to make media_library_media_modify working with IWC/FocalPoint

Remove custom formater, no more needed since 2.0.6

right, only "image media" are impacted

If the problem are on the 3 media reference fields (Adjunts, Video, Imatge media), it's because you are using an "entity reference" field when it should be using a "Media with contextual modifications" field.

You can make the migration with a drush command : drush media_library_media_modify:migrate node [field_name]

I think it's something in node / entity / media configuration.

Did you have an entity_browser / inline_entity_form ? or something like that ? something it can override the media library ?

can you make some screen-shots of node field_list and node form_mode ?

If you have some screen-shot of node field_list & form_mode, at first

Sorry, I don't know

There is some mess somewhere but I do not find where

This is not the correct modal that is opened when you "edit"/"overwritten" the media from the node reference field.

can you tel me all version of all modules ? (media contextual crop, media_library_media_modify)

Can you describe the whole stack (fields, widget, formater) for the node and the media ?

The modal that is displayed here is not the expected one

In both, the node edit form and the image in media edit form:
$build_info['form_id'] = "media_image_edit_form"

We have a anomaly here.

can send me a screen-shoot of the modal open in the node-form ?

The message "This crop definition affects non-overrided usages of this image" will be show when you edit the crop directly in the media (admin/content/media => /media/XX/edit )

When you "edit" (overwritten) the media from the reference field, you will have "This crop definition affects ONLY this contextual usage of this image"

if it's not the case, can you send me the value of $build_info['form_id'] in the media_contextual_crop_iwc_adapter_widget_after_build

Thank you for your confidence in this solution.

Just remain aware that this is first and foremost a PoC and a demonstrator that the need exists and that it is not just “a whim”.

I regularly update all the modules in the collection, so I encourage you to regularly test and check that I don't break anything.

Thanks again for the trust.

For #24 :
- because when I'm studying your issue, I have realized we don't need this formatter, so you can just use "native image" formater (in the media).

If you use a "no crop" style for this display, there should be no problem ?
Where? I get lost with so many places to configure. I hope someone will make a module to configure all for one image XDD

In the ImageWidgetCrop widget settings
For the "Previsualitza l'estil d'imatge"/"Preview image style", can you test a "no-crop" image style ("crop thumbnail" for exemple)

Ok, it seems the "Previsualitza l'estil d'imatge"/"Preview image style" uses the "default" crop of the media, but the anomaly should only exist in the Back-office, the "front image" are croped are correct (can you confirm ?)

If you use a "no crop" style for this display, there should be no problem ?

If the issue are the "Preview image style" I'll create a "clean issue" for that.

normally you should have a different message between the modal in the field and the media form

we will try something else ...

Maybe I'm using too many hamers...

function media_contextual_crop_iwc_adapter_widget_after_build($form, FormStateInterface $form_state) {

  $build_info = $form_state->getBuildInfo();
  $is_overriding_context = $build_info['form_id'] === 'override_entity_form';
=> dsm($build_info['form_id']);
  foreach ($form as $delta => $elem) {

=> if(!is_array($elem)) {
=>   dsm('not array');
=>   dsm($elem);
=> }

    // Ensure working on the right stuff.
    if(isset($elem['image_crop']) && is_array($elem['image_crop'])) {

it's a custom back-office theme ?

I don't understand under what conditions $elem['image_crop'] can be a TranslatableMarkup object (line 68)

I can imagin that $elem['image_crop']['crop_reuse'] can be a TranslatableMarkup object, but in this case the error will be several line after...

Merged

Thanks for the MR, I really need reviews on the image_responsive feature.

Thanks for the tweet too.

You can make these on the 2.0.2 version

Can you put some dsm in the media_contextual_crop_iwc_adapter_widget_after_build function, and send me results ?

for exemple (on dev version) :

function media_contextual_crop_iwc_adapter_widget_after_build($form, FormStateInterface $form_state) {

  $build_info = $form_state->getBuildInfo();
  $is_overriding_context = $build_info['form_id'] === 'override_entity_form';
=> dsm($build_info);
  foreach ($form as $delta => $elem) {

=> if(isset($elem['image_crop'])) {
=> dsm($elem['image_crop']);
=> }

    // Ensure working on the right stuff.
    if(isset($elem['image_crop']) && is_array($elem['image_crop'])) {

Hi,

(I have almost finish the site migration!!!)

Great news !

To be honest, I haven't done any testing about translation, just assuming all module do it correctly...

Just a few check question (classical switch-off-and-on ) :
- In the node are you sure using a "Media with contextual modifications" field for media reference (instead of an entity reference)
- In the media image, are you sure using the "ImageWidget Crop" widget for the image field, and set the corrects CROPs (how many)
- Can you details the version of CROP and Image widget crop module (I assume you use the latest sable release for "media_contextual_crop" collection)
- if you using a multilanguage site : did you activate translation on the content ? on the media ?
- did you have the error when creating a new media from a new image ? (from the node, or from media lib)

Thanks for your time and your support

For the "file" parameters in the request object, it is to prevent the "PathProcessorFiles" from taking charge of the file downloading.
It seems I still don't understand the black magic hiding in pathprocessors ...

Lets say you have all information needed, so you have a Crop entity, you have all width, height, x, y, context info, you have the image uri etc. Which is the exact code to programmatically render a Crop?

How it's work

something like that :

$image_style = ImageStyle::load('my_style');

$original_image_uri = "public://path/to/source/file.jpg"; // public for the exemple
$derivative_uri =  "public://path/to/the/future/derivative/file.png"; // may be generated by something like ImageStyle::buildUri()

$image_style->createDerivative($original_image_uri, $derivative_uri);

If your image style use a crop effect, the crop effect will check in all crop entities which entity have as the couple "crop type / original_image_uri".

=> so no context effect here, if you test that without my mess, you cannot apply a context on the crop process, it will use the first couple "crop type / original_image_uri" found.

My first approach : create copies of original files, and crop on it.

My first approach of the multiple crop issue was to "troll" this association, by "creating copies" of the original_image in the file system (1 copy by context) so for the CROP module, there still have one unique couple "crop type / image uri" , except the image_uri are no longer the "source image" (just a copy)

So in term of code, juste have a "formater" or "altering the image formater" will create a "copy" of the image source and create a CROP entity with contextual setting targeting this copy.

You can check 1.x branch of the collection (or multi_crop module) for more details.
have found this approach was a mess for keeping the file system & the crop entity table "clean" (when the image will change in the media, when media are deleted, or the image_style edited...)

The second approach : without copies by new controller and CROP_ID injection

for this approach, I have add a patch to the CROP process :

public static function findCrop($uri, $type) {
-    return \Drupal::entityTypeManager()->getStorage('crop')->getCrop($uri, $type);
+    $contextual_crop = \Drupal::request()->query->get('contextual_crop');
+
+    if($contextual_crop) {
+      return \Drupal::entityTypeManager()->getStorage('crop')->load($contextual_crop);
+    }
+    else {
+      return \Drupal::entityTypeManager()->getStorage('crop')->getCrop($uri, $type);
+    }
}

If there is a "contextual_crop" (I.E. a CROP_id) in the request, we just load it, instead searching for a "crop type / image uri" couple.

The "cost" of that, are I cannot use the "standard imageDeliver method, because I need the "crop_id" in a parameters (not in the query), so it's a new route. In order to limit security issues, I have copy the whole "imageDeliver" process (routing, pathprocessing & controller).

I'm always open to new implementation proposal. I'm in love with this problem, not with my solution...

If I test a "standard image field" set to private files, Yes "standard CROP" work (you can test with a "basic field image with crop", in cas of some file permission problem)

this seems coherent, because for Drupal "file mediation" there is no differencies between public/private or any other "file stream scheme" (ex : S3 file system).

So this should work, and I making it working on my local (config as you describe it) with 2.0.x need a whole cache flush.

Pushed in 2.0.x,

just a side effect of the correction to #3416473.
For private resources, we must add a "file" parameter in the request.

It is reproducible and it never was tested...

I'll check the pathprocessor

Released in 2.0.4

In fact, you are right, if I have the context, the file are not mandatory...

Did you have any error in drupal watchdog ?

The URL in 03 are correct, so can you make a dsm for parameters of MediaContextualCropService::createContextualizedDerivativePath

OK,

The scenario you want for the use case :
Step 1 : Insert Media in content
Step 2 : crop the media "what ever you want"
Step 3 : the image are display "as she is croped"

In fact, you don't even care about the type of crop : "display image as the user crop her"

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.

If I understood correctly, you use CROP to impose some "image formats" (and the user is free to select the area), but the user "in addition" has the ability to choose which format he wants. want for its image (from the node form)?

Something like this module → but applied to media with crop ?