Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updating an image end up deleting it #331

Open
BuonOmo opened this issue Jan 24, 2019 · 3 comments
Open

Updating an image end up deleting it #331

BuonOmo opened this issue Jan 24, 2019 · 3 comments
Assignees
Labels

Comments

@BuonOmo
Copy link

BuonOmo commented Jan 24, 2019

Hi,

I'm using ActiveAdmin, with CarrierWave (1.3.1) and Cloudinary (1.11.1) with Ruby 2.4.4 (same issue with ruby 2.5.3) and rails 4.2.1.

My issue is the following one:
If I create a new record with an image, it works fine and I can see this image on my Cloudinary dashboard. However, when I try to update my record for a new image, none of the two images are on my dashboard anymore, and the URL stored in my record's attribute leads to a 404. However, the old version of the image is still available using the previous record's attribute's URL.

My guess is that there is either an issue with the cache like spotted in the issue #314, or an issue with carrierwave handling of cloudinary versions. However, the weirdest part is this deletion, and the fact that there is no trace of any image in my dashboard after update.

For more information, here are examples of my uploaders (feel free to ask for more information):

class BaseUploader < CarrierWave::Uploader::Base
  include Cloudinary::CarrierWave

  cloudinary_transformation backup: Rails.env.production?

  def public_id
    "#{store_dir}/#{model.id}"
  end

  def extension_white_list
    %w(jpg jpeg gif png)
  end

  def cache_dir
    "#{Rails.root}/tmp/uploads"
  end

  def filename
    "#{public_id}.#{file.extension}" if original_filename.present?
  end

  protected

  def store_dir
    "#{Rails.env}/#{model.class.to_s.underscore}/#{mounted_as}"
  end
end

class TeamMemberPictureUploader < BaseUploader
  version :thumb do
    process resize_to_fill: [300, 300]
  end
end

class TeamMember < ActiveRecord::Base
  mount_uploader :picture, TeamMemberPictureUploader
end

While looking for similar issues, I came across #267. Maybe my issue is quite similar. But I don't get your answer:

If you need your app to have both old and new images, then you'll need your app to be able to add more images rather than having a single updated one, and also make sure every new upload will assign a unique public ID to every upload.
On the other hand, if you're ok with your app having only a single (latest) version of the image, but still want to not delete the old versions on your Cloudinary account, then you'll need to also make sure the public IDs are unique for each new upload.

What I want is to have one id associated to my record / environment / attribute. But I don't want it to change. The expected behavior is that the new picture will replace the old one.

@d-mendoza
Copy link
Contributor

Hi @BuonOmo
I apologize for the delay in this response.
We have reproduced your issue and are looking at alternatives to achieve your desired result which is to overwrite the previous image but keep the same public_id.

@d-mendoza d-mendoza self-assigned this Feb 8, 2019
@BuonOmo
Copy link
Author

BuonOmo commented Nov 30, 2020

Hi @d-mendoza I guess there won't be any follow-up on that one ?

@rioug
Copy link

rioug commented Mar 31, 2021

I am having the same issue with the following versions: ruby 2.6, Rails 5.0.7.2, Carrierwave 1.3.2 and Cloudinary 1.20.0

I came up with a workaround where I add some non unique characters at the end of my public_id :

def public_id
  "#{model.name}_logo_#{Cloudinary::Utils.random_public_id[0, 4]}"
end

inspired by https://support.cloudinary.com/hc/en-us/articles/202519862-How-can-I-set-the-public-ID-as-the-original-filename-in-Carrierwave-

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants