WP 6.7 Block Editor converting new PNG uploads to JPEG with mangled backgrounds

[room34]

I’m finding that if I upload a PNG with a transparent background (which is the only reason I use PNG most of the time) in the Block Editor, it’s getting converted to a JPEG with the transparency either turned black or some kind of distorted color blocks from the foreground elements of the image.

If I go into the Media Library and look at the images that were uploaded, the Original image link is not to the original PNG version of the image, but a HEIC file with a name like tempImage1fPWE9.heic and then that has been converted to a JPEG (e.g. tempImage1fPWE9.jpg) for display on the site.

If I upload the PNG directly in the Media Library, it uploads normally. This problem is only happening in the Block Editor. I confirmed it is happening on a site running WordPress 6.7 using the Twenty Twenty Five theme and no plugins active.

I saw in the release notes that 6.7 has added support for HEIC images, but I am not uploading HEIC images, they are definitely PNGs on my computer.

[desrosj]

Hi @room34,

Thanks for this report! It seems to identify two issues that may or may not be related: PNGs being converted to different formats with a loss of transparency, and images being renamed. #62425 has already been opened for the latter, so let's focus on the former in this one.

Could you provide a bit more context around how you're inserting your image into the block editor? I've tried the following with no success:

• Uploading through the image block
• Uploading through the cover block
• Uploading by dragging and dropping into the editor

Could you provide the image you are trying to upload that is experiencing the problem?

Also, are you utilizing GD or ImageMagick for image manipulation? If you're unsure, you can find this info under Tools > Site Health, click the Info tab, and expand the Media Handling section.

[room34]

I think it's fairly obvious the issues are not unrelated, although I don't really care about the filenames. My concern is that PNGs are being converted to HEIC somehow, and then (as I would expect with WP 6.7), those HEIC files are being converted to JPEG — which explains the loss of transparency.

The process I'm following is uploading the image through the image block.

I'm attaching both a screenshot of the Media Handling details from one of the sites where I've observed this (although I've observed it now on three different sites, running on three different servers), along with the PNG I'm using to test. This PNG is an illustration I created directly as an export from Affinity Designer; it is not an image that has ever been in HEIC format.

[azaozz]

Cannot reproduce in WP 6.7 using the provided favicon.png. Tested in Firefox and Brave (Chromium).

If I go into the Media Library and look at the images that were uploaded, the Original image link is not to the original PNG version of the image, but a HEIC file with a name like tempImage1fPWE9.heic and then that has been converted to a JPEG (e.g. tempImage1fPWE9.jpg) for display on the site.

This sounds really peculiar. This is a really long shot but is there any chance that "something" on your computer is actually uploading a .heic version of the image instead of the .png you're using/dragging?

• If uploading by dragging, are you dragging from the desktop or from another app?
• What happens if you upload to the Media Library by dragging the image from the same location?
• Could you try uploading a .heic image (if needed a .heic image for testing can be downloaded here: https://core.trac.wordpress.org/browser/tags/6.7/tests/phpunit/data/images/test-image.heic).

[room34]

@azaozz Indeed! This appears to be Safari-specific. I just tried it in Chrome and the upload was fine. Tried it again on the same post in Safari and the problem happened again.

I got a new Mac this week right around the same time this started happening — a fact I mentioned when I [posted](​https://wordpress.org/support/topic/wp-6-7-block-editor-converting-new-png-uploads-to-jpeg-with-mangled-backgrounds/) this in the general WP support forums, but removed from this ticket — but since I was already running the same OS and software versions on my old Mac before, I didn't think it was that likely to be the issue.

I'll dig into the Safari settings further and see if I can figure out how and why it's doing the conversion. Again it's worth noting this is only happening in the Block Editor, not if I upload in the Media Library. And since it's happening with the stock configuration of Safari on a new Mac, I'm sure I'm not the only person who's going to encounter the issue. (And I suspect most of the people who do encounter it won't know how to report it.)

[room34]

Maybe I need to open a separate ticket for this, but as I was digging through the WP 6.7 code for anything HEIC related, I came across something that looks like a coding error — a misnamed variable.

In the file wp-includes/media.php, in the wp_show_heic_upload_error() function, at line 5612 in the file, a value is being set for a node in the $plupload_init array. However the variable being passed in, and returned by the function, is $plupload_settings. The variable $plupload_init is not a global and is not defined in the function. So in other words, I don't think this function as it's currently written is capable of doing anything. Probably doesn't have anything to do with the issue I'm seeing in Safari, but it definitely should be looked at by someone who knows the code base better than I do.

[room34]

I just found this:

[Safari 17+: Image file got automatically converted to HEIC extension](​https://forums.developer.apple.com/forums/thread/743049)

Seems Safari is doing it when image/heic is included in the accept attribute of the file input. The accept attribute is present in the Image block uploader but not in the Media Library uploader.

I don't know exactly how the drag-and-drop process works (I'm decent with vanilla JavaScript, clumsy with AJAX, and know nothing about React at all), but that also is obviously not a scenario where there's a file input with an accept attribute, hence the image is not being mishandled.

So… yes, it's a Safari bug. But it's happening because the accept attribute was added to the file input in the Image block.