Option on Media to preserve files when deleted

[squatto]

This suggestion is easiest to explain with a situation that just happened to me:

1. Create a new product in our backend system
2. Upload the print template PDF to the product (creating a Media instance in a single-file collection)
3. Orders come into our platform for the product
4. The URL of the product's print template PDF is sent to our vendor to use for fulfillment
5. This continues for two weeks, and then we tweak the product's print template
6. Upload the new print template PDF to the product
7. Since it is a single-file collection, the previous print template PDF is deleted and the new one takes its place, creating a new Media instance with a different URL
8. The URL that we have been sending our vendors for the past two weeks is now invalid and throws a 404

What I am suggesting is that an option is added to Media that will prevent the actual files from being deleted when the Media instance itself is deleted. This functionality already exists at the parent/model level using ->deletePreservingMedia(), but there is no way to do it at the Media level.

Based on this...

laravel-medialibrary/src/MediaCollections/Models/Observers/MediaObserver.php

Lines 55 to 67 in 8a51de5

	public function deleted(Media $media)
	{
	if (in_array(SoftDeletes::class, class_uses_recursive($media))) {
	if (! $media->isForceDeleting()) {
	return;
	}
	}
	/** @var \Spatie\MediaLibrary\MediaCollections\Filesystem $filesystem */
	$filesystem = app(Filesystem::class);
	$filesystem->removeAllFiles($media);
	}

...this can already be accomplished by using my own Media model that implements soft deletes (correct?) However, I wanted to suggest that this be added to the package itself so that it's available to everyone.

This would require a new property on Media, which would require a migration. That's definitely not a small change - especially for those that are already using their own model. Definitely something that can be presented in an upgrade guide on the docs though.

A corresponding option could be added to a media collection, effectively setting the option on all Media within. This may actually be a better option than adding it directly to Media, since media collections are ephemeral by nature. No migrations would be required. However, this would force the use of media collections in order to prevent the deletion of files. Adding an option to both media collections and Media would satisfy both scenarios, however.

I am happy to PR the entire change, but I wanted to propose it and get approval before I take the time.

Thanks!

[freekmurze]

Thanks for your idea, but I'm going to leave things as they are for now. I think that deletePreservingMedia is enough to cover this functionality for most users.

[squatto]

@freekmurze thank you for considering it!

I was able to accomplish what I was after by using my own model and adding soft deletes. What would you think about adding some info about this to the "Using your own model" docs page? I can write it up and PR it if you'd like.

I'll put these here for anybody that comes across this discussion:

---

App\Models\Media model:

namespace App\Models;

use Illuminate\Database\Eloquent\SoftDeletes;
use Spatie\MediaLibrary\MediaCollections\Models\Media as BaseMedia;

class Media extends BaseMedia
{
    use SoftDeletes;
}

---

AddSoftDeletesToMedia migration:

class AddSoftDeletesToMedia extends Migration
{
    public function up(): void
    {
        Schema::table('media', function (Blueprint $table) {
            $table->softDeletes();
        });
    }

    public function down(): void
    {
        Schema::table('media', function (Blueprint $table) {
            $table->dropSoftDeletes();
        });
    }
}

[squatto]

For anybody that implements soft deletes on their own Media model (and for @freekmurze as an FYI), I wanted to point out an issue that I just came across: If you are using Media Library Pro (which I highly recommend) then you are going to get duplicate key errors when persisting temporary uploads to your models. This happens because of the way that Media Library Pro handles temporary uploads:

1. A file is uploaded through the UI
2. A temporary Media record is created for the uploaded file and attached to the TemporaryUpload model
3. When you persist the temporary-upload file to your model (in a controller, or wherever):
   1. The temporary-upload Media record is deleted
   2. A new Media record is created and attached to your model
4. The new Media record's udid property is updated to be the same value that it was on the now-deleted temporary-upload Media record

The last step causes a problem because media.udid is a unique field:

laravel-medialibrary/database/migrations/create_media_table.php.stub

Line 15 in ebbc996

$table->uuid('uuid')->nullable()->unique();

Since the temporary-upload Media record was soft deleted (in other words, it still exists in the table) a duplicate key error is thrown.

To get around this, you have to force-delete the temporary-upload Media record. I did this by watching for the deleted event on my custom Media model, checking if the deleted record is a temporary upload, and force-deleting it if it is. This is easily done by adding a closure-based event handler to your custom Media model:

use Spatie\MediaLibraryPro\Models\TemporaryUpload;

protected static function booted(): void
{
    static::deleted(fn (Media $media) => $media->forceDeleteIfTemporaryMediaLibraryUpload());
}

public function forceDeleteIfTemporaryMediaLibraryUpload(): void
{
    if ($this->model instanceof TemporaryUpload && ! $this->isForceDeleting()) {
        $this->forceDelete();
    }
}

[rahulhaque]

Adding to @squatto's issue, when using the single file collection, the existing media gets deleted along with its corresponding database row and a new media row is created with a new auto incrementing id. Isn't this an issue as with every update we lose a valuable auto incrementing id in the media table? Nevertheless to say, the old id will be invalid as well making some links inoperable where it shouldn't have. My intention is to replace a media in the collection, not to create another media and delete the last one. @freekmurze please let me know if you think this should be implemented for single file collection or any suggestion where it shouldn't be. 🙏🏻

[freekmurze]

Isn't this an issue as with every update we lose a valuable auto incrementing id in the media table

We use unsigned big integers for the id column. If you would insert 20 media items per second, you could go on for decades without hitting the limit. How many decades? That's something for you to calculate 🙂

I think having another id for a replacement is also wanted as you'll get a automatic cache busting.

So unless the code for reuse of id's is really simple, I'd likely pass for it.

[rahulhaque]

I totally get the cache busting purpose as many would like to have new ids for update. Can this be added as an option as many out their like me would love to keep the old ids or suppose I already mailed him a link or my app is monolithic? 🙂 Its SPATIE we are talking about and your packages are versatile.

Edit:

So unless the code for reuse of id's is really simple, I'd likely pass for it.

I feel like I miss this line so editing the comment. Do you mean it'll be too much of a hassle to implement this.

[freekmurze]

I meant that I'm not going to invest my time (because I don't need the feature).

If you can make it work with little and easy code changes, I might consider pulling in the PR. If it's complicated or a lot of code, I'd like not pull it in, because I don't want to maintain complicated stuff that I don't use myself.

[rahulhaque]

Thank you for your time. I'll have a look then. 🙂