Skip to main content

Method destroy() not working

Comments

8 comments

  • Roee Ben Ari

    Hi Thiago, 

    Would you mind sharing a URL example of an image you're trying to delete?

    If you rather keep it confidential, then feel free to open a support ticket and will continue from there. 

    Thanks,

    Roee

    1
  • Thiago

    Thank you for your reply. No, I don't mind sharing. I'm on a test environment to be honest but I'm able to upload images without any problems. Here's the url of the image Im trying to delete but it happens to every image: https://res.cloudinary.com/dhiqac3ao/image/upload/v1596982832/8455e9ceb0677ecbed5a7b067600846f.jpg

    0
  • Roee Ben Ari

    Thanks, Thiago.

    Looking at your logs, I see two requests to delete this resource:

    1. Request sent with type: fetch while the type of the resource is 'upload' therefore no resource was deleted (though the response is 200 nonetheless).
    2. A successful 'destroy' request - the resource was deleted and invalidated and the resource indeed no longer available. 

    Can you please pinpoint the issue?
    Maybe you saw a cached resource when loading one of its URLs? If that's the case, can you please share the URL where the resource is still available so I can investigate it further?

    Thanks,

    Roee

    1
  • Thiago

    Thank you Roee.

    That's weird thought. For example, I just deleted this image via API: https://res.cloudinary.com/dhiqac3ao/image/upload/v1597058565/cba517f916e0624df10f502cd26c707a.jpg but I still can see it in my Cloud. Could you check this image please?

    Thank you. 

     

    UPDATE

    It seems like type='fetch' was preventing the image to be deleted.

    I just used

    \Cloudinary\Uploader::destroy('image_name_without_extension', array('invalidate'=>TRUE,  'resource_type'=>'image')); 

    and it worked. I thought I could use the type parameter as described here

    https://cloudinary.com/documentation/image_upload_api_reference#destroy_method

    I'm sorry, it seems like I misunderstood the documentation.

    Thank you once again Roee.

    0
  • Shirly Manor

    In Cloudinary, fetch type is an image that we fetched from public URL. you can read more about it here: https://cloudinary.com/documentation/fetch_remote_images#remote_image_fetch_url since the image that you tried to delete is with type => upload and resource_type=> image it only find it when you provide the correct type (or not provide the type since the default is upload).

    Hope that helps, please let us know if you have any further questions,

    1
  • Thiago

    Thank you very much for your explanation Shirly. I got it now.

    0
  • Kolawole

    Hi. I've got the same issue. I keep getting a "not found" response. 

    I'm using Node and my code is 

    cloudinary.uploader.destroy(url, {type : 'upload', resource_type : 'image'}, result => {
    return result;
    })

    I only added the optional parameters (type and resource_type) after many failed attempts, to see whether that would work.

    Any help would be appreciated. It's only a test instance so I can share all relevant information. The url of the image I'm currently trying to delete is http://res.cloudinary.com/unitebeta/image/upload/v1623248957/iupl7efjsbkordrvlrbq.png

     

    1
  • Raz Ziv

    Hey @Kolawole,

    When using the `destroy()` method to delete a certain asset, the method expects the `public_id` of the asset to be passed as the first parameter and not the entire delivery URL.

    In your case, you should either run:

    public_id = iupl7efjsbkordrvlrbq;
    cloudinary.uploader.destroy(public_id, {type : 'upload', resource_type : 'image'}, result => {
        return result;
    })

    Or as you've mentioned, `type` and `resource_type` are not mandatory when their respectively values are 'upload' and 'image':

    public_id = iupl7efjsbkordrvlrbq;
    cloudinary.uploader.destroy(public_id, result => {
        return result;
    })

    Let me know if that doesn't work for you as well?

    Best,
    Raz

    0

Post is closed for comments.