Hi Lefteris,
I am currently testing J5 on our sites and found some odd behavior with the Econa image cropping field (we use it for creating a 16:9 feature image for all of our content).
In plugins/fields/econa/src/Field/EconaField.php in the getImages() method it appears to me that the logic for $previewImage and $cropperImage is not thought through for small preview sizes.
We have a $sizes array of [1000, 600, 400, 300, 200, 80] and this is resulting in the following return values:
$previewImage = /images/econa/feature-image-landscape/51426/80/tb-0924-p39_fig1.jpeg?t=1725521510
$cropperImage = /images/econa/feature-image-landscape/51426/tb-0924-p39_fig1.jpeg?t=1725521510
This means when we open the article and view the econa cropper field we see an 80px preview version of the file which just looks like a blob. if we click edit we see the expected 1000px cropper image but the preview at 80px size is not informative.
I assume you are doing this to prevent displaying an enormous preview image but maybe the $previewImage size should be chosen from the sizes value closest to the enclosing div's size of 600px (from the .econa-container class).
i wrote a little snippet and tested this thinking -- it works well for our use case. i'm sure the block could be tightened up but it was tested and works with size arrays with values over 600, straddling 600 and under 600. here is the snippet from
/*
* find largest size <= 600 or use last size if not found
*/
$validSizes = array_filter($sizes, function ($k) {
return $k <= 600;
});
if (!empty($validSizes)) {
$previewSize = max($validSizes);
} else {
$previewSize = end($sizes);
}
$previewImage = Uri::root(true) . '/' . $this->value['path'] . '/' . $previewSize . '/' . $this->value['filename'] . '.' . $this->value['extension'] . '?t=' . time();
Let me know if I misunderstood the code here but for me this matches more properly the behavior in J4 while using the new J5 features and not showing an 80px thumbnail as a 600px preview.
Thank you,
Oliver Rockwell