Deleting image ends up only unpublishing it?

Questions
1

So, this is a weird thing that I just found on 4.3.0:

When I try to delete an image by calling “->delete()” function, it only UNPUBLISHES this image, instead of deleting it as described in the API doc:

delete()

Delete this data object.

$this->onBeforeDelete() gets called. Note that in Versioned objects, both Stage and Live will be deleted.

...
private static $has_one = [ 'Image' => Image::class];
...

$this->Image()->delete();
// I also tried Image::get()->byID($this->ImageID)->delete(), no dice

Any idea?

Thanks!
Leo

1 Like
3

I have a fully working answer for you that works on DataObject items which extends your answer a little. I’ve watched a folder on the file system and on the CMS asset view wipe out all the images associated with the DataObject when pressing Delete on the CMS.

	public function onBeforeDelete(){
		if($this->FrontImageID) {
			$myFile = $this->FrontImage();
			$file = DataObject::get_by_id(File::class, $myFile->ID); //we have to make sure it is a Dataobject object
			if ($file) {
				$file->deleteFile();
				$file->destroy();
				$file->delete();
			}
		}
		return parent::onBeforeDelete();
	}
2

2 years later … still no answer?
So I’m trying to delete images completely (physically and in the DB) and came across this :
I found this:
“Simply call delete() to archive an item. The SilverStripe ORM doesn’t allow you to hard-delete versioned DataObjects.”

I don’t want image versioning but I guess we’re stuck with it!

Anyways I got this so far:

$image = \SilverStripe\Assets\File::get()->byID($id);
$image->delete(); // puts Image into ‘draft’ mode
$image->deleteFile(); // deletes the actual image

No go on removing the image from the DB but :frowning :frowning:

1 Like
4

hey guys, thanks for sharing your experience and the answer. When the notification email popped on my phone screen, I was like “huh??” for quite a few seconds lol - I’ve totally forgotten this issue already, and I’m a bit surprised that it’s still as confusing as 3 years ago.

I think, in the end, I had to first delete the file, and then use DB::query to wipe its existence from the versioned File table.

5

Thinking outside the box: if you really want to build something that you have complete control of, I would suggest you start your own File object and utilise the AWS S3 bucket to store the files and get Lambda functions to take care of the resizing for you.

ps: you can use the official SilverStripe S3 module, but try NOT to use it, if you are in a situation of publishing/resampling more than 10 images at once (e.g. the File tab in the CMS), otherwise, the PHP execution timeout will be your best friend :joy: