Deleting an asset and reuploading it causes issues

[valboivin]

Hello!

When we delete a specific asset from the assets, it is correctly deleted in the Cloudinary account. However, if we re-upload one with the same filename, we are prompt with a file already exists modal. No matter what option we select, the newly uploaded file will have its filename changed.

I think that this is happening because the Search Index is not updated after an asset deletion.

In the deleteElement function of the Craft Elements Services, when we force delete an element it does delete the searchIndex for that element:

if ($element->hardDelete) {
                Db::delete(Table::ELEMENTS, [
                    'id' => $element->id,
                ]);
                Db::delete(Table::SEARCHINDEX, [
                    'elementId' => $element->id,
                ]);
            } 

Because of this, I thought that in the NotificationsController.php file, the processDelete function should have the hardDelete parameter to true on its Craft's deleteElement call. But I've tested this and it's not working either.

Craft::$app->getElements()->deleteElement($asset, true);

What is causing the deleted asset to still be indexed and/or searchable in Craft?

[thomasvantuycom]

I can't reproduce this issue. Are you deleting and uploading through the Craft UI?

[valboivin]

Yes, directly through the Craft UI.

If I test the code with a debugger, it looks like the fileExists method from the CloudinaryAdapter.php file returns true. However, the file found by the API corresponds to a deleted file in Cloudinary.

[thomasvantuycom]

It's great that you sent the hint about asset backups. When using the Cloudinary API to check if a previously backed-up and deleted resource exists, it returns an empty placeholder. The filesystem adapter now filters out these empty results.

The change is now available in version 1.7.1, and soon in version 2.0.0 if you're on Craft 5.

[valboivin]

@thomasvantuycom, thank you! It works 😄