#53022 closed defect (bug) (fixed)
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 )
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)
Change History (23)
#4
@
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
@
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.
#8
@
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
@
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?
This ticket was mentioned in PR #1366 on WordPress/wordpress-develop by adamsilverstein.
3 years ago
#10
Trac ticket: https://core.trac.wordpress.org/ticket/53022
#11
@
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
@
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
@
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
@
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
@
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.
#17
@
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.
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.