derived<\/strong> files (the resized and alternate copies that come from your registered image sizes).\nThey are counted, not listed, because they follow their original.<\/p>\n\nIt is a diagnostic. It never deletes, moves, renames, imports, regenerates or repairs anything, it does not\nmodify attachment metadata, and it writes nothing to your database.<\/p>\n\n
The plugin is deliberately conservative. A file is only reported as an orphan candidate when its own directory\nis already referenced by an attachment from the current scan window. Everything else is listed as\nunknown \/ not classified<\/em> instead of being called orphaned, because a wrong \"orphan\" label is worse than no label.<\/p>\n\nUseful after a migration, a backup restore, a host move or an offload\/CDN change, and as a sanity check before\nrunning any cleanup tool.<\/p>\n\n\n
\n- Upload the plugin folder to
\/wp-content\/plugins\/<\/code>, or install the ZIP through\nPlugins -> Add New -> Upload Plugin.<\/li>\n- Activate the plugin.<\/li>\n
- Go to Tools -> Fruti Media Integrity Audit and press \"Run audit\".<\/li>\n<\/ol>\n\n
How to use it<\/h4>\n\n\n- Open Tools -> Fruti Media Integrity Audit.<\/li>\n
- Press Run audit<\/strong>. The plugin checks the attachment window and scans the uploads window you configure under\n\"Advanced: scan window\" (the defaults are safe for most sites).<\/li>\n
- Read the two result groups. Missing files are checked exactly: WordPress metadata says the file should exist\nand it does not.<\/li>\n
- If the notice says the file scan hit its per-run limit, the window is partial - raise the file offset and run\nagain to inspect the rest.<\/li>\n
- Press Download CSV for this window<\/strong> to export the current results. The CSV is generated on the fly and is\nnever stored.<\/li>\n<\/ol>\n\n\n
\nI migrated or restored my site and images are missing. What should I do?<\/h3><\/dt>\n\n- Run the audit and read the Missing files<\/strong> list. Those are the files WordPress expects at exact paths - they\nare what makes images (and their thumbnails) disappear.<\/li>\n
- Look for the same relative paths in a recent backup, on the old host or in your hosting file manager, and copy\nthe files back to those same paths. Do not delete the attachments: their metadata is still correct, so\nrestoring the file is usually enough.<\/li>\n
- Treat Orphan candidates<\/strong> as candidates only. Check a few in the Media Library before removing anything, and\ntake a backup first.<\/li>\n
- Leave Unknown \/ not classified<\/strong> alone. Those files are outside this scan window or cannot be attributed\nsafely.<\/li>\n
- Nothing needs to be \"repaired\" by this plugin: it reports, and you decide with the tool of your choice.<\/li>\n<\/ol><\/dd>\n
What to do after the report?<\/h3><\/dt>\nThe report is a diagnosis; nothing on your site has been changed. Take a full backup before any repair or\ncleanup, restore genuinely missing files from a backup where you can, verify candidates by hand before deleting,\nand leave unclassified files untouched. If a migration tool moved your files, fix the files or their paths, not\nthe attachments.<\/p><\/dd>\n
Does this plugin delete or fix anything?<\/h3><\/dt>\nNo. It is strictly read-only: no deletion, no import, no thumbnail regeneration, no metadata change, no automatic\nrepair. Fixing is a decision you make with another tool, after reading this report.<\/p><\/dd>\n
Can it see files outside my uploads directory?<\/h3><\/dt>\nNo. It only inspects the uploads tree that WordPress itself reports, it never accepts a path from the browser, and\nsymlinks are not traversed.<\/p><\/dd>\n
Why are some files listed as \"unknown\" instead of orphaned?<\/h3><\/dt>\nBecause the plugin refuses to guess. If a file's directory is not referenced by any attachment in the current\nwindow, the plugin cannot tell whether the file is unused or simply belongs to a part of the library outside this\nwindow, so it reports it as unknown.<\/p><\/dd>\n
What happens on very large media libraries?<\/h3><\/dt>\nEach run is bounded: a limited number of attachments and files are processed per run, nothing is loaded into\nmemory in full, and the screen tells you when the window was partial so you can continue manually. There is no\nbackground job and no cron.<\/p><\/dd>\n
Privacy<\/h3><\/dt>\nEverything runs locally inside your own admin request. Filenames, paths and results are never uploaded, never sent\nto any external service, never logged and never stored in the database. The plugin makes no network requests and\ncollects no telemetry.<\/p><\/dd>\n\n<\/dl>\n\n\n
1.0.1<\/h4>\n\n\n- The results screen now ends with a short \"What to do next\" guidance block: what missing files, orphan candidates\nand unknown files each mean, and the safe order of actions (backup first, restore files, verify candidates by\nhand, leave unknown files alone).<\/li>\n
- The first screen explains what will be checked and that nothing will be changed; the scan-window fields moved\nunder \"Advanced: scan window\". Defaults and scan behaviour are unchanged.<\/li>\n
- Honest result presentation: when a table shows the first 200 rows the screen says so and points to the CSV; the\nsummary labels the derived count as \"counted, not listed\"; the scan-window term is explained in one line.<\/li>\n
- A clean window is now reported as a success notice instead of three \"nothing to report\" lines - without claiming\nanything about the parts of the library that were not scanned.<\/li>\n
- This readme and the listing now lead with the problem (images missing after a migration or restore) instead of\nthe implementation.<\/li>\n<\/ul>\n\n
1.0.0<\/h4>\n\n\n- First release: read-only report of Media Library files missing from disk and uploads files that no attachment\nclaims, with a conservative unknown group, a bounded scan window and a CSV export.<\/li>\n<\/ul>","raw_excerpt":"Images missing after a migration or restore? See exactly which Media Library files WordPress expects but cannot find on disk - and change nothing.","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/bal.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin\/377492","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/bal.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin"}],"about":[{"href":"https:\/\/bal.wordpress.org\/plugins\/wp-json\/wp\/v2\/types\/plugin"}],"replies":[{"embeddable":true,"href":"https:\/\/bal.wordpress.org\/plugins\/wp-json\/wp\/v2\/comments?post=377492"}],"author":[{"embeddable":true,"href":"https:\/\/bal.wordpress.org\/plugins\/wp-json\/wporg\/v1\/users\/frutilabs"}],"wp:attachment":[{"href":"https:\/\/bal.wordpress.org\/plugins\/wp-json\/wp\/v2\/media?parent=377492"}],"wp:term":[{"taxonomy":"plugin_section","embeddable":true,"href":"https:\/\/bal.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_section?post=377492"},{"taxonomy":"plugin_tags","embeddable":true,"href":"https:\/\/bal.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_tags?post=377492"},{"taxonomy":"plugin_category","embeddable":true,"href":"https:\/\/bal.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_category?post=377492"},{"taxonomy":"plugin_contributors","embeddable":true,"href":"https:\/\/bal.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_contributors?post=377492"},{"taxonomy":"plugin_business_model","embeddable":true,"href":"https:\/\/bal.wordpress.org\/plugins\/wp-json\/wp\/v2\/plugin_business_model?post=377492"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}