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.

[poena]

Image: favicon.png downloaded from the issue
Mac OS 15.1 (24B83)
Safari Version 18.1 (20619.2.8.11.10)

I created a new post, then:

Dragged the image from the desktop to the block editor: It created a new image block and there are no issues with the background color. I clicked on Replace in the block toolbar and opened the media library.
The image is in png format, and is not renamed.
I dragged the image a second time and it created a gallery block. The uploaded image is in png.
The image is renamed, but with a number increase, as expected since it was a duplicate.

Next, I dragged the image from the Safari browser window of this ticket directly into the editor. It created a new image block and there are no issues with the background color, and its a png with the expected name.

Next, I placed a new image block using the block inserter.
I selected option one: "Upload". The background of the uploaded image is distorted.
I clicked on Replace in the block toolbar and opened the media library.
The image is now a jpg with the name: tempImageBpkaxz.jpg and there is an additional line of information: Original image: tempImageBpkaxz.heic

[desrosj]

Thanks everyone for the additional details and testing. I'm moving to 6.7.1 to see if there's anything that can be done.

I think that respecting the browser's behavior is probably the right thing to do because it could be the user's configured preference. However, the image definitely should not be renamed, and I can't find how this can be configured or turned off.

[room34]

@desrosj I appreciate the intention of respecting the browser's behavior, but I think it's worth noting that this quite likely is a bug in the browser, and it may be worth working around it… just as adding image/heic to the accept attribute was a workaround to a Chrome issue in the first place.

1. There is no configuration setting in Safari or macOS to allow users to control whether or not this is happening.
2. The file renaming is being done by Safari during its conversion from PNG to HEIC.

I'm not able to think of a reasonable scenario where a user would want Safari, with no warning or option, to convert their image from PNG to HEIC (and change its filename to a random string) during the upload, especially since WordPress 6.7 is then going to convert the image to JPEG. Safari is misinterpreting the fact that the form accepts HEIC as an assumption that the file should be converted to HEIC.

Also consider the fact that it is only the method of uploading the image using the Upload button that causes this conversion. Dragging the image in or uploading it via the Media Library does not do the conversion. Users (e.g. me) are likely to blame the inconsistent behavior on WordPress, not on Safari.

[desrosj]

#62425 was marked as a duplicate.

[desrosj]

It looks like the ​upstream bug report has been fixed in Chromium. Perhaps the right way to proceed here is to ​remove this workaround and allow uploading HEIC to become available in Chrome/Brave as the user updates to the latest version.

The negatives of forced file conversion/temporary name seem to outweigh being unable to upload through one specific interface in the editor.

This will also need an accompanying report upstream in Gutenberg for tracking purposes as the code change will need to happen there.

[mayanktripathi32]

The upstream issue:https://issues.chromium.org/issues/375118901 has been marked as resolved and is now supported in Chrome Canary. I successfully tested adding HEIC and HEIF images using the images/* MIME type.

Tested Version: 133.0.6846.0 (Official Build) Canary (arm64).

[desrosj]

After discussing in today's bug scrub, it was decided that this behavior is much worse than not being able to upload an HEIC file in Chromium-based browsers through the upload form, especially since the media library and drag & drop uploading in the block editor are not affected.

The first option that will be explored in Gutenberg on GitHub is conditionally rendering the <form> with the appropriate attribute value. If that's too complicated or not possible, then the attribute will be changed back to images/* and we will need to wait for browsers to updated and include the bug fix that's currently in Chromium Canary.

[desrosj]

There is an ​upstream pull request available for review and testing.

[im3dabasia1]

Test Report

Description

This report verifies that the indicated ​patch resolves the issue where PNG images uploaded in Safari were converted to *.jpg . Testing confirms the following steps:

1. Used Safari browser (Version 17.3 (19617.2.4.11.8)), create a new post
2. Add group with background color
3. Add image in the group, and upload the favicon.png provided
4. Verified that the image is having the background as transparent and the background color is seen as expected
5. Checked the filename in the media library and is the same ie favicon.png, it has not changed to *.jpg

Results

✅ The fix successfully addresses the image handling inconsistency in Safari and preserves the original file format.

[cbravobernal]

In 59437:

Editor: update npm packages in trunk for 6.7.1.

Syncs Editor packages for WordPress 6.7.1 RC1. Includes the following PRs:

• ​https://github.com/WordPress/gutenberg/pull/66945
• ​https://github.com/WordPress/gutenberg/pull/66889
• ​https://github.com/WordPress/gutenberg/pull/67139

Props mmaattiiaass, ramonopoly, mamaduka, get_dave, poena, ntsekouras, mcsf, jsnajdr, 0mirka00, desrosj, joemcgill, cbravobernal, azaozz, room34, mayanktripathi32, im3dabasia1, jonsurrell.

Fixes #62478, #62447.

[desrosj]

Reopening for backport.

[desrosj]

Good to bring forward to trunk. See comment:9:ticket:62478.

[desrosj]

In 59438:

Editor: update npm packages in trunk for 6.7.1.

Syncs Editor packages for WordPress 6.7.1 RC1. Includes the following PRs:

• ​https://github.com/WordPress/gutenberg/pull/66945
• ​https://github.com/WordPress/gutenberg/pull/66889
• ​https://github.com/WordPress/gutenberg/pull/67139

Reviewed by desrosj.
Merges [59437] to trunk.

Props mmaattiiaass, ramonopoly, mamaduka, get_dave, poena, ntsekouras, mcsf, jsnajdr, 0mirka00, desrosj, joemcgill, cbravobernal, azaozz, room34, mayanktripathi32, im3dabasia1, jonsurrell.
Fixes #62478, #62447.