Contrib.social

Support multiple crop variants per URI and crop type

Open on Drupal.org →
Created on 18 November 2015, about 9 years ago
Updated 5 March 2024, 10 months ago

Problem/Motivation

The current crop API is limited to only support one crop definition per image URI and crop type, while the crop type is the reference from the managed types (configuration).

What possibly seems obvious is not, or at least needs to be well documented and the user need to be aware of that fact.

If the same image is reused, the same crop definitions apply for all output.
What seems valuable (such reuse of a previously defined crop type for that image) makes sense if the image is considered a single resource and the individual crops are considered a focus on THE relevant aspect.
If i alter a crop definition when reusing the image, it also affects all other usages.
(We could check image usage and warn when cropping if it is already used.)
See issue for image_widget_crop: #2617820: Warn user on image reuse →

However, if an image contains multiple objects that want to be referred and cropped individually, we can not deal with the situation. The only thing we could do is clone the original resource.

Examples:
- If a node has a gallery and we want to select multiple detail zoom crops from a total image (same document, same field, different delta)
- If a node has multiple fields and want to use different croppings of the same original (same document, different fields)
- If an image is browsed by entity browser and picked for a second time.

Proposed resolution

Crop should be clear that the current setup of the crop definitions are currently more a composite of the file entity with reference through URI.

Supporting variants can no more happen that easily through the same image style definition, because a file is only rendered and delivered once.
Instead to support variants, we need to:
- Replace the image formatter, because the image URL is different and has new context
- Provide an alternative crop schema / route to render the variants that eats entity type, entity id, field name, delta
-- Load the original image based on the placement context

I realise that with this approach we could use the URI of the image placement to save crop data.

Remaining tasks

Discuss and decide if this kind of variations should be supported.
If yes, then document how the variants would be supported.
Decide about how we will document it, and do it. ;-)

User interface changes

API changes

✨ Feature request
Status

Needs work

Version

2.0

Component

Code

Created by

🇨🇭Switzerland miro_dietiker Switzerland

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

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment over 1 year ago →
    🇫🇷France DrDam

    Hi all, just an update here.

    The module "multi_crop" is now deprecated and replace by media_contextual_crop → suite now fully Drupal 10 compatible.

    The suite are compose with 5 modules :
    - media_contextual_crop → : as the core-api module
    2 use_case modules ;
    - media_contextual_crop_embed → : for croping media in ckeditor (4 & 5)
    - media_contextual_crop_field_formatter → : for cropping in media reference fields
    2 crop plugin adapters :
    - Focal Point adapter →
    - Image Widget Crop adapter → : for cropping in media reference fields

  • Comment about 1 year ago →
    🇫🇷France DrDam

    Hi,

    I'm still working on the subject (crop on media), and I've just modified the approach of my solution.
    Until now (on version 1.x of the media_contextual_crop suite → ), I had to duplicate the image source in order to stay within the standards of image generation by ImageStyle and the Crop_API module.

    For version 2.x of the media_contextual_crop suite → (nearly released), I'd like to do away with the need to duplicate sources, and to do so I need to store a context in the CROP entity itself.
    The patch I'm proposing goes in this direction.

    The "retrieval" part of the context ( in the ``findCrop`` method) still needs to be fine-tuned.

  • Comment 11 months ago →
    🇫🇷France DrDam

    Just an update of the patch, in order to fix conflict between overrided and non-overided usages

  • Comment 10 months ago →
    🇫🇷France DrDam

    @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)

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024