| 开发者 | mzeeshanejaz786 |
|---|---|
| 更新时间 | 2026年8月12日 18:29 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.0 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
zej-mediatidy folder to /wp-content/plugins/, or install it from the Plugins screen in your dashboard.That is the failure I designed hardest against. An image is only reported unused after Mediatidy has checked post content across all statuses, post meta, the options table, theme mods, the site logo, the site icon, custom CSS, widgets, term meta, user meta, menu items, reusable blocks, template parts and WooCommerce product galleries, including the resized variants of the file. Checking post content and post meta alone is what makes a scanner report a site logo as unused, so Mediatidy checks all of the above instead. It also re-verifies at the moment of deletion, and deletion is recoverable anyway.
Deletion moves the attachment into the Mediatidy trash, where the post row, the metadata and the files are all preserved. Restore puts it back with the same attachment ID, so anything still pointing at it keeps working. Compression and resizing back up the original file before writing, and there is a restore for those too. The only irreversible action in the plugin is emptying the trash, which you have to do on purpose.
Yes. Page builders store their layouts in post meta, and Mediatidy scans post meta including serialized builder data. WooCommerce product galleries and product images are checked specifically, since those live in meta keys a plain content scan misses entirely.
No. Nothing leaves your server. Every scan, hash, conversion and compression happens locally through GD or Imagick on your own host. There is no outbound request to any service, mine or anyone else's.
No. Install it and use it. There is nothing to sign up for and nothing to enter.
It is free and unlimited. Because the processing happens on your hardware rather than on a server I pay for, a 50,000 image library costs me the same as a 50 image one, so there is no image count to meter.
That is the case it was written for. Scans are batched, cursors are stored between requests, duplicate detection compares file sizes before it hashes anything, and results stream in as they are found. Libraries in the tens of thousands are the design target rather than the edge case.
Yes, and I would rather say so plainly. Compression and resizing rewrite the file in place, which is the only way the savings are real. Mediatidy copies the original to a backup location first, marks the attachment as already processed so a second pass cannot compound the quality loss, and gives you a restore action. If that copy cannot be made, for instance because the disk is nearly full, the edit does not happen at all and Mediatidy tells you why. WebP conversion is different: it writes new files and leaves your original alone.
Mediatidy converts the picture and every size your theme generated from it, then serves those copies in place of the originals. Your original files stay on disk untouched, so this costs disk space and saves your visitors download size. If a picture is later shrunk, resized, cleaned or restored, its WebP copies are deleted, so nobody is ever served a copy of a version you replaced.
Yes. Metadata removal rewrites the file container and copies the compressed image data across byte for byte, so the picture itself is never re-encoded and never loses quality. The original is still backed up first, so the restore action covers it either way. A file laid out in a way Mediatidy cannot rewrite safely is reported and left alone.