Problem/Motivation
(Assume trash is enabled for both media and files)
When a media entity is deleted, and its associated files are deleted with it at the same time, restoring the media entity does not currently restore the deleted files. For example, when using the media_file_delete module, the user is given the option of deleting the associated file at the same time. If the user does this, and later restores the media entity, the file remains in the trash. This is unexpected, users expect files to be treated similarly to the way path aliases are handled when nodes are deleted, in that the media entity should be fully restored and usable.
Steps to reproduce
Enable Trash for both media and files. Install the media_file_delete module and delete a media entity and its file in one action. Restore the media entity. The file is not restored with it.
Proposed resolution
Add a media trash handler that restores any files previously attached to the media entity that were deleted with it (same delete timestamp).
User interface changes
Files do not need to be restored separately when they are deleted together with a media entity.
API changes
A new media trash handler is added.
Data model changes
None
Issue fork trash-3623650
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
john.oltman commentedComment #5
amateescu commentedThanks for the MR! The approach is right, restoring files that share the entity's deletion timestamp follows how the path alias and menu link integrations work. I pushed a follow-up commit that reworks a few things:
DefaultTrashHandler::postTrashRestore()for every entity type, next to the path alias and menu link integrations, instead of a media-only handler. A node with an image field trashed together with its file has the same problem, and the reference plus timestamp guard keeps it safe for any entity type.deleteAssociatedFiles(),isFileUsedByOtherEntities()and theFileUsageInterfaceinjection). If we want trash to delete files itself that needs its own issue, since it has to decide what happens with shared files.TrashFileIntegrationTestwith a shared fixture helper, plus a node file field case and a translated media case.createPublicFile()moved to the kernel test base soTrashFileTestcan use it too.This also needs to land on 3.1.x, which trashes and restores individual translations, so the handler API takes an array of timestamps keyed by langcode there. I'll open a separate MR for that, where files are paired with the translation that references them, so a partial restore never brings back a file that only belongs to a still-trashed translation.
Comment #9
amateescu commentedMerged both MRs, thanks again!
Comment #11
john.oltman commentedThanks for the quick turn! Do you have an idea of when 3.0.34 will come out?
Comment #12
amateescu commentedAs soon as #3623769: A path alias in the trash overrides an active alias at the same path is figured out, I like to create releases with a clean issue queue :)
Comment #13
amateescu commentedTrash 3.0.34 is out!
Comment #14
john.oltman commentedWorking great, thank you!