You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add a safe WP-CLI command for resizing oversized original uploads #254
WordPress and WP-CLI provide excellent tools for generating image sub-sizes, but there is no first-class way to process oversized original uploads in a controlled, scriptable manner.
Many sites accumulate large camera originals that are far beyond their actual display needs. This increases storage, backup, CDN, and transfer costs. WordPress’s automatic large-image handling does not solve every existing-media or site-policy scenario.
I propose an opt-in command such as:
wp media resize-originals --max-dimension=1920 --quality=91 --dry-run
The command would:
process original uploads in bounded batches;
support JPEG, PNG, and WebP;
provide a dry-run with estimated storage savings;
require explicit confirmation before destructive changes;
preserve a recoverable backup or offer a documented backup strategy;
update only relevant attachment metadata;
never regenerate unrelated sub-sizes unless explicitly requested;
Worth noting that with big_image_size_threshold the original is still uploaded/preserved, but the 'large' image size is the scaled down version. Question is whether we should do the same or do a destructive resize.
It also only affects new uploads, not existing attachments. So this proposed command would fill that gap.
process original uploads in bounded batches
In line with wp media regenerate [<attachment-id>...], this could be wp media resize-originals [<attachment-id>...], so it's up to the caller to query & resize attachments in batches. We don't do batching for wp media regenerate --yes either.
support JPEG, PNG, and WebP
Depends on what WordPress/server support.
provide a dry-run with estimated storage savings;
Sounds complex, not sure if that is easily doable.
preserve a recoverable backup or offer a documented backup strategy;
I'd say it's up to the caller to back up files if needed. We could perhaps add a flag to control whether to keep the original (like big_image_size_threshold) or not.
Activity
szepeviktor commentedon Jul 31, 2026
my hack: https://github.com/szepeviktor/wordpress-website-lifecycle/blob/master/tools/resize-original-media.php#L23
swissspidy commentedon Jul 31, 2026
Thanks for opening!
Related:
https://make.wordpress.org/core/2019/10/09/introducing-handling-of-big-images-in-wordpress-5-3/
https://github.com/WordPress/wordpress-develop/blob/ad2405c10e4d6311464ff40d75435ad95bb8a844/src/wp-admin/includes/image.php#L263-L284
Worth noting that with
big_image_size_thresholdthe original is still uploaded/preserved, but the'large'image size is the scaled down version. Question is whether we should do the same or do a destructive resize.It also only affects new uploads, not existing attachments. So this proposed command would fill that gap.
In line with
wp media regenerate [<attachment-id>...], this could bewp media resize-originals [<attachment-id>...], so it's up to the caller to query & resize attachments in batches. We don't do batching forwp media regenerate --yeseither.Depends on what WordPress/server support.
Sounds complex, not sure if that is easily doable.
I'd say it's up to the caller to back up files if needed. We could perhaps add a flag to control whether to keep the original (like
big_image_size_threshold) or not.szepeviktor commentedon Jul 31, 2026
On thing to note:
on a test site the estimated disk space gain is 11.96 GB across 4411 original uploads