Are you a Site Factory user? Yes? Good. This is for everyone, but especially for you.

You may have used Fancy File Delete in the past and it worked just fine. Randomly, you may have experienced an instance or two where it looks like the file is gone from your site. You checked; it's no longer listed in Files and it's nowhere to be found in your Media Library. Read on and we'll show you the tricksy-hobbitsy way Site Factory can mess with your ability to remove sensitive documents in a timely manner.

First, what's Fancy File Delete?

It's a module specifically designed to help you manually remove documents you have uploaded and linked to your site if the need is urgent. Take a look at our write-up about this feature if you're interested.

Why is/was Fancy File Delete necessary?

A change made to Drupal in 2018 by the Drupal Community of developers removed the ability to delete files via the existing methods in preparation for the rollout of the Media Library Initiative. Even though Media Library is now available and this is likely not a problem, it's possible older files may need to be dealt with manually.

Why would you use Fancy File Delete?

To quickly remove files that

1. contain out-of-date health information that, if not removed, could result in harm, or
2. are subject to legal orders to cease and desist display on the site.

An example of the issue

A user reported that a file they know they deleted was still appearing in search results, complete with a valid link that opened the supposedly deleted file. They requested assistance from our team and, after reviewing the site, it was clear no such file existed. 

Send in the Clones...

We ran through various questions and possibilities, but what we finally determined is that the live site was a clone of a previous site. For those who don't have an account directly on Acquia Cloud Site Factory, our hosting platform, this service allows a client group to have hands-on control over site creation and management. You can read more about it in our documentation on the subject.

We learned the following:

• As mentioned, the current live site was a clone of a previous iteration
• When we compared the site IDs the one for the file link didn't match the current live site, it matched the old one
• Unfortunately, the older site had already been deleted, but the file was tucked away where the client couldn't reach it.

How did this even happen? Why didn't Site Factory update the file's site ID?

It's a little convoluted, so let's go with bullet points:

• When you clone an existing site in Site Factory, configured to include all the original content instead of a clean database, it reviews all of the fields in your site such as primary image fields, and document or logo attachments. It updates any pathways it finds in these fields to reflect the new site ID it's creating; /dgvnsk0005/ to /dgvnsk0011/, for example (more on this below in the next section).
• The cloning process doesn't consider your WYSIWYG area a field. This is the problem. The cloning process, much like the media library, doesn't particularly play well with the WYSIWYG, so in this specific context, it ignores the WYSIWYG except to move a copy of the content from the original site to the new site as-is.
• By ignoring it, the copy process preserves whatever content the WYSIWYG holds untouched and never updates any of the relative path URLs like it would for all the fields in your site. This is why any text with embedded links pointing to files never get updated to the new site ID.
• What's important to know is that the files were successfully added to your new site during the cloning process and exist in your media library; the process didn't skip copying the content over even though it ignored the link in the WYSIWYG.

How to identify if this is your issue

First, look at your problem file's URL. Here's an example:

https://somesite.ucdavis.edu/sites/g/files/dgvnsk0005/files/inline-files/somefile.pdf

Notice the part in bold; /dgvnsk0005/. This is an example of a site ID (we've used one that likely doesn't exist, but it illustrates this is a number). 

Check your current site's ID

1. Navigate to Shortcuts » All content » Files tab in your current site, not the one you cloned it from.
2. Use the Filename or Mime Type fields to help you locate your file.
3. Once located, grab the link by right-clicking on the file and copying the link address, OR look in your browser's status bar (usually located in the lower left of the window at the bottom of the screen) and note the dgvnsk number.
4. Compare the file's site ID with the ID you just reviewed. If they don't match, then you know this means the problem file lives on a different site and needs to be deleted from that location. 

Removing the problematic file

If you know the original site source for your current site, return to the original and follow the Fancy File Delete instructions. If you don't know or don't remember: 

1. Note the dgvnsk ID from the document you're trying to remove and go to Acquia Cloud Site Factory.
2. Go to your sites in Site Factory and, in the site card(s), click the (i) information icon to see the details of each of your sites.

   

3. Keep looking until you see a site ID that matches the one for your file.
4. Proceed with deleting the document from the original site.

You deleted it from the original site and it's STILL showing up

There's a chance your file was cached in a spot you can't access. If you get this far and the file is still accessible, email us so we can help you.

A last note

Though it was mentioned earlier, it's important to note that even if the files and images are still pointing back to the old site with the dgvnsk site ID, those same files and images existing on your current site. If urgently deleting them isn't the concern, but instead making sure they're all referencing the correct source (your Media Library or Files tab), you can easily find and replace the misdirected files either in the user interface of your WYSIWYG or by going into the Source screen and updating the dgvnsk ID if you know it.