An earlier incarnation of this bug had been fixed (via a hack in media_file_load()), but has been re-introduced due to (necessary) refactoring of D7 core's file usage API in #353458-153: hook_file_references() was not designed for a highly flexible field storage. We now need new (hopefully less hacky) code to not count a media entity's own file field as usage of the file. Working on it...

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

effulgentsia’s picture

By the way, #911130: Implement the new file_usage API is another issue related to the file usage API change in core, but that's a different issue.

effulgentsia’s picture

Assigned: effulgentsia » Unassigned
Status: Active » Needs review
FileSize
3.01 KB

Can it really be this easy? Seems to work in my testing.

JacobSingh’s picture

Looks good, but what about on update? hook_file_update()

Also, "implementationally" is not a word... just sayin' :)

effulgentsia’s picture

Improved docs. Or at least, removed "implementationally".

what about on update? hook_file_update()

Usage isn't incremented when a file is saved. It is only incremented by file_field_(insert|update)() when an entity containing a file field is saved. We're only interested in hooking into media entities being saved, or more precisely, anywhere field_attach_(insert|update)('media', $media) is called. We could do it as media_field_attach_(insert|update)() (i.e., implement hook_field_attach_(insert|update)()), but that's not the pattern in Drupal core. Those hooks are for other module to act, but here, we need media module to act on its own entities. In general, ENTITYMODULE_save() should be the only code that calls field_attach_(insert|update)() for its own entity type, and this pattern is followed in core. Therefore, media_save() should be the only place where the self-referential-usage needs to be removed. However, media_save_attached_file() also calls field_attach_(insert|update)('media', $media). It shouldn't: it should call media_save() instead. But that's for another issue, so I added a @todo about that.

JacobSingh’s picture

Status: Needs review » Reviewed & tested by the community
effulgentsia’s picture

Status: Reviewed & tested by the community » Fixed

Committed to CVS.

Status: Fixed » Closed (fixed)

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

brunodbo’s picture

Version: 7.x-1.x-dev » 7.x-1.0-rc3
Status: Closed (fixed) » Active

I'm seeing this again in 7.x-1.0-rc3. The file_usage table isn't updated, even though a certain file isn't in use anymore.

ellishettinga’s picture

subscribing

adam-delaney’s picture

subscribing

wickwood’s picture

I was able to delete all (~20 images and a couple of videos) but 3 images. I've also deleted all content and several content types that would use these images. On of the images I can't delete was the default image for one of the content types I deleted.

I wonder if it is possible for the module to also tell us where the media is being used when a image is still in use. However, in my case all the content for the site has been removed already.

Thanks for your help and hard work on this issue in advance! Wish I could be of more help.

Steve

mpgeek’s picture

Assigned: Unassigned » mpgeek
Status: Active » Postponed (maintainer needs more info)

I concur with @wickwood here: deleting seems to work just fine using 7.x-1.1 or 7.x-1.x-dev with Drupal 7.14: the file_usage table updates as you would expect under various use cases. Does updating the latest 7.x-1.1 (or dev) fix the issue?

katannshaw’s picture

My setup: Drupal 7.13 / SQLSrv / PHP 5.3
(Note: Drupal 7.14 and SQLSrv aren't working together right now, so I'm stuck with 7.13 for now)

I tried installing Media 7.x-1.1, but have had problems. This is what I did:

1) Add new field to article content type for media image
2) Added image (logo.jpg) to a specific article
3) Tried to change the properties to a thumbnail, but it wasn't viewable. I had to keep it as "Original".
4) Removed that field from the article content type all-together
5) Tried to delete the logo.jpg file, because I didn't have use for it anymore.

When I did that, I received this error: The file logo.jpg is in use and cannot be deleted.

Per mpgeek's suggestion, I just uninstalled 7.x-1.1 and installed 7.x-2.x-dev to see if that would work, but the error still occurs when I try to delete that image: The file logo.jpg is in use and cannot be deleted.

Just a note, it was not only removed from the article that it was originally on, but I removed the image field all-together from that content type, and I'm still getting that error. It's not being used anywhere else, so I'm at a loss.

mpgeek’s picture

Assigned: mpgeek » Unassigned

I'm still unable to reproduce the unable-to-delete problem with 7.x-1.1 or 7.x-1.x-dev. In fact, when i remove the image from the only node it's used on, it gets deleted itself (rerun of #12). If you are going to use 1.x, i would completely uninstall (disable + uninstall either in the UI or with drush, and dont forget cache clear for good measure), then pull down fresh 7.x-1.1 (or 1.x-dev) reinstall and try again.

Regarding trying 2.x, when i upgraded from 1.x to 2.x i had to do some monkeying with drush to make it work without losing my field setups. I'm not certain that you can just delete the module, pull down 2.x, run update and have it work. It didn't for me; you might try a dry drupal instance with a fresh install of 2.x and see if the unable-to-delete problem goes away.

mpgeek’s picture

Status: Postponed (maintainer needs more info) » Active
Reg’s picture

Just my 2 cents worth, if it believes that a file is in use then it should list all the places that are using the file (usually just one but sometimes more) along with a link to that item (when at all possible).

This does two things:
a) provides functionality you intuitive expect to be there;
b) doubles as a diagnostics tool to fix these issues.

Dave Reid’s picture

Yep we are working on that with #1286508: Provide a file usage report tab at file/%file/usage in File entity 7.x-2.x. We're not adding new features to 7.x-1.x at all.

mpgeek’s picture

Status: Active » Closed (cannot reproduce)

Feel free to open this issue back up if steps to reproduce can be documented. Tried again for the specific issue in #13, and no errors were found.

katannshaw’s picture

Status: Closed (cannot reproduce) » Active

After looking into it further, I believe for the that the Media module has an issue with working with media items added to content types *before* the module is installed. When I use the module on a logo using the "Media file selector" instead of the "Image" widget, it's able to be deleted from the content type without a problem. So I'm wondering if with this module, the media item must be created using the "Media file selector" widget in the first place to be used within the module. If this is the case, it's too bad, but it's also working as expected I would (dare I say) assume.

After (possibly) figuring that out, here are some related issues:

  1. Resizing an image: I don't see how I can resize the images within the media browser, and when I attached the logo from my computer, no re-size options were presented by the module. Is that located elsewhere that I cannot see?
    Please Note: I like that with the built-in Image widget, you can setup different image views, and apply those to images to be displayed within a content type. I was hoping that there was a similar functionality within this module.
  2. As noted by Mpgeek, when I deleted the logo from the article, it was also completely removed from the library. Is this the intention of the module?
  3. The error messages displayed are extremely vague, and not helpful to the user. I see from other posts that this is being worked on, which is great.
Dave Reid’s picture

Status: Active » Closed (works as designed)

4) Removed that field from the article content type all-together
5) Tried to delete the logo.jpg file, because I didn't have use for it anymore.

This problem would still occur even if Media was not used (just that Media exposes the UI for deleting files) - so this is a core bug that it doesn't remove field usage for files whenever a file or image field is deleted.

Resizing an image: I don't see how I can resize the images within the media browser, and when I attached the logo from my computer, no re-size options were presented by the module. Is that located elsewhere that I cannot see?
Please Note: I like that with the built-in Image widget, you can setup different image views, and apply those to images to be displayed within a content type. I was hoping that there was a similar functionality within this module.

This is not functionality that exists or will be provided by Media module. Note that if you have an Image field you can still select how the files/images in that field are displayed in the node type's 'Manage display' tab and by selecting the 'Image' formatter for the field with the desired image style.

As noted by Mpgeek, when I deleted the logo from the article, it was also completely removed from the library. Is this the intention of the module?

This functionality is an assumption in Drupal core and isn't something that Media introduces or changes. We're still debating the proper way to work around this or how/if it should be worked around.

At this point we should probably still leave this issue closed and file new issues for anything separate.

katannshaw’s picture

Status: Closed (works as designed) » Active

Very good. Thanks to you both for your help and clarification on how this module works. It's hard being a newbie at times:)

katannshaw’s picture

Status: Active » Closed (works as designed)

Sorry; not sure why that was selected.

mpgeek’s picture

dan2k3k4’s picture

Version: 7.x-1.0-rc3 » 7.x-1.3
Priority: Normal » Major

I'm unable to delete images that seem to show as 0 bytes and not in use anywhere? How can I delete manually instead?