Client Side Media: Optimize previously uploaded media#79509
Open
adamsilverstein wants to merge 4 commits into
Open
Client Side Media: Optimize previously uploaded media#79509adamsilverstein wants to merge 4 commits into
adamsilverstein wants to merge 4 commits into
Conversation
…ration Add the store primitives to re-process an already-uploaded attachment client-side: a public optimizeExistingItem action that enqueues a queue item which fetches the original file, re-compresses it (same format) via the existing TranscodeImage operation, uploads the result as a new attachment, and regenerates sub-sizes. Introduce the FetchRemoteFile operation (and a fetchFile utility) to download an existing file by URL, and a FETCH_REMOTE_FILE_ERROR code. Unsupported or unprocessable formats are skipped via onError, leaving the original attachment untouched. Part of #79364.
…images Register an editor.BlockEdit filter that adds an "Optimize" inspector panel to image-bearing blocks (image, cover, media-text, post-featured-image, site-logo). The control resolves the block's attachment, dispatches optimizeExistingItem against its full-size original, repoints the block at the new optimized attachment, and reports progress and errors via snackbars. Gated on window.__clientSideMediaProcessing and isClientSideMediaSupported() so it only appears when client-side media processing is active. Part of #79364.
…e2e flow Add store unit tests for the optimizeExistingItem enqueue shape, its unsupported/non-image/duplicate guards, and fetchRemoteFile success and error paths. Extend the client-side media processing e2e spec with an 'optimize a previously uploaded image' case asserting the block repoints to a new -optimized attachment that is no larger than the original. Part of #79364.
|
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. |
|
Size Change: +1.38 kB (+0.02%) Total Size: 7.51 MB 📦 View Changed
|
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
1 participant
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?
Adds the ability to optimize previously uploaded media using the client-side (WASM/libvips) pipeline. A new "Optimize" control appears in the inspector of image-bearing blocks; clicking it fetches the attachment's original file, re-compresses it in the browser, regenerates sub-sizes, uploads the result as a new attachment, and repoints the block at it.
Closes part of #76756. Implements #79364.
Why?
Client-side media currently optimizes media only at upload time. Sites that predate the feature (or media uploaded before it was enabled) get no benefit. This lets users re-process existing media (e.g. compress a legacy JPEG, regenerate sub-sizes) using the same in-browser pipeline, with graceful fallback when the browser can't process an item. This is one of the capabilities called out for the 7.1 cycle.
How?
Store (
@wordpress/upload-media):optimizeExistingItem( { id, url, fileName, onSuccess, onError, additionalData } )that enqueues a queue item (withsourceUrl/sourceAttachmentIdand aStubFileplaceholder) whose operations are[ FetchRemoteFile, TranscodeImage(same format), Upload, ThumbnailGeneration, Finalize ].FetchRemoteFileoperation +fetchFile()utility to download the original by URL.TranscodeImageoperation for same-format re-compression (no duplicateCompressop), and the existing sideload/finalize chain to regenerate sub-sizes.FETCH_REMOTE_FILE_ERRORcode. Unsupported/unprocessable formats are skipped viaonError, leaving the original attachment untouched.UI (
@wordpress/editor):editor.BlockEditfilter adds an "Optimize" inspector panel tocore/image,core/cover,core/media-text,core/post-featured-image, andcore/site-logo. (Gallery items are themselvescore/imageblocks, so they're covered when selected.)isUploadingById).window.__clientSideMediaProcessingandisClientSideMediaSupported().The optimized result is uploaded as a new attachment and the block is repointed at it (matching the media-experiments prototype). This reuses the existing
mediaUpload/mediaSideload/mediaFinalizesettings, so no PHP/REST changes are required.Testing Instructions
-optimizedattachment that is no larger than the original.Automated
npm run test:unit packages/upload-media— store unit tests foroptimizeExistingItemandfetchRemoteFile.npm run test:e2e -- test/e2e/specs/editor/various/client-side-media-processing.spec.js— "optimizes a previously uploaded image into a new attachment".Out of scope (follow-ups)