Improve Media Library's "Attached" status to reflect actual usage in posts/pages, not just direct uploads.

[sr33hgs]

Currently, WordPress marks media files as “attached” only if they are uploaded directly into a post or page using the Add Media button. However, if a user uploads media to the Media Library first, and later inserts it into a post or page, the file remains labeled as “unattached” - even though it's actively in use.

This behavior causes confusion, especially for users managing large amounts of media or trying to free up storage. It also leads to the false assumption that “unattached” media is unused and safe to delete.

Steps to Reproduce:
Create a new post and upload an image directly inside the post editor.

Save the post.

Visit the Media Library, filter by Unattached.
→ The image is correctly not shown in the “Unattached” filter.

Now, upload a different image directly to the Media Library.

Insert that image into a post by selecting it from the Media Library.

Save the post.

Return to the Media Library and filter by Unattached.
→ The inserted image still appears as Unattached, even though it's now used in content.

Expected Result:
Any media item inserted into a post or page—regardless of whether it was uploaded through the editor or Media Library—should be marked as “attached.” Ideally, it could also display which post/page it is attached to.

Actual Result:
Only media uploaded directly to a post is considered "attached." Media added via the Media Library remains "unattached," even if inserted into content.

Users expect “attached” to mean “in use,” but the current system reflects only a technical upload path.

[sr33hgs]

I came across an earlier ticket that discusses similar concerns: https://core.trac.wordpress.org/ticket/53159 - since that one is over 4 years old and didn’t lead to any updates, I wanted to revisit the issue, focusing more on the practical impact for users managing media and storage.

If the current attached/unattached status is not intended to reflect media usage in content, could we consider introducing an alternate way in Core to track which media files are actually unused? This would greatly help site owners understand what’s safe to delete - especially on sites with storage limits or large content libraries.

[pbiron]

Thank you for raising this issue and opening this ticket. Welcome to trac!

Replying to sr33hgs:

If the current attached/unattached status is not intended to reflect media usage in content

"attached/unattached" is, in fact, not intended to reflect media usage in content. It means whether or not the media was uploaded to a specific post, that is all.

I don't know the history, but I suspect that is the reason for the Attached/Unattached/Detach language instead of "Used/Unused".

could we consider introducing an alternate way in Core to track which media files are actually unused? This would greatly help site owners understand what’s safe to delete - especially on sites with storage limits or large content libraries.

A number of years ago (pre-block editor days) I tried to write a plugin that did just that. I eventually gave up on that plugin because it is very difficult (if not impossible) to do so reliably.

It's easy to tell whether a given attachment is directly used within post content, but it's the indirect usages that are hard/impossible to detect reliably.

Consider a post that uses a shortcode registered by some plugin. Core doesn't know whether that shortcode will use a specific attachment. The tactic the plugin I was writing used was to define a filter that plugins registering shortcodes (or themes that use images in templates) could hook into and their callback for that filter could indicate whether the given attachment was used. But even that proved unreliable. For instance, some shortcodes allow users to add "content" in their shortcode (e.g., [Plugin_A_shortcode]some user entered content [Plugin_B_shortcode] other user entered content[/Plugin_A_shortcode]. So even if Plugin A hooked into that filter, if Plugin B did not hook into that filter, the results would be unreliable.

With the block editor the problem became worse given template parts, reusable blocks, etc.

Another tactic would be to render every post on the site and search the rendered HTML for the URL of the attachment. That might be reliable (I never tried it), but would be extremely inefficient, likely making the Media List table impractical to use.

Thus, the goal of knowing when it is safe to delete a given attachment because it is not used anywhere on the site is really a no-win situation.

I would love to have a practical solution to that, but I don't think one exists.