Deprecate file_get_file_references(). Move the logic to file.usage service

This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request → as a guide.

Did not test but looking at the code

For new properties think it would be nice to add typehints

CI failures in #69

Reading the CR and think it could use some tweaks. The 3 functions are deprecated but the before/after only referes to file_get_file_references() correct? And it's being replaced by dependency injection?

The other 2 seemed perfectly covered by the last sentence.

Change record updates still need to happen.

1. +++ b/core/modules/file/src/FileUsage/FileUsageBase.php
   @@ -18,13 +22,58 @@
   +  protected $references = [];
   

   Should this been a memory cache https://www.drupal.org/project/drupal/issues/3047289 🌱 [policy] Standardize how we implement in-memory caches Needs work

2. +++ b/core/modules/file/src/FileUsage/FileUsageInterface.php
   @@ -67,4 +69,30 @@ public function delete(FileInterface $file, $module, $type = NULL, $id = NULL, $
   +   * @param string $age
   

   Unless I'm missing something this param doesn't appear to work as described - its only used for the cache key

Adding related issues

🐛 file_get_file_references does not return correct results when using $field param Active
#1805690: file_get_file_references is rather bogus →

Reviewed this issue at the DrupalSouth sprint day.

There are some issues with the current implementation of file_get_file_references are still an issue with the current patch.

There are some issues with the optional parameters - namely

• #3361361: file_get_file_references does not return correct results when using $field param
• #1805690: file_get_file_references is rather bogus (the issue with $age is still an issue)

As previously noted in #64 core is not making use of this filtering ability - doing a review of contrib I could not find any usage of filtering by field, and could only find 1 usage of filtering by type ( https://www.drupal.org/project/protected_file → ). It may be worth discussing deprecating these without replacement?

Another possibility raised was that the function could be deprecated without replacement if core can provide a generic entity usage API. I have added a related issue #3361364 for this.

🐛 Private file download returns access denied, when file attached to revision other than current Needs work is the primary related issue I'd say, where I've pointed out similar things on extra arguments and also provided an implementation basically deprecates the age argument as well as it's done as a fallback and implicitly.

> Another possibility raised was that the function could be deprecated without replacement if core can provide a generic entity usage API. I have added a related issue #3361364 for this.

I don't think entity_usage as it is can replace this function, that's not the problem it's trying to solve. The problem it's trying to solve is figure out which field, if any (as it could be referenced by an old revision), references a given file so that field access can be checked on that as well.

Looks like we should postpone on 🐛 Private file download returns access denied, when file attached to revision other than current Needs work then.

When this is picked back up, we should use a memory cache bin instead of class property.

The existing implementation has a problem with returning stale / outdated data.

Here is a patch that shows the issue, its against core rather than the work here and not completed but most relevant is the test which would still be relevant for this approach. Leaving #72 as the displayed patch as that is still the relevant starting point once this is no longer postponed.

This is postponed on 🐛 Private file download returns access denied, when file attached to revision other than current Needs work but in https://www.drupal.org/project/drupal/issues/1452100#comment-15209547 🐛 Private file download returns access denied, when file attached to revision other than current Needs work @berdir suggested we do it the other way around so we can deprecate the arguments here?