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.

Issue fork drupal-3187396

Command icon 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

Niklan created an issue. See original summary.

niklan’s picture

Issue summary: View changes
batkor’s picture

+1
i faced this a problem.

batkor’s picture

StatusFileSize
new1.99 KB

The temporary patch for solve this issues
This patch add new plugin for `entity_label` for `file_usage` table.

niklan’s picture

StatusFileSize
new2.67 KB

I'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.

niklan’s picture

StatusFileSize
new2.59 KB

Wrong paths in previos patch :(

niklan’s picture

StatusFileSize
new2.59 KB

omg, 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.

batkor’s picture

andypost’s picture

Status: Active » Needs review

Patches should be hidden when using mr

andypost’s picture

Status: Needs review » Needs work
Issue tags: +Needs reroll

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

nikhil_110’s picture

StatusFileSize
new4.78 KB

Patch for 10.x

VladimirAus made their first commit to this issue’s fork.

prem suthar’s picture

Status: Needs work » Needs review
needs-review-queue-bot’s picture

Status: Needs review » Needs work
StatusFileSize
new2.21 KB

The 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.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

welly’s picture

Ignore, change made was for 11.x not 9.5.x

grevil’s picture

The patch works great!

Although one small thing, I think we should adjust the table headers to conform with the fileUsage "add()" API documentation:

* @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.

So instead of this:
screenshot

We should use the headers "Object ID" and "Object type".

anybody’s picture

Status: Needs work » Needs review

Agree with #22, as "Entity type" would be wrong then after this fix.
Back to needs review!

smustgrave’s picture

Status: Needs review » Needs work
Issue tags: +Needs Review Queue Initiative, +Needs change record

Left some small comments on MR,

Also new fields believe could use a change record to announce it.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.