HXMC keeps your media library tidy with three focused tools \u2014 and an honest scope for each.<\/p>\n\n
1. Usage scan (read-only)<\/strong>\nDetects references to each image in featured images, post content (all intermediate sizes covered), custom fields, and widgets\/options. Images with no detected reference are flagged as \"No reference found\" \u2014 deliberately not<\/em> \"unused\", because the scanner cannot see theme\/CSS hardcoded URLs, serialized page-builder data, or external sites. This version never deletes anything. The list is there to inform your own decision.<\/p>\n\n 2. Safe rename for non-ASCII filenames<\/strong>\nJapanese (or any non-ASCII) filenames cause percent-encoded URL mess and occasional server-side trouble. HXMC renames the original file and every intermediate size on disk, rewrites URLs in post content and custom fields, and registers a 302 fallback redirect for the old URL \u2014 so nothing breaks even where a reference could not be rewritten. Redirects fire only on 404, costing nothing on normal requests. GUIDs are left untouched, per WordPress convention.<\/p>\n\n 3. WebP conversion with built-in compression<\/strong>\nGenerates For the ~2% of browsers without WebP support, HXMC writes Accept-header fallback rules to 4. In-place compression (overwrite mode)<\/strong>\nRe-encodes JPEG (quality knob, shared with WebP \u2014 one quality concept) and losslessly recompresses PNG, overwriting the same filename so URLs never change and no database rewrite is needed. Files are overwritten only when the result is smaller<\/em>; otherwise the original bytes are kept. This is lossy for JPEG and irreversible \u2014 the confirm dialog says so plainly, and no backups are made (doubling disk usage would contradict the point of a cleanup plugin). JPEG metadata (EXIF) is stripped as part of the diet when Imagick is available.<\/p>\n\n 5. Media replace (same filename, fresh cache)<\/strong>\nUpload a new file over an existing attachment: the filename \u2014 and therefore every URL \u2014 stays identical, thumbnails are regenerated (old size files are cleaned up, stale size references in content are healed), and references get a Design principles (HX Series)<\/strong>\n* Admin-only. Zero JavaScript, zero markup, zero cookies added to your visitors' pages. The only front-end footprint is a 404-time redirect lookup.\n* No external services. Image processing is local GD\/Imagick.\n* 302 only \u2014 never 301 \u2014 so redirects are never cached into permanence.\n* Fires Because \"no reference found\" is not proof of non-use. Deletion may come later behind explicit safeguards; v0.1 is read-only by design.<\/p><\/dd>\n No. Rename moves files (content intact); WebP conversion creates new files alongside the originals.<\/p><\/dd>\n No. JPEG recompression is lossy and originals are overwritten (only when smaller). If you need the pristine originals, keep your own backups before compressing. WebP conversion, by contrast, always keeps originals.<\/p><\/dd>\n On Apache\/LiteSpeed, nothing \u2014 the fallback rules serve the kept original automatically. On Nginx, add the snippet shown on the admin page to your server config. Without it, non-supporting browsers (IE11, Safari 13 and older) would fail to load converted images.<\/p><\/dd>\n String replacement inside serialized values corrupts them, so HXMC skips serialized rows on purpose. The 302 fallback redirect covers those references instead.<\/p><\/dd>\n\n<\/dl>\n\n\n.webp<\/code> twins for the original and all sizes using GD or Imagick \u2014 entirely on your server, no external API. Compression is simply the WebP quality setting (default 82): one knob, not two features. Originals are kept on disk as insurance, references are rewritten to .webp<\/code>, and old URLs get the same 302 fallback. Already-WebP files, SVGs, and animated GIFs are honestly refused rather than silently mangled.<\/p>\n\nuploads\/.htaccess<\/code> (Apache\/LiteSpeed): requests for .webp<\/code> from non-supporting browsers are transparently served the kept original, with Vary: Accept<\/code> so caches stay correct. On Nginx, where plugins cannot write server config, the admin page shows an equivalent copy-paste snippet instead.<\/p>\n\n?v={timestamp}<\/code> cache-busting parameter so browsers and CDNs fetch the new bytes immediately. WebP twins and compression state are reset, with content references rewritten back and 302 entries covering stragglers. Same MIME type only \u2014 keeping a .jpg<\/code> name on PNG bytes would be a lie.<\/p>\n\nhxmc_after_rename<\/code> and hxmc_after_convert<\/code> actions for integration (e.g. HXMD \u2014 Markdown Log Manager).<\/p>\n\n\n\n
Why doesn't it delete unused images?<\/h3><\/dt>\n
Does it modify my original images?<\/h3><\/dt>\n
Is compression reversible?<\/h3><\/dt>\n
What happens in browsers without WebP support?<\/h3><\/dt>\n
What about serialized data (page builders)?<\/h3><\/dt>\n
0.3.11<\/h4>\n\n
\n
0.3.10<\/h4>\n\n
\n
0.3.9<\/h4>\n\n
\n
0.3.8<\/h4>\n\n
\n
0.3.7<\/h4>\n\n
\n
0.3.6<\/h4>\n\n
\n
0.3.5<\/h4>\n\n
\n
0.3.4<\/h4>\n\n
\n
0.3.3<\/h4>\n\n
\n
0.3.2<\/h4>\n\n
\n
0.3.1<\/h4>\n\n
\n
0.3.0<\/h4>\n\n
\n
hxmc_after_replace<\/code> hook.<\/li>\n<\/ul>\n\n0.2.0<\/h4>\n\n
\n
hxmc_after_compress<\/code> hook.<\/li>\n<\/ul>\n\n0.1.2<\/h4>\n\n
\n
0.1.1<\/h4>\n\n
\n
0.1.0<\/h4>\n\n
\n