CarrierWave
This gem provides a simple and extremely flexible way to upload files from Ruby applications. It works well with Rack based web applications, such as Ruby on Rails.
Information
- RDoc documentation available on RubyDoc.info
- Source code available on GitHub
- More information, known limitations, and how-tos available on the wiki
Upgrading from 2.x or earlier
CarrierWave 3.0 comes with a change in the way of handling the file extension on conversion. This results in following issues if you use process convert: :format
to change the file format:
- If you have it on the uploader itself (not within a version), the file extension of the cached file will change. That means if you serve both CarrierWave 2.x and 3.x simultaneously on the same workload (e.g. using blue-green deployment), a cache file stored by 2.x can’t be retrieved by 3.x and vice versa.
- If you have it within a version, the file extension of the stored file will change. You need to perform
#recreate_versions!
to make it usable again.
To preserve the 2.x behavior, you can set force_extension false
right after calling process convert: :format
. See #2659 for the detail.
Getting Started
Start off by generating an uploader:
rails generate uploader Avatar
this should give you a file in:
app/uploaders/avatar_uploader.rb
Check out this file for some hints on how you can customize your uploader. It should look something like this:
class AvatarUploader < CarrierWave::Uploader::Base
storage :file
end
You can use your uploader class to store and retrieve files like this:
uploader = AvatarUploader.new
uploader.store!(my_file)
uploader.retrieve_from_store!('my_file.png')
CarrierWave gives you a store
for permanent storage, and a cache
for
temporary storage. You can use different stores, including filesystem
and cloud storage.
Most of the time you are going to want to use CarrierWave together with an ORM. It is quite simple to mount uploaders on columns in your model, so you can simply assign files and get going:
ActiveRecord
Make sure you are loading CarrierWave after loading your ORM, otherwise you’ll need to require the relevant extension manually, e.g.:
require 'carrierwave/orm/activerecord'
Add a string column to the model you want to mount the uploader by creating a migration:
rails g migration add_avatar_to_users avatar:string
rails db:migrate
Open your model file and mount the uploader:
class User < ApplicationRecord
mount_uploader :avatar, AvatarUploader
end
Now you can cache files by assigning them to the attribute, they will automatically be stored when the record is saved.
u = User.new
u.avatar = params[:file] # Assign a file like this, or
# like this
File.open('somewhere') do |f|
u.avatar = f
end
u.save!
u.avatar.url # => '/url/to/file.png'
u.avatar.current_path # => 'path/to/file.png'
u.avatar_identifier # => 'file.png'
Note: u.avatar
will never return nil, even if there is no photo associated to it.
To check if a photo was saved to the model, use u.avatar.file.nil?
instead.
Changing the storage directory
In order to change where uploaded files are put, just override the store_dir
method:
class MyUploader < CarrierWave::Uploader::Base
def store_dir
'public/my/upload/directory'
end
end
This works for the file storage as well as Amazon S3 and Rackspace Cloud Files.
Define store_dir
as nil
if you’d like to store files at the root level.
If you store files outside the project root folder, you may want to define cache_dir
in the same way:
class MyUploader < CarrierWave::Uploader::Base
def cache_dir
'/tmp/projectname-cache'
end
end
Changing the filename
To change the filename of uploaded files, you can override #filename
method in the uploader.
class MyUploader < CarrierWave::Uploader::Base
def filename
"image.#{file.extension}" # If you upload 'file.jpg', you'll get 'image.jpg'
end
end
Some old documentations (like this) may instruct you to safeguard the filename value with if original_filename
, but it’s no longer necessary with CarrierWave 3.0 or later.
Securing uploads
Certain files might be dangerous if uploaded to the wrong location, such as PHP files or other script files. CarrierWave allows you to specify an allowlist of allowed extensions or content types.
If you’re mounting the uploader, uploading a file with the wrong extension will make the record invalid instead. Otherwise, an error is raised.
class MyUploader < CarrierWave::Uploader::Base
def extension_allowlist
%w(jpg jpeg gif png)
end
end
The same thing could be done using content types. Let’s say we need an uploader that accepts only images. This can be done like this
class MyUploader < CarrierWave::Uploader::Base
def content_type_allowlist
/image\//
end
end
You can use a denylist to reject content types. Let’s say we need an uploader that reject JSON files. This can be done like this
class NoJsonUploader < CarrierWave::Uploader::Base
def content_type_denylist
['application/text', 'application/json']
end
end
Setting the content type
As of v0.11.0, the mime-types
gem is a runtime dependency and the content type is set automatically.
You no longer need to do this manually.
Conditional processing
If you want to use conditional process, you can only use if
statement.
See carrierwave/uploader/processing.rb
for details.
class MyUploader < CarrierWave::Uploader::Base
process :scale => [200, 200], :if => :image?
def image?(carrier_wave_sanitized_file)
true
end
end
Nested versions
It is possible to nest versions within versions:
class MyUploader < CarrierWave::Uploader::Base
version :animal do
version :human
version :monkey
version :llama
end
end
Conditional versions
Occasionally you want to restrict the creation of versions on certain properties within the model or based on the picture itself.
class MyUploader < CarrierWave::Uploader::Base
version :human, if: :is_human?
version :monkey, if: :is_monkey?
version :banner, if: :is_landscape?
private
def is_human? picture
model.can_program?(:ruby)
end
def is_monkey? picture
model.favorite_food == 'banana'
end
def is_landscape? picture
image = MiniMagick::Image.new(picture.path)
image[:width] > image[:height]
end
end
The model
variable points to the instance object the uploader is attached to.
Create versions from existing versions
For performance reasons, it is often useful to create versions from existing ones instead of using the original file. If your uploader generates several versions where the next is smaller than the last, it will take less time to generate from a smaller, already processed image.
class MyUploader < CarrierWave::Uploader::Base
version :thumb do
process resize_to_fill: [280, 280]
end
version :small_thumb, from_version: :thumb do
process resize_to_fill: [20, 20]
end
end
#filename method, but this doesn’t work for versions because of the limitation on how CarrierWave
re-constructs the filename on retrieval of the stored file.
Instead, you can override #full_filename
with providing a version-aware name.
class MyUploader < CarrierWave::Uploader::Base
version :thumb do
def full_filename(for_file)
'thumb.png'
end
process convert: 'png'
end
end
Please note that #full_filename
mustn’t be constructed based on a dynamic value
that can change from the time of store and time of retrieval, since it will result in
being unable to retrieve a file previously stored.
Making uploads work across form redisplays
Often you’ll notice that uploaded files disappear when a validation fails.
CarrierWave has a feature that makes it easy to remember the uploaded file even
in that case. Suppose your user
model has an uploader mounted on avatar
file, just add a hidden field called avatar_cache
(don’t forget to add it to
the attr_accessible list as necessary). In Rails, this would look like this:
<%= form_for @user, html: { multipart: true } do |f| %>
<p>
<label>My Avatar</label>
<%= f.file_field :avatar %>
<%= f.hidden_field :avatar_cache %>
</p>
<% end %>
````
It might be a good idea to show the user that a file has been uploaded, in the
case of images, a small thumbnail would be a good indicator:
```erb
<%= form_for @user, html: { multipart: true } do |f| %>
<p>
<label>My Avatar</label>
<%= image_tag(@user.avatar_url) if @user.avatar? %>
<%= f.file_field :avatar %>
<%= f.hidden_field :avatar_cache %>
</p>
<% end %>
Removing uploaded files
If you want to remove a previously uploaded file on a mounted uploader, you can easily add a checkbox to the form which will remove the file when checked.
<%= form_for @user, html: { multipart: true } do |f| %>
<p>
<label>My Avatar</label>
<%= image_tag(@user.avatar_url) if @user.avatar? %>
<%= f.file_field :avatar %>
</p>
<p>
<label>
<%= f.check_box :remove_avatar %>
Remove avatar
</label>
</p>
<% end %>
If you want to remove the file manually, you can call remove_avatar!
, then save the object.
@user.remove_avatar!
@user.save
#=> true
Uploading files from a remote location
Your users may find it convenient to upload a file from a location on the Internet via a URL. CarrierWave makes this simple, just add the appropriate attribute to your form and you’re good to go:
<%= form_for @user, html: { multipart: true } do |f| %>
<p>
<label>My Avatar URL:</label>
<%= image_tag(@user.avatar_url) if @user.avatar? %>
<%= f.text_field :remote_avatar_url %>
</p>
<% end %>
If you’re using ActiveRecord, CarrierWave will indicate invalid URLs and download
failures automatically with attribute validation errors. If you aren’t, or you
disable CarrierWave’s validate_download
option, you’ll need to handle those
errors yourself.
Retry option for download from remote location
If you want to retry the download from the Remote URL, enable the download_retry_count option, an error occurs during download, it will try to execute the specified number of times. This option is effective when the remote destination is unstable.
CarrierWave.configure do |config|
config.download_retry_count = 3 # Default 0
config.download_retry_wait_time = 3 # Default 5
end
Providing a default URL
In many cases, especially when working with images, it might be a good idea to
provide a default url, a fallback in case no file has been uploaded. You can do
this easily by overriding the default_url
method in your uploader:
class MyUploader < CarrierWave::Uploader::Base
def default_url(*args)
"/images/fallback/" + [version_name, "default.png"].compact.join('_')
end
end
Or if you are using the Rails asset pipeline:
class MyUploader < CarrierWave::Uploader::Base
def default_url(*args)
ActionController::Base.helpers.asset_path("fallback/" + [version_name, "default.png"].compact.join('_'))
end
end
Recreating versions
You might come to a situation where you want to retroactively change a version
or add a new one. You can use the recreate_versions!
method to recreate the
versions from the base file. This uses a naive approach which will re-upload and
process the specified version or all versions, if none is passed as an argument.
When you are generating random unique filenames you have to call save!
on
the model after using recreate_versions!
. This is necessary because
recreate_versions!
doesn’t save the new filename to the database. Calling
save!
yourself will prevent that the database and file system are running
out of sync.
instance = MyUploader.new
instance.recreate_versions!(:thumb, :large)
Or on a mounted uploader:
User.find_each do |user|
user.avatar.recreate_versions!
end
Note: recreate_versions!
will throw an exception on records without an image. To avoid this, scope the records to those with images or check if an image exists within the block. If you’re using ActiveRecord, recreating versions for a user avatar might look like this:
User.find_each do |user|
user.avatar.recreate_versions! if user.avatar?
end
Configuring CarrierWave
CarrierWave has a broad range of configuration options, which you can configure, both globally and on a per-uploader basis:
CarrierWave.configure do |config|
config.permissions = 0666
config.directory_permissions = 0777
config.storage = :file
end
Or alternatively:
class AvatarUploader < CarrierWave::Uploader::Base
permissions 0777
end
If you’re using Rails, create an initializer for this:
config/initializers/carrierwave.rb
If you want CarrierWave to fail noisily in development, you can change these configs in your environment file:
CarrierWave.configure do |config|
config.ignore_integrity_errors = false
config.ignore_processing_errors = false
config.ignore_download_errors = false
end
Testing with CarrierWave
It’s a good idea to test your uploaders in isolation. In order to speed up your
tests, it’s recommended to switch off processing in your tests, and to use the file storage.
Also, you can disable SSRF protection at your own risk using the skip_ssrf_protection
configuration.
In Rails you could do that by adding an initializer with:
if Rails.env.test? or Rails.env.cucumber?
CarrierWave.configure do |config|
config.storage = :file
config.enable_processing = false
config.skip_ssrf_protection = true
end
end
Remember, if you have already set storage :something
in your uploader, the storage
setting from this initializer will be ignored.
If you need to test your processing, you should test it in isolation, and enable processing only for those tests that need it.
CarrierWave comes with some RSpec matchers which you may find useful:
require 'carrierwave/test/matchers'
describe MyUploader do
include CarrierWave::Test::Matchers
let(:user) { double('user') }
let(:uploader) { MyUploader.new(user, :avatar) }
before do
MyUploader.enable_processing = true
File.open(path_to_file) { |f| uploader.store!(f) }
end
after do
MyUploader.enable_processing = false
uploader.remove!
end
context 'the thumb version' do
it "scales down a landscape image to be exactly 64 by 64 pixels" do
expect(uploader.thumb).to have_dimensions(64, 64)
end
end
context 'the small version' do
it "scales down a landscape image to fit within 200 by 200 pixels" do
expect(uploader.small).to be_no_larger_than(200, 200)
end
end
it "makes the image readable only to the owner and not executable" do
expect(uploader).to have_permissions(0600)
end
it "has the correct format" do
expect(uploader).to be_format('png')
end
end
If you’re looking for minitest asserts, checkout carrierwave_asserts.
Setting the enable_processing flag on an uploader will prevent any of the versions from processing as well. Processing can be enabled for a single version by setting the processing flag on the version like so:
@uploader.thumb.enable_processing = true
Fog
If you want to use fog you must add in your CarrierWave initializer the following lines
config.fog_credentials = { ... } # Provider specific credentials
Optimized Loading of Fog
Since Carrierwave doesn’t know which parts of Fog you intend to use, it will just load the entire library (unless you use e.g. [fog-aws
, fog-google
] instead of fog proper). If you prefer to load fewer classes into your application, you need to load those parts of Fog yourself before loading CarrierWave in your Gemfile. Ex:
gem "fog", "~> 1.27", require: "fog/rackspace/storage"
gem "carrierwave"
A couple of notes about versions:
- This functionality was introduced in Fog v1.20.
- This functionality is slated for CarrierWave v1.0.0.
If you’re not relying on Gemfile entries alone and are requiring “carrierwave” anywhere, ensure you require “fog/rackspace/storage” before it. Ex:
require "fog/rackspace/storage"
require "carrierwave"
Beware that this specific require is only needed when working with a fog provider that was not extracted to its own gem yet.
A list of the extracted providers can be found in the page of the fog
organizations here.
When in doubt, inspect Fog.constants
to see what has been loaded.
Dynamic Asset Host
The asset_host
config property can be assigned a proc (or anything that responds to call
) for generating the host dynamically. The proc-compliant object gets an instance of the current CarrierWave::Storage::Fog::File
or CarrierWave::SanitizedFile
as its only argument.
CarrierWave.configure do |config|
config.asset_host = proc do |file|
identifier = # some logic
"http://#{identifier}.cdn.rackspacecloud.com"
end
end
Manipulating images
If you’re uploading images, you’ll probably want to manipulate them in some way, you might want to create thumbnail images for example.
Using MiniMagick
MiniMagick performs all the operations using the ‘convert’ CLI which is part of the standard ImageMagick kit. This allows you to have the power of ImageMagick without having to worry about installing all the RMagick libraries, it often results in higher memory footprint.
See the MiniMagick site for more details:
https://github.com/minimagick/minimagick
To install Imagemagick on OSX with homebrew type the following:
$ brew install imagemagick
And the ImageMagick command line options for more for what’s on offer:
http://www.imagemagick.org/script/command-line-options.php
Currently, the MiniMagick carrierwave processor provides exactly the same methods as for the RMagick processor.
class AvatarUploader < CarrierWave::Uploader::Base
include CarrierWave::MiniMagick
process resize_to_fill: [200, 200]
end
See carrierwave/processing/mini_magick.rb
for details.
Migrating from Paperclip
If you are using Paperclip, you can use the provided compatibility module:
class AvatarUploader < CarrierWave::Uploader::Base
include CarrierWave::Compatibility::Paperclip
end
See the documentation for CarrierWave::Compatibility::Paperclip
for more
details.
Be sure to use mount_on to specify the correct column:
mount_uploader :avatar, AvatarUploader, mount_on: :avatar_file_name
Large files
By default, CarrierWave copies an uploaded file twice, first copying the file into the cache, then copying the file into the store. For large files, this can be prohibitively time consuming.
You may change this behavior by overriding either or both of the move_to_cache
and
move_to_store
methods:
class MyUploader < CarrierWave::Uploader::Base
def move_to_cache
true
end
def move_to_store
true
end
end
When the move_to_cache
and/or move_to_store
methods return true, files will be moved (instead of copied) to the cache and store respectively.
This has only been tested with the local filesystem store.
Skipping ActiveRecord callbacks
By default, mounting an uploader into an ActiveRecord model will add a few callbacks. For example, this code:
class User
mount_uploader :avatar, AvatarUploader
end
Will add these callbacks:
before_save :write_avatar_identifier
after_save :store_previous_changes_for_avatar
after_commit :remove_avatar!, on: :destroy
after_commit :mark_remove_avatar_false, on: :update
after_commit :remove_previously_stored_avatar, on: :update
after_commit :store_avatar!, on: [:create, :update]
If you want to skip any of these callbacks (eg. you want to keep the existing
avatar, even after uploading a new one), you can use ActiveRecord’s
skip_callback
method.
class User
mount_uploader :avatar, AvatarUploader
skip_callback :commit, :after, :remove_previously_stored_avatar
end
Uploader Callbacks
In addition to the ActiveRecord callbacks described above, uploaders also have callbacks.
class MyUploader < ::CarrierWave::Uploader::Base
before :remove, :log_removal
private
def log_removal
::Rails.logger.info(format('Deleting file on S3: %s', @file))
end
end
Uploader callbacks can be before
or after
the following events:
cache
process
remove
retrieve_from_cache
retrieve_from_store
store