Your opinion wanted: using different images

I posted this enhancement proposal to github a few days ago, but I have no takers on the discussion. So I'm advertising for an opinion. It's specifically around the add-on

I think I explain the case well there.

tl;dr: I want a news item (or any object) to have multiple images, but I want to use named scales to accomplish it - even though it's clearly a hack and not what named scales was designed for.

I don't want to add a bunch of image file fields to a news item to accomplish this. We've already done that, and it's very time consuming for the plone user. However, it seems to be the correct approach from a software engineering point of view.

1 Like

I can see the use for this (especially since I just had a case where the image we want to share on social media should not be the same as the 'lead image'.

So I ended up with another field and a bit of hacking.

That said: ImageCropping breaks restAPI (fullobject) so this is keeping me from using it on newer sites.

We kind of had the same architectural issue when we started to build a new image cropping solution for Volto based on GitHub - DominicTobias/react-image-crop: A responsive image cropping tool for React.

We discussed using scales for this or having two fields (one for the original image and one for the cropped image). We ended up with a simple solution where we crop the image on upload and store it in the regular single field.

If we need multiple versions for different social media channels we actually use kitconcept.seo. I just realized that we do not mention those additional fields in the README. Will change that.

Quoting from the Github issue:

A news item featured image is a different image than the image shared on twitter - not just a cropped version of the original featured image.

This for me sounds like a different image and maybe @tisto’s solution with a dedicated open graph image is the way to go.

A news item featured image is a different image when viewed on mobile, or changes dynamically with viewport changes

That is a combination of responsive images (size and format based on client hints) and art direction (showing a headshot on mobile while serving a landscape banner image on larger viewport sizes). This is something that already can be done with p.a.imagecropping. Here we can maybe enhance it by providing the upload of a high resolution crop, but the content of the image should be the same. Also, p.a.imagecropping forces the custom cropped scales to have exactly the dimensions, whereas the automatic scales use the scale dimensions as max boundaries. It would be great if custom cropped scales would fit into the constraints (so one side must match), but are not forced to have the exact aspect ratio.

A news item's listing image (teaser image) is different than a cropped version of the featured image.

Isn’t that possible right now? If you need more versions/scales, those can be added in the image control panel.

But as @espenmn mentioned, it currently breaks plone.restapi and is therefor “useless” in a current setup.

Just one other remark. When tried to introduce image cropping across our customer site it turned out that not all images can and should be cropped. Some images might use a different aspect ratio and this highly depends on your design and requirements. Therefore you can't just add image cropping functionality to all images (at least not with the same image cropping default set, like aspect ratio).

We actually failed so far to establish an aspect ratio standard in our client projects because they all differ. We would love to provide an open-source general-purpose solution like for Volto in the future. Though the ugly truth is that modern image-heavy websites with different image aspect ratios, social media distribution channels, mobile-friendly delivery methods (hello srcsets) are pretty complex and it is a challenge for a CMS to come up with an easy to use general-purpose solution for this. With Plone 6 / Volto we have the chance to maybe come up with a good solution once we gained more experience in our client projects. Though, this will for sure be a challenge.

Maybe our experiences and lessons learned can help a bit here...

A bit off topic, but since it is possible to turn on imagecropping for only some sizes, it is possible to combine 'the best of both' here.

What I do is

  1. (I usually) have a bit of Image Sizes
  2. I make only a few of them croppable
  3. In my views I add a setting for the image that I use for x- and y-axis placement ( object-position (or focal point as others might call it)
  4. If one combine that with max and min sizes and @media CSS it is possible to get most things right (?)

With a little explanation, my customers understands this

I checked this yesterday and for me it works: Imagecropping breaks resapi search (full objects) · Issue #104 · collective/ · GitHub

@espenmn, can you please check if it works for you as well?

@tmassman You seem like the closest to a dissenting view. I appreciate it.

I think you may have misunderstood my use cases. Serving a different image to twitter than what's displayed on the site is a good use of open graph, but this only covers when and where the URL of the image would be used (how to add it to the template), and not necessarily what resource that URL provides (where it points to).

Taking a featured / original image, but serving a cropped version of that image is supported, useful, and used, but is not the feature I am proposing.

No, it's not possible. Each version / scale is a transformation of the original featured image. It cannot be a new image or a different image. You cannot have a featured image of The Earth and a version / scale of that image being a human smiling.

"But this isn't want image scaling / cropping is designed to do". I totally agree, and that's the cornerstone of my own counterargument. This feels like I'm trying to break single-mindedness, SOLID design principles regarding image scales and the image cropper functionality.

We can accomplish this (and do) by having two fields on a content type schema. Both are type 'ImageFile'. One is 'featured image' and one is 'teaser image'. The teaser is displayed in listings and featured when viewing the object. When the teaser image is absent, we fall back onto image scales. Logic is provided in the view or template (preferably in the view).

However, from the view of a user, it would be very easy to 'upload' a different picture into a 'scale' of an image. I don't have to deal with an extra field on the schema. If the user has a firm understanding on how image scales work and are to be used, they know they are hacking the functionality of image scales.

Yes, this then changes the vocabulary from 'image scales' to 'image versions'. (thank you)

The advantage gained is a single place to control all versions of the "image representing the object". Depending on the context the object is used (default view, listing, mobile, twitter, facebook) it will show a different image version. We extend the functionality of 'image version' beyond just scaling and cropping by giving the user the ability to replace the image completely.

I am honestly on the fence here.

I feel this is a complete abuse of and making developing plone harder.
I also feel like this is a feature improvement that makes using plone better.

Creating a new add-on '' (for example) to provide only the functionality to replace an image scale with a new uploaded image bothers me (a little) because I don't know how it would behave with also installed.

It also seems like a very clean user experience if the '@@croppingeditor' simply gains an 'upload' button.

Related Docs:

Hey, here is a discussion too. See my comment at GitHub.

Essence: Uploading a complete different image as scale is basically an evil idea. Don't do this.

If you really want to have this, implementing it as an addon '' is probably the best way. If you need (neutral) UI hooks in to integrate it, PRs are welcome. But I give veto to merge this feature in

1 Like