Problem/Motivation
Drupal Core API provides a file.usage service that provides the ability for developers to track file usage of a specific file in different places and for different purposes.
This service implements \Drupal\file\FileUsage\FileUsageInterface that describe adding file usage as:
/**
* Records that a module is using a file.
*
* Examples:
* - A module that associates files with nodes, so $type would be
* 'node' and $id would be the node's nid. Files for all revisions are
* stored within a single nid.
* - The User module associates an image with a user, so $type would be 'user'
* and the $id would be the user's uid.
*
* @param \Drupal\file\FileInterface $file
* A file entity.
* @param string $module
* The name of the module using the file.
* @param string $type
* The type of the object that contains the referenced file.
* @param string $id
* The unique ID of the object containing the referenced file.
* @param int $count
* (optional) The number of references to add to the object. Defaults to 1.
*/
public function add(FileInterface $file, $module, $type, $id, $count = 1);
The $type and $id, according to that documentation, can be any string.
For example, I have a form to upload product prices. I track those files by set $type = 'form' and $id = $this->getFormId(). Because this file used by that form, not by specific node or user.
The API (service) allows me to do that and works perfectly, but Views integration doesn't.
In \Drupal\file\FileViewsData::getViewsData where file usage is linked it says "Relate file entities to their usage.". But there is no requirement that usage will be linked on entity type, but views assumes that, and the leads to HTTP 500 error for such usages.
For example above, views trying to load entity type 'form' and end with fatal error:
Drupal\Component\Plugin\Exception\PluginNotFoundException: The "form" entity type does not exist. in Drupal\Core\Entity\EntityTypeManager->getDefinition() (line 150 of core/lib/Drupal/Core/Entity/EntityTypeManager.php).
Steps to reproduce
1. Add file usage linked to anything except entities:
$file = File::load(1);
\Drupal::service('file.usage')->add($file, 'example', 'form', 'my_awesome_form');
2. Go to /admin/content/files/usage/1
3. You will see HTTP 500 because Views trying to load entity type 'form'.
The \Drupal\file\FileUsage\FileUsageInterface::listUsage works as expected:
[
'example' => [
'form' => [
'my_awesome_form' => '1',
],
],
]
Proposed resolution
1. Improve Views integration and remove the requirement for type to be an entity type ID, because this is not required by an API. Show those usages without any links.
2. Change API and description for \Drupal\file\FileUsage\FileUsageInterface::add so it requires $type to be entity_type_id.
I think, in current situation this is Views integration is only the problem, because API works as expected and very useful. Limiting it to the entities only, will make no sense for provided example and other use cases, because that file used by the specific form, not the specific user or entity type.
| Comment | File | Size | Author |
|---|---|---|---|
| #22 | 2024-02-08 10_37_15-File usage information for logo_drc_app_512.png _ Drush Site-Install.png | 3.02 KB | grevil |
| #19 | 3187396-nr-bot.txt | 2.21 KB | needs-review-queue-bot |
| #16 | 3187396-12.patch | 4.78 KB | nikhil_110 |
Issue fork drupal-3187396
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 #2
niklanComment #3
batkor+1
i faced this a problem.
Comment #4
batkorThe temporary patch for solve this issues
This patch add new plugin for `entity_label` for `file_usage` table.
Comment #5
niklanI'm trying to write the fail test for that case and apparently found another bug, views results are duplicated.
Upload patch to see what Drupal CI says.
Comment #6
niklanWrong paths in previos patch :(
Comment #7
niklanomg, edited on windows and it appends .txt
Everything is going wrong with this test :)
UPD I wont trust creating patch for PHPStorm anymore. Will create proper one with CLI tomorrow.
Comment #8
batkorComment #10
andypostPatches should be hidden when using mr
Comment #11
andypostComment #16
nikhil_110 commentedPatch for 10.x
Comment #18
prem suthar commentedComment #19
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".
Apart from a re-roll or rebase, this issue may need more work to address feedback in the issue or MR comments. To progress an issue, incorporate this feedback as part of the process of updating the issue. This helps other contributors to know what is outstanding.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #21
welly commentedIgnore, change made was for 11.x not 9.5.x
Comment #22
grevil commentedThe patch works great!
Although one small thing, I think we should adjust the table headers to conform with the fileUsage "add()" API documentation:
So instead of this:

We should use the headers "Object ID" and "Object type".
Comment #23
anybodyAgree with #22, as "Entity type" would be wrong then after this fix.
Back to needs review!
Comment #24
smustgrave commentedLeft some small comments on MR,
Also new fields believe could use a change record to announce it.