#1245 Posted in ‘Econa’

Latest post by Lefteris Kavadas on Tuesday, 10 September 2024 14:05 EEST

Oliver Rockwell

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

Lefteris Kavadas

Hi Oliver,

I never could imagine that a 80 pixels wide image could be used in a website, but I completely understand this request. The truth is that I had (incorrectly) assumed that the last image size will be the largest one (based on the default sizes).

So my intention was to display the largest image there. I will update the code so it detects the size that is close to 600 pixels. 

Until then you can keep using the code you have added or simply change image sizes order in the custom field options so 600 is the last one.

Please let me know if you have any questions or suggestions.

 

Regards

Oliver Rockwell

Hi Lefteris,

That's funny.  I assumed you were specifically taking the smallest image because of some outlier case with a huge image breaking the preview page.  I first changed the call 'end($sizes)' to 'max($sizes)' but then realized if I did that than $cropperImage and $previewImage were effectively identical since $previewImage was being generated from the max size during the upgrade from v1 to v2. 

I guess my question now is do you really need both a cropper and preview version when the cropper version would probably work in both cases?

I actually want to remove some of our no longer used sizes because we now use Cloudinary for dynamic resizing and just need our largest size -- Econa is still great for generating the core 16:9 feature image.  Do you have any advice on doing this?  I'm worried that removing legacy sizes may cause older fields to misbehave.  I obviously plan on thoroughly testing this beforehand but thought you might have some warnings or suggestions.

Thanks for the quick response.

Oliver

Lefteris Kavadas

Hi Oliver,

Preview Image and cropper image are not the same. We introduced watermark functionality in v2 and that's why we need the "clean" (without the watermark) cropper image. This allows users to use the switch to toggle watermark without having to upload again the image.
My initial thought was to keep the original image (before any cropping) but I decided that this feature will add no significant value to the extension.

Regarding the image sizes, you can delete those you don't need in the field options but the files will remain. You have to do this manually or write a script (since you are familiar with coding). If you need help with the script I would be more than happy to help.
Note that in v2 we have added a CLI command for upgrading the legacy v1 custom field values to the new v2 custom field value format. You can check the code there as a starting point.

Finally, I was also thinking to add support for services like Cloudinary or Cloudflare images to Econa. Any ideas or suggestions are welcome.

Regards

 

 

 

 

 

Oliver Rockwell

Hi Lefteris,

I actually started building out a quick console plugin to upgrade the images and when testing the discover install realized there was already an 'econa:upgrade' console plugin.  mine was almost identical to yours which confused me for a bit.  I've run it on our J5 test site and works as expected.

i'll play with removing the old sizes and let you know if there are any issues.  i'll also look into a console plugin to remove unneeded sizes and possibly adding new sizes to legacy content if that comes up.

I'm happy to discuss and share code as to how we have integrated Cloudinary into our Joomla sites and use it with Econa.  We've been using Cloudinary for almost 5 years now and are very happy with it but do find it more efficient in terms of cost and transformations to bypass the API for generating image URLs.  We've built out some Joomla libraries to handle this.  Let's have a private discussion about this if you're interested.

Oliver

 

Lefteris Kavadas

Hi Oliver,

If there is any kind of integration with a third party service that might be useful, I would be more than happy to add it to Econa. 

Also feel free to contact me if you face any issues or you need any help with the console plugin.

Regards

Note: An active subscription is required in order to get support for our paid extensions. For our free extensions, if you don't have an account, register and then submit your support request.  In case you just want to ask a question, you can also use the contact form .

Firecoders
Are you using our extensions? Please post a review at the Joomla extensions directory!
Post a review