Known Issues

This is a list of known issues in CarrierWave. If you have the time and ability to help come up with a better solution for these issues, your contributions would be most welcome!

Edge case problems when not using the mount_on option in mounted uploaders

As discussed in issue 249 and elsewhere, you may encounter problems when not using the mount_on option in a mounted uploader. Due to bug/feature/unexpected behavior in ActiveRecord, when loading records from database using associations it might happen that ActiveRecord tries to assign String value to uploader column. If this happens you need to rename database column (for example use file_identifier instead of file) and specify new name as mount_on option when mounting uploader.

Install image manipulation libraries first, and then install their associated gems

If you get an error such as "Attachment failed to be processed" ensure that you have installed the relevant image manipulation library before installing the associated gem.

Cannot convert multipage PDFs to JPG with RMagick

See issue 517 for details.

Ruby 1.9 & ImageMagick

Read this Stack Overflow page and try uninstalling any prexisting installations and deleting your cache.

brew remove imagemagick
brew --cache imagemagick
brew install -f imagemagick --disable-openmp

ActiveRecord callback ordering

# If we have this model
class MyModel < ActiveRecord::Base
  mount_uploader :bam, BamUploader
  ...
  before_save :set_bam
  ...
  def set_bam
    self.bam = File.open("bam")
  end
end

# Then play
m = MyModel.new
m.save

# Result
m.bam # => nil

CarrierWave is doing part of its magic on before_save and our callback is executed after CarrierWave's because its declared later. If we do our business on after_validation or if we declare the before_save callback before calling mount_uploader, then all is happy.

Fog and Dots in Bucket Names

To avoid having issues with SSL certificate errors when trying to display images on a webpage, do not use dots in bucket names. An example of a bad bucket name would be "my.s3.bucket", which would result in a url like "https://my.s3.bucket.s3-website-us-east-1.amazonaws.com". This address would result in an invalid certificate error because Amazon's certificate is only valid for *.s3-website-us-east-1.amazonaws.com. So any bucket name with extra dots will not be valid. See issue Issue 531 for more details.

remote_url, brackets, colons, question marks and hashes

CarrierWave does its best to interpret the urls it receives by remote_url, but this is not always possible, and certain characters, if presented in the path unencoded, will consistently confuse it.

The class of characters we can't handle are those which are valid in the schema, query string or fragment, but not in the path. Based on the docs, those characters might be :?#[]. Maybe. In RFC 3986 terms, these are the general delimiters aka gen-delims which aren't specifically permitted in path characters aka pchars.

The reasons we haven't been able to do this yet are:

1. We can't just gsub those characters out, because they're ok in other parts of the string.
2. We aren't able to tell which part of the uri they occur in, because URI.parse doesn't work on invalid URIs. We'd have to write a URI.parse which is smarter than the one provided by Ruby.

For anyone willing to give this a shot, here's an insanely difficult test case (perhaps among the hardest possible): http://example.com/:?#[].jpg?foo[]=bar#baz.

• The first colon shouldn't be escaped, but the second one should.
• The first question mark should be escaped, but the second one shouldn't.
• The first hash should be escaped, and the second one shouldn't be (or it should be stripped along with "baz").
• The first pair of brackets should be escaped, but the second one shouldn't.

If you can pull that off, it shouldn't just be a pull request to carrierwave—it's an act of heroism deserving its own gem. (ps. I'm suspicious Webkit & Firefox are already doing something like this; if you're courageous you might be able to find an algorithm there.)