2

I got a ticket from our stakeholders that certain outdated PDFs are googlable, and this is causing problems with people going on old information.

Navigating to admin/content/files, I am able to find entities(?) for the files, by searching on their filename and extension (MIME type). There is also a seemingly handy column "Used In". However, when I click through the values in the "Used In" column (e.g. "2 places"), the paths are like render elements or something similiar: {Content Type} > Paragraphs (previous revision) > Column Content (previous revision) > Column Wrapper Content (previous revision) > Accordion Section (previous revision) > Accordion Section Body.

From this information, I am not able to navigate to the page where the file resides, in order to remove it.

Furthermore, one of the files is used in 0 places, and there appears to be no interface that allows me to delete it. I am able to open the PDF from the file path link in an incognito window, so I conclude that, even though a user can't discover this PDF by navigating on our site, they still might get to it through a google search.

My question is different from this similar question, How do I delete files the correct way?, because in that question, the asker already knows which node it is that contains the file they want to delete. In this case, I don't know where on the website the file is actually attached. I'm trying to get that information.

One proposed solution might be to google for the files, and find out where on our site they are from Google's search results, but I want to know how to delete these files through Drupal, so in a future case, where I can't find them through google, I still have a way to delete them.

Edit even after googling search terms for the files, I find that the top search results are direct links to the PDFs themselves. So even using google, I'm not able to determine which page or URL on our site has them on.

How do I delete these files, listed in the "Files" tab of the admin content screen?

Edit 3 So Clive's first answer "didn't work" for me, because it turns out, as Clive deduced, that the reference to the files were broken. But I was able to confirm that the code did indeed work by testing a node whose attached image I was certain of. I've deleted "Edit 2" expounding on the broken reference information I got from the code.

Improve this question
0

1 Answer 1

Reset to default
2

There are a couple of approaches; if you'd rather manage the deletion a bit more tightly, you can use the API to get a list of node (and/or other "thing") IDs that reference a particular file:

$usage = \Drupal::service('file.usage')
  ->listUsage(\Drupal\file\Entity\File::load($fid));

Then you can edit the node/etc, find the offending reference (in your example it looks like that would be within a paragraph of a previous revision), and remove it.

If you just want an interface for deleting files, there's the fledgling Delete Files module. It will even degrade gracefully for deleted files that are still referenced:

If a file you've deleted is managed by Drupal, this module replaces it with a new empty file to head off potential problems with dangling file references.

Improve this answer
5
  • As regards the first answer, I was not able to get useful information from the file.usage service-- please my second edit to my question.
    – user1359
    Sep 12, 2019 at 18:43
  • It may be more useful than you think - if you're sure the information is wrong, as in you've visited the node (e.g. 4651 is the node ID, 4 is the count that the file_usage table contains for that file), and it doesn't contain the files, or even fields, then you can probably safely assume it's a broken reference. Maybe caused by a bug in paragraphs/entity reference revisions. Armed with that information you can make a more informed decision about deleting the file via the second method (File Delete module)
    – Clive ♦
    Sep 12, 2019 at 18:46
  • I suppose they are broken references, then, but I have no way to further confirm or deny that theory, other than to look at the node edit screen on the page. As for the paragraph entity id, I am not aware of any way to further use that information, but I would not be surprised if there were further code I could implement in the script, or a module out there that could look that information up.
    – user1359
    Sep 12, 2019 at 18:50
  • 1
    For the paragraph: $parent_entity = \Drupal::entityTypeManager()->getStorage('paragraph')->load(4617)-> getParentEntity(); will get you the node/etc. If there's no paragraph/parent entity, it'll be another broken reference. I also think you can probably infer from the lack of a link to the content from the file admin UI, that Drupal couldn't find a reference to it either. You could definitely write a script to check, and it would probably be a good idea to delete the file usage entries too when you're happy they're not relevant. Just to keep things clean
    – Clive ♦
    Sep 12, 2019 at 18:56
  • 1
    Ah okay -- so, testing a known good image, I was able to get the nid from the fid, so you must be right-- they are broken references. I am going to use delete_files to delete them. I am updating my answer.
    – user1359
    Sep 12, 2019 at 19:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.