Once we move the media/[file:fid] pages to file/[file:fid] in file_entity, it would be nice to add a summary of how the file is used based on the file_usage table.

Files: 
CommentFileSizeAuthor
#32 file_entity-usage-summary-1286508-32.patch3.4 KBgooddesignusa
PASSED: [[SimpleTest]]: [MySQL] 110 pass(es).
[ View ]
#25 file_entity-usage-summary-1286508-25.patch3.39 KBslashrsm
PASSED: [[SimpleTest]]: [MySQL] 110 pass(es).
[ View ]
#24 Screen Shot 2012-08-24 at 10.36.45.png17.65 KBmrfelton
#22 file_entity-usage-summary-1286508-22.patch3.12 KBslashrsm
PASSED: [[SimpleTest]]: [MySQL] 106 pass(es).
[ View ]
#16 file_entity-usage-summary-1286508-16.patch2.52 KBJackinloadup
FAILED: [[SimpleTest]]: [MySQL] 106 pass(es), 0 fail(s), and 14 exception(s).
[ View ]
#12 file_entity-usage-summary-1286508-12.patch2.53 KBmtift
PASSED: [[SimpleTest]]: [MySQL] 106 pass(es).
[ View ]
#10 file_entity-usage-summary-1286508-10.patch2.42 KBPomliane
PASSED: [[SimpleTest]]: [MySQL] 106 pass(es).
[ View ]
#9 file_entity-usage-summary-1286508-9.patch2.42 KBmtift
PASSED: [[SimpleTest]]: [MySQL] 106 pass(es).
[ View ]
#3 media-usage-1286508-3.patch2.63 KBReg
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch media-usage-1286508-3.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#2 1286508-usage-summary.patch3.41 KBDave Reid
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1286508-usage-summary.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Comments

Dave Reid’s picture

Version:7.x-1.x-dev» 7.x-2.x-dev
Dave Reid’s picture

Status:Active» Needs work
StatusFileSize
new3.41 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 1286508-usage-summary.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Work in progress patch.

Reg’s picture

StatusFileSize
new2.63 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch media-usage-1286508-3.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

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.

edward.kay’s picture

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

tsvenson’s picture

@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.

gmclelland’s picture

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

mpgeek’s picture

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’s picture

Title:Provide a 'usage summary' on the file view page» Provide a file usage report tab at file/%file/usage

Let's merge #1497368: File "usage" tab - Reports usage and tools to manage file into this issue. I'd like to change direction and go with a 'Usage' tab as file/%file/usage which could either be a View or manual output.

Hello,
I have several large-scale clients who have been attempting to use the media module to manage their media libraries. Several of the assumed business rules that media (and to some extend Drupal core) attempt to manage are not configurable nor obvious.

I'd like to request a management report/management tab for each media element in the files management index. The management index I'm referring to is:

www.example.com/admin/content/file/list

When viewing a media file entity it would be very useful to have an addition tab next to:

view
The default state when clicking on a media element in the file manager.

Usage (count number)
New tab that lists the entities, nodes, etc that the file is being used within and what module defines the usage (media, linkit, insert, etc)

Delete
The standard delete confirmation tab.

Usage - management
It would be very useful to be able to jump to the node and or revision where the media element is referenced and "unlink" it. Or have a hard-line tool to override the usage count to orphan it from entities that linked to it.

Other tasks that are not easily accomplished:

The ability to update a file, not replace but upload over the top of a media file.
Define permissions for access: ala view, edit, delete.
Define if a file is private or public.
Anyone else have any ideas?
I'd prefer such functionality is centralised instead of spread through multiple modules and or sections of the file management area.

mtift’s picture

Assigned:Unassigned» mtift
Status:Needs work» Needs review
StatusFileSize
new2.42 KB
PASSED: [[SimpleTest]]: [MySQL] 106 pass(es).
[ View ]

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).

Pomliane’s picture

Assigned:mtift» Unassigned
StatusFileSize
new2.42 KB
PASSED: [[SimpleTest]]: [MySQL] 106 pass(es).
[ View ]

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.

Dave Reid’s picture

Status:Needs review» Needs work
+++ b/file_entity.pages.incundefined
@@ -57,6 +57,51 @@ function file_entity_add_upload($form, &$form_state, array $options = array()) {
+          l($label, $entity_type . '/' . $entity_id),

We should be using the result of entity_uri() here like the original patch was, rather than hard-coding the link URL.

+++ b/file_entity.pages.incundefined
@@ -57,6 +57,51 @@ function file_entity_add_upload($form, &$form_state, array $options = array()) {
+  if (empty($rows)) {
+    $rows = array();

Let's define $rows up above in the function as an empty array rather than having to check here.

+++ b/file_entity.pages.incundefined
@@ -57,6 +57,51 @@ function file_entity_add_upload($form, &$form_state, array $options = array()) {
+    '#prefix' => t('Below are the recorded instances where @filename is being used.',

This should actually be using '#caption'

mtift’s picture

Status:Needs work» Needs review
StatusFileSize
new2.53 KB
PASSED: [[SimpleTest]]: [MySQL] 106 pass(es).
[ View ]

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

wickwood’s picture

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

Jackinloadup’s picture

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

Jackinloadup’s picture

Status:Needs review» Reviewed & tested by the community

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.

Jackinloadup’s picture

StatusFileSize
new2.52 KB
FAILED: [[SimpleTest]]: [MySQL] 106 pass(es), 0 fail(s), and 14 exception(s).
[ View ]

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.

Status:Reviewed & tested by the community» Needs work

The last submitted patch, file_entity-usage-summary-1286508-16.patch, failed testing.

Dave Reid’s picture

Issue tags:+sprint, +Media Initiative
mrfelton’s picture

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

Dave Reid’s picture

Some things to check/test with this patch:
- How this page is output when using the File lock module which doesn't link files to any valid entity type.
- How this page works when a file has usage for two different types with the same entity.
- How this page works when the file usage has entities that do not return a value for entity_uri().

Dave Reid’s picture

Yes, file/%file/usage should be defined as an admin path.

slashrsm’s picture

StatusFileSize
new3.12 KB
PASSED: [[SimpleTest]]: [MySQL] 106 pass(es).
[ View ]

- 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?

slashrsm’s picture

Status:Needs work» Needs review
mrfelton’s picture

StatusFileSize
new17.65 KB

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:

Screen Shot 2012-08-24 at 10.36.45.png

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.

slashrsm’s picture

StatusFileSize
new3.39 KB
PASSED: [[SimpleTest]]: [MySQL] 110 pass(es).
[ View ]

Aggregation added.

mrfelton’s picture

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.

Mile23’s picture

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.

slashrsm’s picture

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?

ParisLiakos’s picture

raspberryman’s picture

Patch in #25 tested and looked great.

gooddesignusa’s picture

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.

gooddesignusa’s picture

StatusFileSize
new3.4 KB
PASSED: [[SimpleTest]]: [MySQL] 110 pass(es).
[ View ]

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.

ParisLiakos’s picture

Status:Needs review» Fixed

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

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

rli’s picture

Status:Closed (fixed)» Needs work

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.

HyperGlide’s picture

Status:Needs work» Closed (fixed)

@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.