Make WordPress Core

Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#53022 closed defect (bug) (fixed)

List the supported file types for the active image editor

Reported by: desrosj's profile desrosj Owned by: desrosj's profile desrosj
Milestone: 5.8 Priority: normal
Severity: normal Version:
Component: Site Health Keywords: has-patch commit needs-codex
Focuses: Cc:

Description (last modified by desrosj)

I was doing some testing related to #35725 to see whether WebP was supported on various server configurations and realized that the list of image formats supported by a server's Imagick configuration is not displayed anywhere.

In some cases, having this list easily available could be useful.

For example, this could be a good way to help users verify that their server will support WebP (and other more modern image formats) before the feature becomes available so that they can reach out to their hosts.

When Imagick is not the site's active editor, the GD supported formats could be shown instead, but GD handles this a bit differently (a bit-field is returned instead).

Attachments (6)

53022.diff (1001 bytes) - added by desrosj 4 years ago.
53022.2.diff (2.1 KB) - added by desrosj 4 years ago.
53022.3.diff (1.2 KB) - added by adamsilverstein 3 years ago.
53022.4.diff (1.3 KB) - added by adamsilverstein 3 years ago.
Site Health Info ‹ test — WordPress 2021-06-11 20-35-00.jpg (33.4 KB) - added by adamsilverstein 3 years ago.
53022.5.diff (1.2 KB) - added by adamsilverstein 3 years ago.

Download all attachments as: .zip

Change History (23)

@desrosj
4 years ago

#1 @desrosj
4 years ago

  • Description modified (diff)
  • Keywords has-patch added; needs-patch removed

#2 @Clorith
4 years ago

This seems like a very useful thing to add, even having it after an eventual WebP core support is added, being able to look and see that it's not supported when you feel like the images should be there will be beneficial to users.

Path looks simple enough as well 👍

I'm not sure we need the GD support at this time, looking at the other ticket, it seems GD only supports lossy conversion, so I suspect that won't be implemented at this time.

#3 @desrosj
4 years ago

  • Milestone changed from Awaiting Review to 5.8

@desrosj
4 years ago

#4 @desrosj
4 years ago

53022.2.diff cleans up the original patch a bit, makes the labels more accurate, and renames a variable from $imagick_version to $imagemagick_version, which more accurately reflects the value being stored.

I also added an Imagick version to the debug data. Currently, there is no version of the Imagick extension that officially supports PHP 8 (it requires building from source at the moment). As more people look to upgrade to PHP 8, knowing the installed version of the Imagick extension will be helpful.

@Clorith if you think the last item should be discussed a bit more or separated out to a new ticket, I'm happy to branch it out.

#5 @Clorith
4 years ago

Ahh, smart, I'd not thought about the relation there that you may want the PHP extension version as well, this seems reasonable to include then, I see no reason not to add it alongside this ticket, as they are related in that they are media handling debug fields.

#6 @desrosj
3 years ago

  • Keywords commit added
  • Owner set to desrosj
  • Status changed from new to assigned

#7 @desrosj
3 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 50817:

Site Health: Include more ImageMagick/Imagick information in the Media Handling section.

This adds additional information to the Media Handling section of the Site Health Info page. When ImageMagick is used as the site’s image editor, a full list of file formats supported will now be shown. This will help site owners debug any issues they encounter as support for newer, more modern image formats is added (such as WebP in [50810]).

Additionally, the version of Imagick installed. This will help site owners debug issues with generating images on the PHP side.

Some variables have also been renamed to more accurately represent what is being stored.

Props Clorith, desrosj.
Fixes #53022.

#8 @milana_cap
3 years ago

  • Keywords needs-codex added

Once we actually create end user docs for Site Health, it will be useful to direct people to the place where they can see which file types are supported in their installs. I imagine support team will find this useful as well.

#9 @adamsilverstein
3 years ago

This is great, thanks @desrosj! What do you think about listing image format support for LibGD when that is the active image editor, do we already do that?

#11 @adamsilverstein
3 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

@desrosj in 53022.4.diff I added support for GD image detection. Since gd_info data looks like this:

{
    "GD Version": "bundled (2.1.0 compatible)",
    "FreeType Support": true,
    "FreeType Linkage": "with freetype",
    "GIF Read Support": true,
    "GIF Create Support": true,
    "JPEG Support": true,
    "PNG Support": true,
    "WBMP Support": true,
    "XPM Support": false,
...
}

the code iterates through known formats, looking for matching array variables set to true. I also clean up the GIF image support string a bit and skip formats we don't need/use like "FreeType".

We'll need to keep this updated as new formats are added.

Reopening for consideration for 5.8, fine with 5.9 as well.

#12 @jorbin
3 years ago

53022.4.diff looks good to me. I think it would be good to get this in for 5.8 and since this is a bug to a new feature, it shouldn't be a problem this early in the beta cycle.

#13 @desrosj
3 years ago

Thanks @adamsilverstein!

Let's go ahead and add this. I think it makes sense so that users have the information they need.

For 53022.4.diff, I think that debug can be removed from the gd_formats array. When debug is not present the value of value is used instead. Since it looks like there will never be a difference between the two, debug can be skipped here.

Would it be worth allowing the $gd_supported_formats array to be filtered? That would allow plugins adding support for additional formats to add those formats to the list.

#14 @adamsilverstein
3 years ago

For 53022.4.diff​, I think that debug can be removed from the gd_formats array. When debug is not present the value of value is used instead. Since it looks like there will never be a difference between the two, debug can be skipped here.

Thanks for clarifying, I will remove that. I wasn't certain how these fields were used.

Would it be worth allowing the $gd_supported_formats array to be filtered? That would allow plugins adding support for additional formats to add those formats to the list.

I don't think so. This is a server level capability check, can plugins even add image format support at this level?

#15 @adamsilverstein
3 years ago

In 53022.5.diff I removed the debug data line and verified I still see the correct info in site health.

This should be ready for commit.

#16 @desrosj
3 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 51143:

Site Health: Display a list of file formats supported by the GD library.

This adds the list of file formats supported by the GD library to the Media Handling section in Site Health.

This will help site owners debug any issues they encounter as support for newer, more modern image formats is added (such as WebP in [50810]).

Follow up to [50817].
Props adamsilverstein, jorbin.
Fixes #53022.

#17 @desrosj
3 years ago

I felt it was good to include AVIF in this list, but just wanted to note that GD only supports this in PHP 8.1 and up.

Note: See TracTickets for help on using tickets.