Provide a file usage report tab at file/%file/usage

Here's a patch based on the above for version 7.x-1.0-rc3 . It's doesn't have all of the above patch's functionality but it has the most important, that being the summary of usage on the edit page.

What's the status of this patch? Has it been incorporated into a release yet?

@edward.kay: Quick answer - No.

In almost every case when a patch gets committed to the project code-base you will see a comment from a maintainer saying so. Generally also in combination with that status is changed to "fixed".

To help this patch get committed quicker you are of course welcome to test the patch and give feedback on how it works for you. Its much appreciated.

I'm guessing we could create a view that would show a tab for this "File Usage" on the file/[file:fid]? That could possibly allow it to be overwritten with a ViewsBulkOperations view? Similar to http://drupal.org/project/admin_views

Cross posting: #1497368: File "usage" tab - Reports usage and tools to manage file

... moved over one of the better thought out "file usage" feature requests from Media to File entity. It appears this patch is abandoned, so pointing people to the above one instead to get some eyes on it, and hopefully some useful input so it can get figured out.

Dave Reid and I discussed doing this with Views, but decided instead to do it in code.

The attached patch adds a "Usage" tab between the "Edit" and "Delete" tabs on the file page.

In my testing, the Count column on the Usage tab was not functioning correctly, but the problem seemed to be with the file_usage table not updating the count table (rather then a problem with this patch).

Patch in #9 works as expected, but there's a missing t().

Here is an edited version with slightly modified strings—according to davereid's recommandation on #drupal-media a few minutes ago.

I've updated the patch based on the suggestions in #10 and #11.

I downloaded this patch to try and find where media files were being used that I could not delete.

For these files if I tried to delete from /admin/content/media path, I get an error saying The file [name of file] is in use and cannot be deleted.

After installing this patch, I now have a new tab "Files" with the path /admin/content/file, and I can delete the file from this page.

However, if I click on Edit for the file from /admin/content/file this takes me to /file/%file/edit and then click on the usage tab which takes me to /file/%file/usage, I get the following error:

EntityMalformedException: Missing bundle property on entity of type node. in entity_extract_ids() (line 7539 of /path_to_my_install_Barracuda_Octopus_Aegir_platform/includes/common.inc).

I'm guessing because this media file isn't actually in use anywhere?

Also, if go to edit this media file from /admin/content/media page, it takes me to /media/%file/edit, and then I don't have the usage tab, but everything else on the edit page is the same.

I hope this helps with your development. Wish I could be of more help. At least now I've been able to delete these legacy files!

Good Luck and thanks for all of your hard work on this!!

Steve

Patch in #12 worked as stated. Thanks for the hard work! ^_^

I haven't run into the issue stated in #13. I get this message when media isn't used "This file is not currently used.".

I'm going to mark this as RTBC as I have tested it pretty extensively.

This attached is a patch for when #1227706: Add a file entity access API lands.

The access control for the usage page will be affected by that issue.

Is there any reason why the usage tab does not load in the overlay? Seems like it should be marked as an admin/overlay page like the other pages that provide admin level data/actions about the file. I have the following tabs at /file/1:

View (normal)
Edit (overlay)
Usage (normal)
Delete (overlay)

If Edit and Delete are shown in the overlay, shouldn't the Usage information be too? I would have thought that the usage information is primarily for he benefit of site administrations

- Checked things in #20. Solved first one with some more checks. The other two were OK.
- Added to admin paths.
- Added some comments.

+++ b/file_entity.moduleundefined
@@ -150,6 +150,16 @@ function file_entity_menu() {
+    'page arguments' => array(1),
+    'access callback' => 'file_entity_access',
+    'access arguments' => array('view'),
+    'type' => MENU_LOCAL_TASK,
+    'context' => MENU_CONTEXT_PAGE,

"View" is not a good permission, as it allows anonymous people, who will most likely be allowed to view files, to check usage as well. Changed to "edit". Should we add another permission?

I would agree that the Edit permission is definitely more appropriate than the View permission, especially as we now have the file usage list marked as an admin path (confirmed as working with latest patch).

In regards to "- How this page works when a file has usage for two different types with the same entity." from #20, it looks a but like this:

Personally I find this confusing. It should probably group by just type and id so that for example, files attached to the same node through both a file field and the wysiwyg show up as just one entry in the usage list, with a combined count. eg. In the screenshot above we should show just one row with a count of 3. Refer to my notes in http://drupal.org/node/1268116#comment-6386458 for more info about what was done to get that screenshot.

Aggregation added.

Aggregation tested and confirmed to be working nicely. Only question that I had left about the implementation is the use of entity_load(). This is being called for every single entity that uses the media, which would introduce some performance overhead. Considering that the only information that we need about the entity is its Label and URI, entity_load seems like overkill. However, I don't see an easy way of reliably getting that information for any entity type without doing the entity load, or reimplementing chunks of entity_label and entity_uri which would likely reduce the readability of the code substantially. This would likely only be an issue for large sites that reuse media heavily, and access this page - so not exactly common case.

You use entity_load() because of API concerns like hook_entity_info_alter() and others, which allow for better caching. :-)

See: entitycache for an example. Note that entitycache can cache file entities.

The fact that this happens in admin interface and not on front-end and the possibility to have few hundred or thousand entities that use same piece of being low is IMO enough not to worry about this too much. This will probably affect just a tiny portion of our users (if any at all), but this users will most likely use some way of caching things.

We can do some benchmarks if it will allow us to sleep better. What do you think?

#25: file_entity-usage-summary-1286508-25.patch queued for re-testing.

Patch in #25 tested and looked great.

Thanks for the patch it applied cleanly for me and seemed to do the job. I did notice it stopped working after applying
http://drupal.org/node/1227706#comment-6627060 - Add a file entity access API
That patch seems like the final outcome so this will need to be updated to work with that eventually. I will try to look at it tomorrow if I have time.

I just changed 'access arguments' => array('edit'), to 'access arguments' => array('update', 1),
I manually edited the patch file from #25 it should still work.

I think this is ready.
committed to 2.x
Thanks all
http://drupalcode.org/project/file_entity.git/commit/11894c1

Hey Guys,

I think it will be better if we can display the usage as a column in admin/content/file.
In case we have huge number of files, it will be hard to go into each file to see the usage. We can simply delete unused files in the file list with this feature. Or we already have this feature in other patches I missed?

Any thoughts?

Thanks.

@rli

I would suggest a new issue be created related to your suggestion.

I do agree that having the summary would be helpful.

However at this time the file I have still found the usage report not to be as accurate as I would like.