@hans2103 Have you added ".avif" to both the list of allowed file types "Legal Extensions (File Types)" and the list of allowed images "Legal Image Extensions (File Types)" in the media manager's options? And if "Check MIME Types" is switched on in the options, which is the default, have you also added "image/avif" to the list of allowed MIME types "Legal MIME Types"?

Joomla Administrator > Content > Media > Options

• Legal Extensions (File Types) => added ,avif,AVIF
• Check MIME Types = YES (by default)
• Legal Image Extensions (File Types) => added avif
• Legal MIME Types => added 'image/avif`

Tried to upload an AVIF image.
The result:

Concluding two things:

• there is no English translation for this text variable
• it is not possible to upload an avif image

The MIME type is image/heif.

For missing string issue see PR #30671.

Added MIME type image/heif. Uploading an AVIF image is not possible with the same error message as mentioned earlier

Can you post a link to the image for testing?

I've been using one of the avif images downloaded from the article mentioned in the description of this issue

• article => https://jakearchibald.com/2020/avif-has-landed/
• used image => https://jakearchibald.com/c/f1-good-a14c8cc5.avif

What happens if you switch off "Check MIME Types" in media manager options?

It's recognized as having application/octet-stream MIME type. There's PR #25351 for improving MIME detection but I don't think it's going to help in this case.

Yes, but I wanted to know what happens when the MIME type check is switched off.

It works without MIME check.

So the MIME check is the broken thing? Maybe it just can't handle that new format yet? Maybe our dependency needs an update for that?

The MIME type is determined in the MediaHelper class here:

https://github.com/joomla/joomla-cms/blob/4.0-dev/libraries/src/Helper/MediaHelper.php#L65

For images, following functions are used if available, one after the other:

• exif_imagetype
• getimagesize
• mime_content_type
• finfo_open

The availability of these functions depends on PHP version and available PHP extensions, and if avif images are included in the corresponding extensions or in case of mime_content_type in the magic file may depend on the particular PHP extension's version.

Please test PR #31233 using mimetype application/octet-stream.

PR #31233 has already been merged.
@Quy what should I change in the settings to get an .avif file being uploaded?
The mentioned error remains

I am not at a computer to double check. Add avif to filetype and image extension settings. For the mime type please add the avif file manually to the images folder and click the info icon to see its mime type value to use for the mime type setting.

Using application/octet-stream works for me.

Thanks, @brianteeman , for letting me know about this.

I imagine the problem is that Joomla doesn't support AVIF, because PHP-GD doesn't support AVIF - which is because libgd doesn't include AVIF support?

If so, I'm working on that right now. You can follow my progress (and I very much hope there will be good news soon) at libgd/libgd#557 .

Just wanted to let you know that this PR is almost out of review. I expect it to be merged soon!

And... it's merged.

Thanks @morsssss for that PR there and for keeping us up to date.

So the next step is that they make a new release, then we can maybe pull it into the CMS (if no B/C breaks).

@morsssss Could you have an eye on it and let us know here when they've made a new release? If not, it's not a problem, just let us know then someone else will watch it hopefully. But if you can: Thanks in advance, that would really be a help.

Yes - definitely!

I'm following the progress here.

GD 2.3.2 released: https://github.com/libgd/libgd/releases/tag/gd-2.3.2

on my php 7.4.9 is 2.3.0 for example

@alikon It needs to fetch gd-2.3.2 with a composer update. Could you make the PR?

i didn't think it is a composer matter
but correct me if i'm wrong ?

did you mean this one ? https://github.com/joomla/joomla-cms/blob/4.0-dev/composer.json#L83

@alikon I think so, but I might also be wrong.

TIL over the weekend: PHP core maintainers told me that PHP's version of gd diverged from libgd long ago. I looked at the source, and, sure enough, it's true. It's quite different from libgd. It's even full of PHP-specific functions like zend_error().

Reading the last couple of comments, I looked at a sample PHP version of a GD file from v7.4.0. It, too, has zend_error().

I haven't been working with PHP much for the last few years. Do you know whether the external libgd is necessary at all? I do see it in the composer file @alikon just mentioned. I just don't know how it's used.

libavif, on the other hand, should be required.

So, as far as I can tell, the next steps here are:

• propagate the new AVIF support from libgd into PHP's fork. This mostly involves gd_avif.c.
• Get PHP's getimagesize() function to recognize AVIF. The good news is that there's already a PR for that.

Just wanted to provide you all with an update.

My PR to propagate AVIF support into PHP's bundled gd library has been approved and merged. This should be included when PHP 8.1 is released in November. It'll be available in beta in July!

My followup PR to provide AVIF support in getimagesize() and imagecreatefromstring() is nearing approval as well.

So: it's good news!

@morsssss I created a package that adds support for Avif (amongst other things) to any Joomla 4 site:

https://responsive-images.dgrammatiko.dev/faq/index.html

code:
https://github.com/ttc-freebies/plugin-responsive-images/tree/4.0.0

@dgrammatiko hey, that's excellent!

You didn't need to wait for support in PHP? Do you use libgd or Imagick independently?

4.0.3 native ready for images AVIF?

4.0.3 native ready for images AVIF?

Not yet:

You can use https://responsive-images.dgrammatiko.dev though to get AVIF, WebP and srcsets for free

In any case, as far as I know, full AVIF support will be released in PHP 8.1.

And, yes, @dgrammatiko 's plugin :)

is this resolved with #35752 ??

Closing as having a pull request. Please test #41381 . Thanks in advance.