WordPress.org

Make WordPress Core

Opened 2 months ago

Last modified 16 hours ago

#53022 reopened defect (bug)

List the supported file types for the active image editor

Reported by: desrosj Owned by: 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 (5)

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

Download all attachments as: .zip

Change History (17)

@desrosj
2 months ago

#1 @desrosj
2 months ago

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

#2 @Clorith
2 months 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
2 months ago

  • Milestone changed from Awaiting Review to 5.8

@desrosj
2 months ago

#4 @desrosj
2 months 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
2 months 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
6 weeks ago

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

#7 @desrosj
6 weeks 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
11 days 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
5 days 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
29 hours 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
16 hours 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.

Note: See TracTickets for help on using tickets.