Upload Media: Use .jpg extension for HEIC-to-JPEG client conversion#77506
Merged
Conversation
The client-side HEIC to JPEG converter in canvasConvertToJpeg() produced files with a .jpeg extension. Switch to .jpg since it is the more common and widely-recognized extension for JPEG images. The MIME type remains image/jpeg.
|
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 If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
adamsilverstein
added
[Type] Bug
10 tasks
|
Size Change: 0 B Total Size: 7.75 MB ℹ️ View Unchanged
|
|
Flaky tests detected in 147387d. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/24692739673
|
andrewserong
approved these changes
Apr 21, 2026
Contributor
andrewserong
left a comment
andrewserong
left a comment
There was a problem hiding this comment.
This rename is working nicely for me in testing 👍
One oddity that I noticed unrelated to this PR, but possibly related to #76731 is that the HEIC file I upload winds up getting a suffix that doesn't match the generated JPEG files.
E.g. I upload sample-IMG_0218.heic from my local filesystem and it's stored as sample-IMG_0218-1.heic in my server's filesystem (not the -1 appended). The JPG generated does not have a suffix, so it is stored as sample-IMG_0218.jpg.
This creates an interesting situation in subsequent uploads of the same file, where there's drift in the numbering of the suffix, so for the subsequent upload the HEIC file gets -3 as the suffix where the jpg files have -2.
For all the above, here's a screenshot across two uploads of my sample file:
In the above cases, I'd have expected the heic file to have the same basename as the jpg and for any suffix to be consistent across all of the files.
Are you able to reproduce?
(It's unrelated to the file extension, so not a blocker to landing this PR)
Contributor
|
Not sure if this is legit, but from a quick chat with Claude, it sounds like the I.e. the arg might need to be added here: gutenberg/lib/media/class-gutenberg-rest-attachments-controller.php Lines 31 to 85 in 70387ef Does that sound right? |
Member
Author
I did see this but thought it might be related to #77036. Since that merged now and you still see it, its probably another issue.
Possibly. I will open a follow up issue to address this specific problem. Merging the current fix as is. |
Member
Author
|
Follow up issue: #77564 |
adamsilverstein
added a commit
that referenced
this pull request
Apr 23, 2026
…route (#77565) The sideload handler reads $request['convert_format'] but the route did not declare it. Multipart/form-data requests delivered the client's "false" as a PHP string which evaluates truthy, so the filter that suppresses server-side format conversion was never added. This caused HEIC companion originals to get a numeric suffix while the JPEG derivative had none, and the drift widened on every subsequent upload of the same HEIC. Declaring convert_format with type=boolean (default true) lets the REST layer coerce the string to a PHP bool, matching what is already done for the create_item path, and incidentally fixes the HEIC/JPEG filename drift reported against #77506. Fixes #77564.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Follow-up to #76731. When the client-side HEIC→JPEG converter in
canvasConvertToJpeg()outputs a file, it now uses the.jpgextension instead of.jpeg. The MIME type remainsimage/jpeg.See #76732
Why
.jpgis the more common and widely-recognized extension for JPEG images. Using it keeps filenames uploaded by the HEIC conversion path consistent with what users expect to see.How
packages/upload-media/src/canvas-utils.ts: changed the threenew File( …, \${ baseName }.jpeg`, … )sites (one per decoding strategy) to.jpg`.packages/upload-media/src/test/canvas-utils.ts: updated the two matching test expectations and the affected test title.Testing Instructions
.jpgextension.Automated
npm run test:unit -- --testPathPattern="upload-media/src/test/canvas-utils"passes.