Problem/Motivation
Recently @catch, @webchick, @xjm, @cottser, @cilefen and I discussed #2801777: Give users the option to prevent drupal from automatically marking unused files as temporary , #2810355: $entity->isDefaultTranslation() behaves incorrectly when changing default translation, causing file/image field usage to be set to zero, causing files to be deleted and #2708411: [PP-1] editor.module's editor_file_reference filter not tracking file usage correctly for translations. We all agreed that the current file usage behaviour that is resulting in files being deleted when they are being used by a site is unacceptable and a critical issue.
This was also discussed at Drupal Dev Days Seville — see the meeting notes.
This issue is exist to propose a series of steps to mitigate and fix these related issues.
The current behaviour
As files are "used" in different situations we add to the counter in the file_usage table. As the usages are removed we subtract from the counter. Once the counter gets to 0 the file is made temporary in \Drupal\file\FileUsage\FileUsageBase::delete(). Then a cron process (file_cron()) comes along and deletes temporary files after system.file:temporary_maximum_age seconds.
There are several cases where that counter is not incremented or decremented correctly.
Regardless of all the sub-issues we have the known issue that this does not track usages added by content editors if they are able to add links to file but editing the source HTML. Also the system of maintaining a counter seems very fragile and evidence supports that :).
Which cases/issues are there?
These fall into clear buckets, along three axes:
- Field (image/file/entity reference) versus
editor.module'seditor_file_referencefilter - Entity revisions versus entity translations
- Data loss: yes or no
| Short description | Data loss? | Field or filter? | Revision or translation? | Issue | Notes |
|---|---|---|---|---|---|
| Deleting entity with revisions + image/file field | no | Field | Revision | #1239558: Deleting an entity with revisions and file/image field does not release file usage of non-default revisions, causing files to linger | No data loss, but irrepairable, therefore still critical. |
| Changing default translation + image/file field | YES | Field | Translation | #2810355: $entity->isDefaultTranslation() behaves incorrectly when changing default translation, causing file/image field usage to be set to zero, causing files to be deleted | This was caused by the "fix" for another critical: #2787187: Data loss: Deleting a translation of an entity deletes all file_usage entries for files referenced by the entity |
| The critical #2666700: User profile images unexpectedly deleted was merged into this — it has the same root cause, but different steps to reproduce. | |||||
| Generic entity reference fields | YES | Field | N/A | #2826127: Usage of Files Referenced in Entity Reference Fields Not Tracked | A missing feature. File usage support is only present on file and image fields, which subclass the generic entity reference field code. |
| Filter + translations | YES | Filter | Translation | #2708411: [PP-1] editor.module's editor_file_reference filter not tracking file usage correctly for translations | Was implemented using entity hooks before Translation API matured. |
| Filter + revisions + adding/removing images | no | Filter | Revision | #2892368: editor.module's hook_entity_update() does not count file usages correctly when adding/removing images without creating new revisions | The only "normal" priority issue here, because it cannot lead to data loss, and can be repaired |
The mitigation for all the rows with YESin the Data loss?column | N/A | #2801777: Give users the option to prevent drupal from automatically marking unused files as temporary | This is a mitigation for:
The downside: it becomes difficult to delete "unused" files, which can be a security problem (e.g. accidentally uploaded PDF with sensitive data, now how to delete it?). That's less of a problem than files just disappearing right under you though. Worst case, the site administrator could be asked to remove the file from disk manually. | ||
Proposed resolution
TBD
Remaining tasks
TBD
User interface changes
TBD
API changes
TBD
Data model changes
TBD