tests/Codeception/api/com_media/MediaCest.php needs to be updated and fails at this point.

Hey, @obuisard I can't reply on #38722 as Nik has blocked me so I'll write my comment here:

• when I asked you to resurrect this PR I meant to fork it and patch the things that other were asking me to change in the original PR and also fix the failing tests
• • #36552 (review)
• • #36552 (review)
• • #36552 (comment)
• About the other PR: the approach on that PR is wrong in the sense that you need a data structure that holds all related info per supported media file (mime type, has preview, allows edit, etc). If the project ends up with different inputs for each of all these required data you end up with countless inputs which makes the app really hard to configure and finally use it to its full extend. Mind that since Media manager supports audio and video and other types at some point you might want to provide edit for those (I had a trim plugin for audio and video). Also one more thing: uploads should only allowed if there is a known and matching mime type, the idea that in 2022 people rely on extensions for uploads is a huge security problem. A simple composer require is all it takes: https://packagist.org/packages/league/mime-type-detection to start making things right...

Thank you Dimitris @dgrammatiko. I did address the first review, fixed formatting and tested the code successfully.

As far as the tests are concerned, a solution would be to remove testUpdateFileWithoutAdapter all together, but I would appreciate someone's expertise on this.

a solution would be to remove testUpdateFileWithoutAdapter all together,

@laoneo could you advise here?

Removing the test is a bad idea. Better to set the default to 0, so no thumbs will be generated and the admin has to activate it. If it is on by default, then after the update all thumbnails are generated without notice, which can lead to resource issues on large sites.

I have modified the code to make the thumbnail creation 0 by default. It does solve issues with tests. Thank you @laoneo for the suggestion.

I have tested this item ✅ successfully on 53bc63a

Everything looks good after applying the PR.

I have tested this item ✅ successfully on 53bc63a

RTC

First comment on this PR was edited by the bot, removing information.
Thank you to @dgrammatiko for this work, it's a big step into improving the performance of the media manager.
For information, turning on thumbnails can be found in the Filesystem 'Local' plugin.
Joomla 4 documentation found at https://docs.joomla.org/Chunk4x:Extensions_Plugin_Manager_Edit_FileSystem_Group

Back to pending because changes were made and more changes were requested.

Troy @N6REJ and Jacob @jwaisner, would you mind re-testing this so we can merge it? Thank you so much!

I have tested this item ✅ successfully on d82abd9

Everything retested well. No issues.

I have tested this item ? unsuccessfully on d82abd9

in my test the images were already thumbnailed without the PR. This was " The currently installed Joomla! version is "‎4.3.0-dev"‎4.3.0-dev"
with the latest composer & npm.
plugin setting did not exist w/o the pr as expected.
Media manager image Without PR..

image with pr

original image

in my test the images were already thumbnailed without the PR.

That's strange. The thumbnails created with the PR should be 200x200.

@obuisard what @N6REJ is showcasing is the SIZE of the container DIV, not the size of the image. To get the size of the image open the browser tools, select the image in the elements tab and in the console type $0.naturalWidth (or naturalHeight for the height). False alarm...

@obuisard what @N6REJ is showcasing is the SIZE of the container DIV, not the size of the image. To get the size of the image open the browser tools, select the image in the elements tab and in the console type $0.naturalWidth (or naturalHeight for the height). False alarm...

Oh good catch Dimitris @dgrammatiko! @N6REJ can you double-check? Thank you!

Blurry quality:

Before PR:

After PR:

Thank you, Troy @N6REJ for reporting those issues.
The image quality and handling of transparency for GIFs is unrelated to this PR, but improvements need to be made to the image library itself. Something for another PR...

I have tested this item ✅ successfully on d82abd9

retested as instructed.

A big thank you to Dimitris @dgrammatiko and the testers !

Documentation added ✔️

@obuisard I haven't checked but is the thumbnails functionality bypasses the svg files? If not it needs to do so, the thumbs helper expects only files that the Image class can handle. I'll try to check the next days if I get some free time

@obuisard I haven't checked but is the thumbnails functionality bypasses the svg files? If not it needs to do so, the thumbs helper expects only files that the Image class can handle. I'll try to check the next days if I get some free time

@dgrammatiko I have checked SVG and image thumbnail creation and both work well together. The image.php file specifies which image file formats can be treated by the GD library .

it's sad that we are using GD instead of imagemagick.

it's sad that we are using GD instead of imagemagick.

I know, but GD is more widely installed than imagick. It would be great to offer the use of either one of those graphic libraries in Joomla.

You'll be surprised but GD (PHP 8.1+) is (median) faster than imagick. How do I know? I keep testing these for responsive-images

@dgrammatiko faster but I thought imagick quality was far higher?