Shrink Uploads, Serve WebP, Move Media to S3
If you run a community site on WordPress, your media library is probably the heaviest part of it. Big photos slow your pages down. Your origin server fills up. Search gets sluggish once you cross a few thousand uploads. The new WPMediaVerse 1.3.0 release is built around fixing exactly those problems. Here is what you get the moment you update.
Your media library shrinks 10 to 30 percent overnight
Every JPEG, PNG, and GIF a member uploads is automatically re-encoded smaller. The visible quality stays the same; the file just gets lighter. Hidden camera data is stripped. Typical savings land between 10 and 30 percent on every upload, starting from the very next one.
If the optimization ever produces a bigger file than the source, the original is kept. Animated GIFs stay animated. Nothing breaks.
To shrink the files you already have, run one command:
wp mvs optimize-bulk
It walks your entire library, is resume-safe if interrupted, and shows you the savings per file in the All Media admin column.
Already paying for EWWW, Imagify, Smush, or ShortPixel? Leave them on. They run alongside the built-in WPMediaVerse pipeline through a single extension point.
Your phone visitors get pages that load roughly a third faster
Every uploaded image now gets a WebP sibling automatically (around 25 to 35 percent smaller than the JPEG). Modern browsers pick it up; older browsers keep getting the original. There is nothing to configure.
If you want to push savings even further, switch on AVIF in Settings, Storage tab. AVIF cuts another 30 percent on top of WebP. It is opt-in because the encoder is slower at upload time.
Both formats are served everywhere your members actually see media:
- The explore grid
- BuddyPress activity feed
- Dashboard cards
- Single media pages
- The lightbox
- Private images served through gated URLs
Mobile users on slower networks are the biggest winners here.
Move your media library to S3 or BunnyCDN without writing a script
Until now, getting existing local media off your origin server was a do-it-yourself project. Not anymore. Open Settings, Storage tab and you get two buttons:
- Move next 20 uploads the next batch of public media to your active cloud driver.
- Delete next 20 removes the local copies after the cloud copies are verified.
Every destructive click goes through a confirmation modal. You can stop whenever you want and pick up later.
Prefer the command line? The same flow is available as:
wp mvs migrate-storage --from=local --to=bunnycdn
Idempotent and resume-safe. Run it on a million-file library and it will pick up exactly where it stopped if your terminal dies.
Once your media is in the cloud, flip on the new direct-CDN setting and public images load from your CDN edge instead of being proxied through WordPress.

S3-compatible storage now works correctly
If you use Cloudflare R2, MinIO, or Backblaze B2 instead of AWS S3 to save money on bandwidth, you finally get a driver that works. The old path encoding worked on AWS by coincidence and silently failed on every other S3-compatible backend. Fixed.
BunnyCDN migrations are also no longer dumping duplicate uploads because the file-exists check actually works now.
Search keeps working when your library hits 100,000 items
If you have ever watched the WordPress search box hang for several seconds on a busy media library, you know the problem. WPMediaVerse search now runs on a FULLTEXT index for queries of three characters or more. Result: milliseconds, not seconds, on libraries with 100,000+ media items.
Two more changes you will feel on busy pages:
- Each media item is loaded from the database once per page, even when it is rendered many times. Activity feeds and dashboards see a noticeable drop in query count.
- View-tracking events older than 90 days are pruned daily. Your database stays lean on long-running sites. (Window is configurable per site.)
Two security fixes you should not skip
If you run private albums on a BuddyPress community, this is the part to read carefully.
- Private media stays private in the activity feed. Before this release, posting a non-public media item to a BuddyPress activity would still leak the activity card (your composer text, timestamp, author) to the public stream, even though the image itself was hidden. Activity visibility is now derived from the strictest of the media and album privacy settings.
- REST endpoints can no longer be slowed by enormous result requests. Every list endpoint now caps the per-page count. The cap is filterable for trusted environments, but the default is sensible.
Update WPMediaVerse for these two alone if nothing else.
The small fixes that quietly remove paper cuts
- Your cloud storage password is no longer wiped when you save the settings form with the password field empty.
- MP4 uploads now generate proper poster images on managed WordPress hosts (the plugin auto-detects ffmpeg in the usual locations).
- Videos without an embedded cover image get a clean default poster instead of a black frame.
- Audio without cover art gets a unique SoundCloud-style waveform card instead of a blank thumbnail.
- PHP 8.4 and 8.5 compatibility warnings are gone.
Update both plugins together
WPMediaVerse Pro 1.3.0 talks to Free 1.3.0 APIs directly, so update them in the same maintenance window. The safe order is: backup, update Free, update Pro immediately after.
If you are new to WPMediaVerse, here is why I built it in the first place. For a related Wbcom plugin release in the same family, see the Jetonomy 1.3.8 update covering FluentCommunity integration and space moderation.
For the full version-by-version changelog, see the Free release notes and Pro release notes.
This WPMediaVerse 1.3.0 release is the one I always wanted to ship. Not the features, but the cleanup that makes the features quiet, fast, and out of your way. Lighter media. Faster pages. Cloud storage you can actually use. Search that does not give up at scale. That is what you get when you click update.