[PP-2] When Media entities are deleted, the associated files are not deleted.

For now, there is the contrib Media file delete → created by larowlan →

I post my own workaround here also because I occasionally land here via google when searching for a solution for this problem.

The workaround:
When a Media entity is deleted:
- get the File
- set the 'changed' date so its older than the temporary_maximum_age setting.
- run file_cron which should delete old temporary files

If your file remains permanent instead of changin to temporary after deleting the Media entity, then add this to your settings:
$config['file.settings']['make_unused_managed_files_temporary'] = TRUE;

/**
 * Implements hook_ENTITY_TYPE_delete().
 */
function mymodule_media_delete(Media $media_entity) {
  // Get original value of temporary_maximum_age (in seconds).
  $temporary_maximum_age = \Drupal::config('system.file')->get('temporary_maximum_age');

  // Get the file source value for the media entity.
  $source_value = $media_entity->getSource()->getSourceFieldValue($media_entity);

  // Validate if a file resource exists.
  if (!$source_value) {
    return;
  }

  // Load the File.
  $file_entity = File::load($source_value);

  // Set the File changed date to older than temporary_maximum_age.
  $seconds = $temporary_maximum_age +1;
  $past_date = new DrupalDateTime("-$seconds seconds");
  $file_entity->setChangedTime($past_date->getTimestamp())->save();
  
  // Run Cron so it deletes the temporary files.
  file_cron();
  
}

Thanks for getting this back on my radar. Reading the thread, I'm really not sure why we should postpone this.

files in media entities are typically only used once (in the media entity) and while the media entity might be referenced several times, the file typically is only referenced by the media entity.

I fully agree with this. In my experience, editors do not understand (I don't even think they should) that there is a difference between file/media entities when using media. I think the associated file should always be deleted when an editor deletes a media item. Some site setups might want their own rules. For those cases, we could add an option to configure this default behavior. For new sites, this is enabled by default. We should probably disable this for any existing sites to avoid regressions.

I don't even think we should show a checkbox like the Media file delete → module does. I think most editors won't really understand the implications of enabling or disabling the checkbox. Sure, the file would be removed from the file system (or not), but when/why would you choose to remove it?

I fully agree with this. In my experience, editors do not understand (I don't even think they should) that there is a difference between file/media entities when using media.

100% in agreement with this - at work we keep running into this issue where clients don't care about the architecture, they expect the media system to be tied exclusively to files and for operations on one to affect the other.

+1 for this!

Clients having an issue with deleting media items and not understanding that there is a related File that is not deleted is a recurring issue. Sometimes the issue comes up when clients notice having files like mypdf_0.pdf instead of their uploaded mypdf.pdf which then forces us to try to explain the difference between Media and Files, and the difference between temporary en permanent files etc and honestly, it is exhausting to do so.
I'm all for letting 'delete' actually mean 'delete' in the way anybody would think it is.
Also, If you have a small hosting, and you only have 100MB of free space, and you delete a Media item with a file of 60MB, then you should be able to create a new Media item with another file of 60MB, but in reality that will not work. Bad example to say that not actually deleting files when you do expect them to not only leads to confusion but also to unnecessary occupied disk space and 'ugly' versioned filenames containing '_0' or '_1' etc.

I dont know whats the best place to hold this debate, but I think this is an important issue to discuss and get a good number of people's opinions about it.

There's no need for a debate, everyone agrees with this. It was just decided to disable this feature by default, because the risk of losing files that *are* being used was considered a bigger issue than not deleting files that no longer are being used.

But it's a setting, already comment #3 explained how to change the setting. Which you need to do *before* deleting media items.

To move this forward, 🌱 Dealing with unexpected file deletion due to incorrect file usage Active and the known bugs around it need to be fixed. The only known issue atm is AFAIK related to translations, if you don't have a multilingual site, then you should be pretty safe. We have been switching the setting on dozens of sites with the patch from 🐛 $entity->isDefaultTranslation() behaves incorrectly when changing default translation, causing file/image field usage to be set to zero, causing files to be deleted Fixed and haven't seen any issues.

That said, there's a different set of issues related to having too many usages, in which case the file won't be deleted either, like 🐛 Deleting an entity with revisions and file/image field does not release file usage of non-default revisions, causing files to linger Postponed but that will only affect you if you are using revisions on media.

I agree that it is _not_ blocked by 📌 Track media usage and present it to the site builder (in the media library, media view, on media deletion confirmation, etc.) Active , that's would only be related to manual or automatic deletion of unused media items, that's a very different beast.