Thisismyurl Image Support

Two things are probably going on. There is no top-level menu: the plugin adds columns to the Media list and one page under Media. And WordPress shows the Media screen as a grid by default, where there is no table and therefore nothing to add columns to.

Go to Media > Image Support and use the button there, or click “Your images” on the Plugins screen. Either one opens the list view and WordPress remembers the choice.

On the Media list view, just after the file name. If you are looking at the grid, switch to the list using the two small buttons at the top left of the Media screen.

The image is still listed in your library, with a name and a size, but the file itself is no longer on the server. You usually notice these as broken thumbnails.

It matters more than tidiness. A missing file still counts as an image without alt text, so it shows up as work to do, and nobody can describe a photograph that is not there. The overview page says how many of your undescribed images are actually missing files, so the number you are working from is honest.

This plugin only reports them. Deleting an entry is your call, and worth checking first, because a post may still be pointing at it.

Media > Image Support has a second tab, “Where images are used”, listing every image twenty at a time with the places a reference was found: as a featured image, in post or page content, in a custom field, in a site or theme setting, or in a theme or plugin file.

It exists because WordPress’s own “Unattached” filter answers a different question. post_parent records how a file was uploaded, not how it is used. Measured on a real 766-image library, nearly a quarter of “unattached” images were live on the site, and 86 attached images were absent from the post they were attached to.

“No reference found” means this search did not find one. It does not mean the image is unused. The site icon and the custom logo are recognised, but an image picked by ID inside a gallery shortcode, or in a store or form plugin’s own fields, is not. Page builders that keep layouts in their own tables, shortcodes that pick images at render time, and anything a plugin stores privately are all invisible to it. Check where an image appears before deleting it. The plugin only reports; it never deletes anything.

It sends nothing anywhere. There are no external requests of any kind, no analytics, no telemetry, no licence checks, and no calls home. The plugin will work with the server disconnected from the internet.

What it stores on your own site, all of it removed when you uninstall:

• A number against each image, being the file size, so the Media list can sort by it.
• Two settings: the oversize multiplier and the large-file threshold.
• One reading a day of its own counts, kept for a year, so progress can be compared.
• Short-lived caches of what its scans found, so a page load does not repeat the work.

None of that is personal data. The daily readings are counts, not lists. The scans read your posts, custom fields, settings and theme files looking for file names, but they keep only which category a name was found in, never the content they searched.

Your alt text is the exception, and it is not really this plugin’s data: it goes into the field WordPress has always used, so it stays exactly where it is when the plugin is removed.

Facts rather than faults. The size of the library and how much of it is generated thumbnails, image files in the uploads folder that no attachment accounts for, likely duplicates, images with no recorded uploader, the formats in use, how many sizes your site registers, whether upload scaling is switched on, and whether uploads are organised by year and month.

None of it is a problem list. It is the set of things somebody taking over a site would otherwise have to work out by hand.

One reading is kept per day, taken when somebody opens the page. There is no scheduled task and nothing runs in the background, which means days when nobody looked have no reading at all. That is worth knowing before you read the trend.

Readings are kept for a year and can be downloaded as a CSV for any date range. The file is built when you ask for it, holds only the numbers shown on the page, is never written to the server, and is not sent anywhere.

Because a list of file names invites deleting them, and a good proportion of them should not be deleted. Some are sizes left behind when a theme changed the sizes it asks for, and the image they belong to is perfectly healthy. Others belong to a plugin that manages its own directory. Showing the folders tells you where to go and look without implying that everything listed is rubbish. Administrators can open each folder to see the files inside it, linked so you can see what one actually is. Anyone else sees only how many there are. Folders that form and store plugins use for private files are left out of the scan, and so are other sites’ uploads on the main site of a network.

Two numbers, on the Settings tab of Media > Image Support, both requiring an administrator: the oversize multiplier, which decides how much wider than your largest served size an image has to be before it is flagged, and the large-file threshold in megabytes. Everything else is a developer filter, because it is either derived from your site’s own registered sizes or not a decision a site owner has a reason to make. Changing either number only changes which images get marked; it never changes an image.

No. Nothing about your image files is altered, moved or re-saved. The only content this plugin changes is alt text, and only when you type it.

It stays. Alt text is stored in WordPress’s own field, exactly where the attachment editor and every other plugin looks for it. Uninstalling removes the file-size index this plugin builds for sorting, the daily readings, the saved results and the two settings above, on every site of a network. Nothing else is touched.

Because it would be a lie. Width and height are stored inside a serialized blob that the database cannot sort on, and offering a sort control that quietly did nothing would be worse than not offering it. File size is sortable because this plugin maintains a separate numeric index for it.

An image more than one and a half times wider than the largest size your site will ever serve, which on a default install is 2048 pixels.

That number comes from measuring rather than guessing. Since WordPress 5.3, uploads are scaled down to 2560 pixels automatically, so an ordinary photo you upload today sits at about 1.25 times the yardstick and is perfectly healthy. Anything much past that did not come through the normal upload path: it predates the scaling, it was imported directly onto disk, or the scaling was switched off. Those files are often several thousand pixels wide and nothing in WordPress points them out.

The multiplier is a setting on Media > Image Support, where the page also shows you the resulting pixel width so the number means something. It will not go below 1.3, because below that it would start flagging ordinary healthy uploads. Developers can override it with the timu_image_support_oversize_threshold filter, and change the yardstick itself with timu_image_support_widest_width . A filter always wins over the setting. The full list is under “For developers” below.

Seeing none at all is the normal result on a well-kept library, and it is worth knowing that rather than wondering whether the feature works.

The columns, the alt filters and the library measurement scale fine. The measurement reads attachments in batches, up to 50,000 of them, and holds a short file name for each file it finds, so memory use grows with the library at roughly 100 bytes a file. Past that limit the page says so and leaves the untracked-file count out rather than guess. Two checks have to read each file or its metadata, so they look at the newest 2,000 images: oversized originals and images with no file. On a library larger than that the page says so, and those two numbers are a minimum. The “where images are used” scan examines the newest 5,000 images, reads your content in pages, and says so when part of your site could not be read, because “no reference found” is not worth much then. Results are kept for an hour, and every limit can be changed with a filter.

Only if your role lets you edit that attachment. The check is per image, not a blanket permission, so contributors do not gain the ability to edit other people’s uploads.