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

Versions on a subclassed uploader save to the location of the parent class #1064

Gazler opened this issue Apr 12, 2013 · 8 comments


Copy link

Gazler commented Apr 12, 2013

I have made a repository that displays this issue at

I am not sure if this behaviour is intended. I have the following Uploader that sets the versions to be used by other Uploaders:

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

  storage :file

  version :square do
    process :resize_to_fill => [380, 380]

  version :thumb, :from_version => :square do
    process :resize_to_fill => [119, 119]

I then want to override the store location when an uploader subclasses this, so I do the following:

class AvatarUploader < BaseUploader

  def store_dir

When I upload an image, I get the following urls:

User.first.avatar.url # "/uploads/people/pictures/4/avatar.png"
User.first.avatar.thumb.url #"/uploads/thumb_avatar.png"

I would expect the url of the thumbnail to be:

User.first.avatar.thumb.url #"/uploads/people/pictures/thumb_avatar.png"

Apologies if this is intentional or has been raised before.

Copy link

BBonifield commented Jul 9, 2013

👍 I ran into this same issue today. My issue was not around storage locations but rather version process calls.

class BaseUploader < CarrierWave::Uploader::Base

  include CarrierWave::MiniMagick
  version :thumbnail do
    process :resize_to_fill => [200, 200]


class IconImageUploader < BaseUploader

  version :processed do
    process :resize_to_fill => [175, 175]


I can access .thumbnail of IconImageUploader instances, but the process operation is not performed.

The test below passes if I define the thumbnail version on IconImageUploader, but it fails when thumbnail is defined on BaseUploader

require 'spec_helper'
require 'carrierwave/test/matchers'

describe IconImageUploader do
  include CarrierWave::Test::Matchers

  before do
    bundle = build_stubbed(:bundle)
    test_image_path = fixture_file_path 'test-image.jpg'
    IconImageUploader.enable_processing = true
    @uploader =, :bundle)!(

  after do
    IconImageUploader.enable_processing = false

  context 'the thumbnail version' do
    it "should scale down an image to be within 200x200" do
      @uploader.thumbnail.should be_no_larger_than(200, 200)

Copy link

synth commented Jul 21, 2014

+1, hitting this issue as well; we're changing the default_url's on subclasses but revert to the parent classes implementation

Copy link

groue commented Sep 29, 2014


Copy link

satyapatidar commented Dec 17, 2014

👍 happening same with overriding store_dir is picking the parent class imaplementation.

Copy link

avgerin0s commented Jun 4, 2015

This is a general design issue that can be seen here.

Any patch that changes this logic without breaking something will be appreciated.

@avgerin0s avgerin0s added bug and removed bug labels Jun 4, 2015
Copy link

chrhansen commented Jul 27, 2015

I'm also seeing this issue when I'm subclassing a base_uploader(PublicImageUploader < BaseUploader). If files are defaulted to fog_public = false in my base_uploader-class, then even when I set:

# public_image_uploader.rb
def self.fog_public

In a subclass, this is only respected for the original file, but not in version-calls. So for now, I've done this

# public_image_uploader.rb
version :thumb do
  def fog_public
  process resize_to_fill: [200, 200]

Based on suggestion here: – but it hurts my eyes.

Copy link

thomasfedb commented Nov 16, 2015

@chrhansen if you believe that you have found a genuine bug, rather than a design choice, please report a new issue.

Copy link

tbrammar commented Feb 1, 2017

We've just run into this same issue. As this is by design perhaps it might be helpful to highlight this in the Readme text?

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

No branches or pull requests

9 participants