| 开发者 | gfxproductions |
|---|---|
| 更新时间 | 2026年7月30日 17:08 |
| PHP版本: | 8.1 及以上 |
| WordPress版本: | 7.0 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
photo.jpg to photo.webp and repointing every reference at the new file. Other plugins keep the original and add a parallel file served through an .htaccess rule, a <picture> tag or a CDN. EvoMedia changes the actual file on your disk. There is no rewriting layer at page-render time - nothing to break when you switch hosts, and nothing to un-install later.
And once your library grows, EvoMedia helps you see into it: an index of where every image is actually used, so you know what is safe to remove - plus reports of the duplicate and orphaned files quietly wasting your disk.
Everything runs on your own server, through Imagick or GD. No account, no API key, no credits, no monthly quota, no upload limit. Your images are never sent anywhere.
What it does
photo.jpg to photo.webp with a plain SQL replace and the recorded length no longer matches the string. PHP refuses to unserialize it. The section disappears.
EvoMedia walks the structure, replaces the value, and lets PHP recompute the lengths. This is why it can offer replace, format conversion and (in the Pro add-on) renaming at all - and it is the part that took the longest to get right.
Take control of the sizes WordPress generates
Every upload, WordPress quietly creates a stack of resized copies - thumbnail, medium, large, and hidden HiDPI versions - whether your theme uses them or not. EvoMedia lists every registered size with a live count of how many images in your library have it, lets you turn off the ones you don't need (only new uploads and regenerations are affected - files already on disk are left alone), and regenerates your whole library to match with a single button and a progress bar. Core sizes are flagged, so you never switch off one the theme relies on by accident.
Know which images you can actually delete
Every library accumulates images nobody uses, and the reason they are never cleared out is that you cannot tell which ones they are. Deleting the wrong one takes a page down.
EvoMedia scans your posts, pages, custom fields and site settings and records where each image is referenced - including the ones page builders name by ID with no URL to search for, and the ones held in a category image, an author profile or your site logo. Each image then carries a count you can sort by, and opening it lists the exact places, with the size each one uses.
It reports only what it can prove. An image referenced solely from a theme file, a stylesheet or an external service cannot be seen from the database, and every list says so rather than pretending otherwise. An image that has not been scanned yet shows "?" and never "0" - because "nobody uses this" and "nobody has looked" are different answers, and confusing them is how cleanup tools delete pictures that were still on a page.
Built to coexist
Media plugins break each other. EvoMedia is written to notice what else is installed:
evomedia folder to /wp-content/plugins/, or install it through Plugins → Add New.No. EvoMedia keeps the attachment and updates WordPress's own metadata, so everything that renders through WordPress keeps working. And if a replace changes the file's name or its format, every reference in posts and postmeta is rewritten to match - serialized data included.
Only if you ask it to. Keep the current file name and the URL stays identical: nothing anywhere needs updating. Choose the uploaded file's name, or a different format, and EvoMedia rewrites every reference for you. Be aware that if other websites link straight to the old file, those links will break - that is unavoidable once the filename changes.
Yes. Tick "Backup originals before converting" and the original is archived before each conversion. Restore it from the Backup Status column, per image or in bulk.
Whichever your server's image driver can actually encode - commonly WebP, AVIF and JPEG, and JPEG XL on the rare host whose Imagick was built with it. Only formats your server can write are listed: nothing is shown that you cannot select and use immediately, and nothing your server supports is held back. The System Info page reports exactly what your image driver can do.
No. Turning a size off only stops WordPress generating it for new uploads and regenerations - the files already on disk are left exactly as they are. (Reclaiming that disk space by deleting a size's existing files is a job for the Pro add-on.)
Those are WordPress core sizes, flagged with a warning, because themes and the responsive-image system often rely on them. WordPress falls back to a nearby size if one is missing, but layouts can shift - so turn off a core size only if you know your theme doesn't use it. The extra HiDPI copies (1536×1536, 2048×2048) are usually the safest to drop.
It rebuilds every image's sub-sizes to match your current settings - (re)creating the sizes you have on and dropping the ones you turned off. It never deletes files and only touches the sub-sizes, never your originals.
Yes. Turn on "Resize on upload" in the upload panel to cap every incoming image at 2560px and drop the oversized full-size original WordPress would otherwise keep beside it. It is off by default, so nothing changes until you switch it on. (The Pro add-on lets you set your own maximum dimensions, and resize images already in your library.)
Build the index from EvoMedia → Media Usage. Every image then carries a "Used in" count in the Control Center that opens to show the exact posts, custom fields and site settings referring to it, and which size each one uses. A count of 0 means nothing on your site points at it. An image that has not been scanned yet shows "?" and never "0", so you are never told an image is unused just because it has not been looked at. (Deleting unused images in bulk is a feature of the Pro add-on; the free build shows you what is safe to remove.)
The free build only lists them. Duplicates are compared byte for byte, not guessed from their size, so nothing is called a duplicate until the contents match; entries that merely share one file on disk are listed apart. Orphaned files are looked for only in the year and month folders WordPress itself creates, and any file your content still references by name is flagged as still in use. Removing them is the Pro add-on's job, and it re-scans and re-checks each file at the moment of deletion, so nothing in use is ever taken off disk.
Because a parallel copy has to be delivered by something: an .htaccess rule, a <picture> tag rewrite, or a CDN. That layer can fail silently, breaks when you move host, and leaves orphaned files behind if you ever remove it. EvoMedia converts the file itself and repoints every reference at it. What is on disk is what is served, by WordPress, with no help from anything.
Nothing. Converted files stay where they are and keep being served. EvoMedia does not proxy or rewrite anything at page-render time.
Because your files live in a remote bucket, and rewriting them locally would leave your site pointing at stale objects. EvoMedia detects the offload plugin and steps aside. If you know what you are doing, the evomedia_allow_with_offload filter overrides this.
None. No image quota, no counter, no expiry, no licence key, and no feature switched off waiting to be unlocked. Everything in this plugin works from the moment you activate it.
No. Conversion runs on your own server through Imagick or GD. The plugin makes no network requests of any kind.