Uploaded files are impossible to replace

Has anyone attempted to solve this problem by automatically creating a redirect from the old file URL to the new file URL when Media is edited and a new file is uploaded? Are there any obvious reasons it couldn't work?

I've seen some modules that create a redirect from a constant URL to the actual file URL, but these all rely on content editors understanding that they should never link directly to the file URL. I don't think content editors should have to remember this and I don't trust that they will.

The old file URL will still exist on the filesystem in some cases, in which case a Drupal-created redirect will not work. Your web server won't even involve Drupal when someone requests a file that exists in the filesystem.

#73 I still think, performance tradeoff aside, permanent URI a la node/123 is preferable over raw file URLs. They will always work, until that media item is deleted. Whatever file it holds, its name or path is irrelevant. As bkosborne points out in #74, the application won't have a chance to respond when a file like that is requested.

Ah, I hadn't thought of that. Dang.

I can see how a permanent URI would be the ideal solution for a site without many editors and where everyone adheres to the rules. It won't work for my situation unfortunately. I am testing your media_entity_file_replace module bkosborne, and it seems to be working great so far. Hopefully I can convince the team that being able to replace files and maintain the URL is more important than revisions on media. Seems like a fair trade based on how frustrated editors are with the current file replace situation. Thanks for your work!

I've been able to replace and rename files in Drupal 9 without any custom code by using the File (Field) Paths module → . Following this awesome blog post, Better File Management for Drupal 8 and Drupal 9 – Part 1 I was able to give content editors the power to rename media files with normal sentence case and spacing, but have ideally managed filenames renamed by File Field Paths:

Media name:
Product Handbook 2023

Filename:
product-handbook-2023.pdf

In addition, if this were a media entity type Document and had a taxonomy term attached to this e.g. onboarding, I was able to get FFP to automatically place these in a structured location for easy file management:

/sites/default/files/documents/onboarding/product-handbook-2023.pdf

The only difference between what I did and what you'll find in the blog post is I have unchecked "Create Redirect" and "Retroactive update" and only have checked "Active updating" under the FFP settings in the file field settings. Retroactive update is useful if you have existing files that you want to update, and you'll only have to check this box once, and after it runs it unchecks itself. I've also used this to change file systems from private > public or public > private and update the file paths for my media files.

I am also using the Media file delete module → so that users are managing media entities rather than Files themselves. If the media entity is deleted, so is the file. I set the default value to be checked:

/**
 * Implements hook_form_BASE_FORM_ID_alter().
 */
function MYMODULE_form_media_confirm_form_alter(&$form, FormStateInterface $form_state, $form_id) {
  // Set confirm delete default value for media files.
  $form['also_delete_file']['#default_value'] = 1;
}

Finally, I have the following in my settings.php file, so that if I want to make sure orphaned files are removed, I can either wait for the next cron run or trigger a manual cron job.

/**
 * File settings (Custom).
 *
 * This will remove orphaned (deleted) files from the file system on the
 * next cron run.
 */
$config['file.settings']['make_unused_managed_files_temporary'] = TRUE;
$config['system.file']['temporary_maximum_age'] = 1;

Out of scope, but:

> $config['system.file']['temporary_maximum_age'] = 1;

This is wrong and will delete files that users are in process of creating if cron runs between uploading a file and saving the entity. Introducing this setting at all was a mistake, this should always be set to the same as the form cache max age (6h by default), that's the reason temporary files aren't immediately deleted. And we should also reintroduce the logic that immediately deletes files as the change from permanent to temporary/lose all usages.

Has anyone come up with a way to make the file replacements when uploading media in bulk? I'm surprised that has not been brought up.

Created a related ticket for better authorisation 🐛 File entity update is allowed only for user who has uploaded the file Active