As a website editor I want to find out which media asset (image, video, etc) is used on which pages / posts

[abitofmind]

Time flies…

• You drag'n'dropped image 1 to page A in the editor. Later maybe deleted page A.
• You upload image 5 to the media library for now, and want to make blogpost X later, which you forget about.
• And so on…

Challenge…

1. Main use case: After some time your media library is a mess and you want or have to clean up!
2. Other possible use cases: Another person (co-editor who checks style consistency, photographer who licensed photos to you, advertiser/partner) inquires: Gimme a statistic on which pages pics nr. 200, 300 and 500 are used.

The only utility function (as of WordPress 6.1.1)

• Look at "Uploaded to" field in the media detail page, if you work on a pic by pic basis.
• Or "Uploaded to" column in the list view of the Media Library, if you work in an analytic/systematic fashion.
• But that's about it, and helps only for attached images (minority of use cases!)
• Not for: Featured images, images first uploaded to media library and then embedded, galleries, etc. For those you have no clue whatsoever!

See attached

• Problem: As annotated screenshots
• UX Design Proposal: Mockup for first MVP: 2-3 extra columns for the list view:
  • "Use Count" — Easily find all the orphans (0) or the frequently used ones (higher count)
  • "Used in these slugs" (pro: clustered hierarchically if slug has category/path above it)
  • Alternatively "Used in these titles" (clustered A-Z by post/page title with whitespaces)

[audrasjb]

Hello and thanks for the proposal!

This looks like a nice feature for a plugin. While I can definitely see some real-life use cases, I think it's plugin territory. At the very least, Core could implement something as generic and harmless as the "Use count" column, but the "Used in" is another story: it would require big reverse queries on both post_content and post metadata, and when a media is used in a big amount of posts, it would quickly become an UI nightmare :)

[abitofmind]

Thanks for your assessment that:

• "Use count" is probably possible in Core.
• "Used in these slug(s)" is rather 3rd party plugin territory.
  • Is there an established market/place in the WordPress sphere where to put "plugin idea for adoption"
  • as in: "Offering: Detailed concept for plugin for free. Looking for: Volunteer/paid/partnering plugin developer" ?

Regarding UI nightmare and performance:

• As a UX designer I would agily collaborate with the developer to find a feasible solution.
• A compromise between usability and performance.
• In my mockup result °1 shows the first 4 slugs max and a "6 more >" expander link, which would only load on click (via AJAX).
• And many more adaptions, that's my daily job.
• And in later plugin versions: Further tools to not only analyze problems but also fix them: Individually or in batch.

But first: MVP — Wanna give it a scope and a try?

• Media Library List View: "Use Count" column
• Media Detail Page: "Use Count" + "Used in these slugs" then the reverse query is a lesser performance problem, only happens for this media object.
• What do you say?

[abitofmind]

During my initial research for this had I found no existing plugins for this.

• Good news: The free plugin ​Media Library Assistant seems to do much of what my MVP proposes.

• It's a complex plugin. I continue my evaluation & tests. Will share here when I have more details.

[Mista-Flo]

@abitofmind There is also this plugin from a french web agency: ​https://github.com/BeAPI/bea-media-analytics Does not seem maintained anymore but might still work.

I agree with @audrasjb it will be quite tricky to maintain good performances for large websites so not sure that should be something supported by default by core despite the interesting use case of the feature

[abitofmind]

@Mista-Flo thanks for sharing ​BEA – Media Analytics! Comes really close to my MVP!

• Media Library List View has "Use" count column

• Media Detail Page shows page/post title links + embedding method (Post content, Post thumbnail, Advanced Custom Fields)

• As you said: Last plugin update 2017/ 2018 and tested up to WP 4.9.22.
• Question is whether that will work well with Gutenberg created content.
• I will give it a try.

Now some real core related question:

• Both plugins have columns in the Media Library List View but those columns cannot be used for sorting
  • Use (count) in ​BEA – Media Analytics
  • Columns Featured in, Embedded in, Gallery in in ​Media Library Assistant
• That as a UX designer and QA tester (bu no dev) leads me to the following suspicion:
  • They can only sort the media library by DB keys that WordPress provides to them, e.g. by ID, media title, filename, date, etc.
  • Then for the current pagination view, they look up all media entries and per each media entry get back the necessary infos. So look up "media-ID 123" and get back "present in page 456 as featured image" + "present in post 789 as embedded image".
• So for a sortable column like Use or Featured in Embedded in, Gallery in the database would need to manage those, so that it's ready for normal DB sorting operations. And not dynamically each time (impossible for huge pagination-sizes or full datasets).

• This to me sounds very much like core responsibility.
  • 3rd party plugins may then take care of various UI integrations.
• But the backend itself -- if supposed to be efficient -- must be updated in an event driven manner (when media objects are manipulated and when page markup with media object changes). Because if doing this as a cronjob or on demand oneshot indexing then this info always only reflects the last manual indexing, rarely the current status.
  • So is the foundation for said columns purely core territory?
  • Or are hooks for said event based maintenance available to plugins?

[abitofmind]

Sadly BEA – Media Analytics dies with a fatal error on WP 6.1.1

• Reported this to their ​WP 6.0 Github issue.
• Anyone interested may also express interest in WP 6.x support over there (comment, upvote)

The interesting thing I noted: After plugin installation when going to the Media Library or the Media Detail Page then on top there is a banner saying:

As BEA - Media Analytics plugin has been activated, the process of indexing contents will silently launch himself [sic!] soon. [Note: It never does on WP 6.x due to the fatal error]

It mentions indexing. So probably they create proper persistence of the needed infos to the database and not only query recursively during runtime.

[audrasjb]

Hello, closing this as wontfix, as the global feature belongs to plugin's territory :)

Related discussion can still happen even here is the ticket is closed.

[abitofmind]

To me the closing feels premature:

I attempted to get a feasibility estimation from you devs/experts whether sort-able columns like "Use count" or "Embedded in" are technically feasible with the methods and hooks that core provides to plugins. If so, then close the issue for good. But if something fundamentally for this is missing in Core, then there should be a discussion (with experts, not me) whether and how core could provide this. Hence I had asked:

If supposed to be efficient -- it must be updated in an event driven manner (when media objects are manipulated and when page markup with media object changes)

Because if doing indexing as a cronjob or oneshot then this info always only reflects the last manual indexing, rarely the current status.

Does core provide hooks to plugins for said event driven DB maintenance?

What I observed from the plugins:

• Media Library Assistant → Uses normal sorting & likely reverse queries for the paginated results during runtime.
• BEA Media Analysis → Mentions "indexing". This is the initial indexing. But how is the index updated in the future? Cronjob based? Or truly event driven? Could not observe the plugin further as the plugin dies fatally in WP 6.1.1. Could some DEV here look into its source code and tell whether it has any kind of event driven approach? To answer the question: Does Core provide enough for plugins, that sorting by the custom columns could work.