WordPress
Add support for HEIC uploading + JPEG conversion
First pass, excluding tests
Trac ticket: https://core.trac.wordpress.org/ticket/53645
This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.
Core Committers: Use this line as a base for the props when committing in SVN:
Props adamsilverstein, noisysocks, swissspidy, spacedmonkey, peterwilsoncc.
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
Test using WordPress Playground
The changes in this pull request can previewed and tested using a WordPress Playground instance.
WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.
Some things to be aware of
- The Plugin and Theme Directories cannot be accessed within Playground.
- All changes will be lost when closing a tab with a Playground instance.
- All changes will be lost when refreshing the page.
- A fresh instance is created each time the link below is clicked.
- Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance, it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.
Test this pull request with WordPress Playground.
Thanks for the PR @adamsilverstein. It doesn't seem to work when I test it, though.
If I drop a .heic into the gallery I see an error, the image cannot be previewed, and the file type is still image/heic.
https://github.com/user-attachments/assets/6a11403b-c794-439c-8cb6-59ebf104817f
Thanks for the PR @adamsilverstein. It doesn't seem to work when I test it, though.
@noisysocks some parts were missing, I had a little trouble debugging, but finally got it working. Can you give it another test?
Here is a screencast of uploading an HEIC image via drag and drop onto the editor:
https://github.com/user-attachments/assets/600766e8-bb07-4fa8-ad88-3dfad79139e1
on the right side you can see all of the files being generated in jpeg format. Note the preview functionality still isn't working correctly.
Also, using the "upload" selector in Gutenberg fails because HEIC is still not a recognized type there:
This probably needs fixing in Gutenberg.
Note the preview functionality still isn't working correctly.
Yep we'll need to fix those two issues in the Gutenberg repo.
Also, using the "upload" selector in Gutenberg fails because HEIC is still not a recognized type there:
This seems to work for me. Might be browser dependent. We can investigate on the Gutenberg side.
I'm seeing a different error about the image size now when I test with a picture I took the other day.
https://github.com/user-attachments/assets/1643092f-4c6c-40b4-b8d9-a8469cbe68ee
Error log:
2024/07/17 05:13:36 [warn] 2197#2197: *2317 a client request body is buffered to a temporary file /var/cache/nginx/client_temp/0000000026, client: 192.168.228.6, server: , request: "POST /wp-admin/async-upload.php HTTP/1.1", host: "wordpress-develop.ddev.site", referrer: "https://wordpress-develop.ddev.site/wp-admin/upload.php"
[17-Jul-2024 05:13:36] WARNING: [pool www] child 10848 said into stderr: "NOTICE: PHP message: PHP Fatal error: Uncaught Error: Undefined constant "IMAGETYPE_HEIC" in /var/www/html/build/wp-includes/media.php:5607"
[17-Jul-2024 05:13:36] WARNING: [pool www] child 10848 said into stderr: "Stack trace:"
[17-Jul-2024 05:13:36] WARNING: [pool www] child 10848 said into stderr: "#0 /var/www/html/build/wp-admin/includes/image.php(803): wp_getimagesize('/var/www/html/b...')"
[17-Jul-2024 05:13:36] WARNING: [pool www] child 10848 said into stderr: "#1 /var/www/html/build/wp-admin/includes/media.php(392): wp_read_image_metadata('/var/www/html/b...')"
[17-Jul-2024 05:13:36] WARNING: [pool www] child 10848 said into stderr: "#2 /var/www/html/build/wp-admin/includes/ajax-actions.php(2632): media_handle_upload('async-upload', NULL, Array)"
[17-Jul-2024 05:13:36] WARNING: [pool www] child 10848 said into stderr: "#3 /var/www/html/build/wp-admin/async-upload.php(33): wp_ajax_upload_attachment()"
[17-Jul-2024 05:13:36] WARNING: [pool www] child 10848 said into stderr: "#4 {main}"
[17-Jul-2024 05:13:36] WARNING: [pool www] child 10848 said into stderr: " thrown in /var/www/html/build/wp-includes/media.php on line 5607"
2024/07/17 05:13:36 [error] 2197#2197: *2317 FastCGI sent in stderr: "PHP message: PHP Fatal error: Uncaught Error: Undefined constant "IMAGETYPE_HEIC" in /var/www/html/build/wp-includes/media.php:5607
Stack trace:
#0 /var/www/html/build/wp-admin/includes/image.php(803): wp_getimagesize('/var/www/html/b...')
#1 /var/www/html/build/wp-admin/includes/media.php(392): wp_read_image_metadata('/var/www/html/b...')
#2 /var/www/html/build/wp-admin/includes/ajax-actions.php(2632): media_handle_upload('async-upload', NULL, Array)
#3 /var/www/html/build/wp-admin/async-upload.php(33): wp_ajax_upload_attachment()
#4 {main}
thrown in /var/www/html/build/wp-includes/media.php on line 5607" while reading response header from upstream, client: 192.168.228.6, server: , request: "POST /wp-admin/async-upload.php HTTP/1.1", upstream: "fastcgi://unix:/run/php-fpm.sock:", host: "wordpress-develop.ddev.site", referrer: "https://wordpress-develop.ddev.site/wp-admin/upload.php"
Looks like media.php references IMAGETYPE_HEIF but combat.php defines IMAGETYPE_HEIC.
Wiki says .heic, .heif, image/heic and image/heif are all valid. Should we be liberal in what we accept? In practice I've only ever seen .heic and image/heic.
https://en.wikipedia.org/wiki/High_Efficiency_Image_File_Format
OK, it's working well for me with this patch applied:
diff --git a/src/wp-includes/compat.php b/src/wp-includes/compat.php
index f7c1a85871..bd4f1b69dc 100644
--- a/src/wp-includes/compat.php
+++ b/src/wp-includes/compat.php
@@ -514,6 +514,6 @@ if ( ! defined( 'IMG_AVIF' ) ) {
}
// IMAGETYPE_HEIF constant is not yet defined in PHP as of PHP 8.3.
-if ( ! defined( 'IMAGETYPE_HEIF' ) ) {
- define( 'IMAGETYPE_HEIF', 99 );
+if ( ! defined( 'IMAGETYPE_HEIC' ) ) {
+ define( 'IMAGETYPE_HEIC', 99 );
}
I tested a bunch of different upload flows. Here's how it looks:
https://github.com/user-attachments/assets/f1c3d19b-fd5d-46e4-a2fc-d35945653a9c
I like that this approach means that you can download the original HEIC image via the attachment page. Very nice.
👍 LGTM once that define() is fixed.
Here's a fix for the Image block: https://github.com/WordPress/gutenberg/pull/63643
Interestingly, in my project I just saw some differences in the browser tests where the browser-determined mime type was once image/heic and once image/heif. Strangely that was for the same image 🤔
I don't know how the mime type detection works in PHP, but it might be worth testing this with a few different HEIC images to see if the image/heif mime type also needs to be checked (in addition to just image/heic).
HEIC images have a different FourCC code depending on the type:
'mif1', // .heic / image/heif
'msf1', // .heic / image/heif-sequence
'heic', // .heic / image/heic
'heix', // .heic / image/heic
'hevc', // .heic / image/heic-sequence
'hevx', // .heic / image/heic-sequence
Looks like media.php references IMAGETYPE_HEIF but combat.php defines IMAGETYPE_HEIC. Ah, right. sticking with HEIC for now, fixed in a65c937c5e6cb92de8ca76ca36d0d20a44c9430e
Interestingly, in my project I just saw some differences in the browser tests where the browser-determined mime type was once
image/heicand onceimage/heif. Strangely that was for the same image 🤔I don't know how the mime type detection works in PHP, but it might be worth testing this with a few different HEIC images to see if the
image/heifmime type also needs to be checked (in addition to justimage/heic).HEIC images have a different FourCC code depending on the type:
'mif1', // .heic / image/heif 'msf1', // .heic / image/heif-sequence 'heic', // .heic / image/heic 'heix', // .heic / image/heic 'hevc', // .heic / image/heic-sequence 'hevx', // .heic / image/heic-sequence
Currently I'm using this bit of code which I haven't really verified works beyond a single test image. This will be important to test throughly because PHP won't properly detect the mime type.
I plan to add tests next and can bundle several test images to make sure they are identified correctly (and hopefully that we can get the sizes correctly with Imagick). I'll be looking for test images that have a compatible license and are relatively small, contributions welcome!
This works well in my testing. I really like that you get to the original image from the attachment screen.
Worth noting that I tried uploading heif from https://filesampleshub.com/format/image/heif. I was unable to upload and I get this error message.
This works well in my testing. I really like that you get to the original image from the attachment screen.
yum!
Worth noting that I tried uploading heif from filesampleshub.com/format/image/heif. I was unable to upload and I get this error message.
Thanks for the link to the sample files, that is helpful.
I could try to extend full support to .heif files. Do we know how common these are or where/how they are created? I double checked and the files my iphone was creating before I switched it off were .heic files.
As an experiment I took a .heic image from my iPhone and renamed it to .heif. Regardless of whether the file is .heic or .heif it works the same in Preview and other Apple apps. In both cases the MIME type that file -I spits out is image/heic.
$ file -I playground-1.HEIF
playground-1.HEIF: image/heic; charset=binary
$ file -I playground-2.HEIC
playground-2.HEIC: image/heic; charset=binary
I think it makes sense to have WordPress do the same. Support both .heic and .heif but map them to image/heic in both cases.
Other sample images
https://filesampleshub.com/format/image/heic https://github.com/tigranbs/test-heic-images/tree/master https://www.learningcontainer.com/sample-heic-files-download/# https://github.com/dsoprea/heic-exif-samples
Added some tests @adamsilverstein.
I think coverage is okay, though I struggled to write one for the changes to wp_generate_attachment_metadata. Ended up deciding it's not worth the effort since it more or less is already covered by test_resize_heic.
Something strange I noticed is that our PHP 8.3 container in GitHub Actions doesn't have the Imagick extension enabled but the other containers do 🤷♂️
This still tests really well for me. Here's how things look now that https://github.com/WordPress/gutenberg/pull/63643 is merged.
https://github.com/user-attachments/assets/6cfcda0c-d04b-445f-9884-677f539aac2a
I'll commit on Monday if there's no objections. Keen to get something in early for 6.7 so that there's plenty of time for feedback and iteration.